By default, SMF does not know the concept of the postbit as implemented and used in many other forum software packages. The post bit is a special template that renders exactly one post, therefore it determines how the post will look like.
Instead of this concept, SMF uses a more or less monolithic topic display template that also includes the post template itself. This has 2 major drawbacks:
Here comes the postbit approach
- It is not possible to re-use the postbit layout but this is something that should be desirable. The topic display is not the only instance where the forum needs to render one more more posts. Search results, profile display, recent content are other typical examples. Re-using the postbit template would simplify things and give the forum an overall consistent look.
- It is hard to implement different post layouts. This is something I really wanted to have for EosAlpha - post (or topic) layout should be flexible enough to present a topic in different styles.
Postbit.template.php contains (so far) 4 different post layouts:
- Normal layout (poster info left-sided)
- Simple layout (with a small user-info block in the top right corner)
- Totally clean layout. This can be used to present a topic like a blog article - only very little pre-formatted stuff, the post is shown "as is" - example here
- The compact layout - looks like a typical blog comment.
A topic has additional options and when you post a new topic, you can select which layout you want to use (you need the permission though, so normal users typically can't post with non-standard layout, but admins, moderators or trusted usergroups can).
Postbit templates are implemented as callbacks and the logic lies in Display.php where it finds out which layout needs to be used for:
- the absolutely first post of a topic (first post, first page)
- the first post of a page (if page != 1 - this has something to do with the "sticky first post" feature).
- all other replies
It fills an array ($context['postbit_callbacks']) with the names of the callback functions to use for the first post and replies and prepareDisplayContext() then sets $message['postbit_callback']. In Display.template it's down to call $message['postbit_callback']() to display the post. I always pass $message as reference here, so it shouldn't really have a significant impact on performance (at least, I didn't notice one, even with a long thread using "View all" and about 70 posts on a single page or so). The, by far, biggest cycle burner in topic display is parse_bbc()
For uncached posts, it accounts for about 70% of all CPU time.
Because I have significantly decluttered the post display (especially the userblock), I expect people to call for a more "fully featured" post display. With the postbit system, that should be fairly easy to do, even possible to make it into a user-selectable option.
Hooks are somewhat basic at the moment, but it's possible to add additional info to the $message['template_hooks'] array which is then used in the postbit templates (4 areas - poster info column, before signature, after signature and after the post). There is also an additional hook in Display.php that allows to modify the query which grabs all the message info.
I'm also using postbit templates elsewhere (e.g. in /recent or in the profile showposts area).
BTW: I'm doing the same with other "bit" templates. GenericBits contains templates for a board or topic row. There is SO MUCH duplicated code to display topic rows for example and in my opinion, that's just wrong. A topic row should *always* look the same, no matter whether it's the message index, the search results or wherever else (but that's WIP and nowhere close to finished).