WordPress introduced, a while ago, an interesting thing, called “post formats“. With this feature every post can have a (predefined) format (gallery, aside, video, …) which “declares” the main scope or content of the post. That format can be used from designers to render posts in a different way using their format.
It’s easy to imagine how: a “gallery” post can have the sequence of images presented with a slider, a “video” post can be rendered around the video player, focusing on that than on the text content and so on.
Managing post format is not required when coding a theme: a designer can work with the old school method, where a post is simply made of a title, some meta information and the content (displayed with the_content() function).
If on a theme we want to support post formats, we need to supply different piece of theme to render different post formats. Eventually we can choose to customize only few of the available formats and fall back to the default rendering for the ones we do not manage (always keep in mind that new format can be added, hence we must have a fallback).
If you look at the TwentyTwelve theme, the WordPress team load a spacial rendering part with:
<?php get_template_part('content', get_post_format()); ?>
the get_post_format() return a string containing the post format (the standard format is an empty string) and the get_template_part() try to find in the theme folder the file named content-{format}.php and, if not found, try to load the content.php (the fallback mechanism: if there isn’t a piece of theme for the specific post format, use the generic “content.php”).
Recently I installed a nice theme on a high traffic blog (and with many plugin). The blog was already near the “out of memory” limit, and with that new theme the page rendering regularly hit that limit generating errors.
If was not a fault of the theme, even if it was so configurable that even the rendering of a single simple post was very memory and database consuming.
Between the optimization I made on that theme, there was the post format detection. It was done as:
if (has_post_format('gallery')) {
} else if (has_post_format('image')) {
} else if (has_post_format('video')) {
} else if (has_post_format('asaid')) {
} else {
}
since the blog was made only of standard post format, that if structure was tested on each condition. The has_post_format() is not a simple function, it requires queries, filter calls and so on. But the post format is known from the beginning, so it’s wrong to ask WordPress if the post has a specific format, it’s correct to follow the TwentyTwelve example and extract the post format and then check it against the string values:
$post_format = get_post_format();
if ($post_format == 'gallery') {
} else if ($post_format =='image') {
} else if $post_format =='video') {
} else if ($post_format =='asaid') {
} else {
}
Ok, it is far better: even if I have not profiled that, I’m pretty sure the difference in CPU and memory usage can be relevant.
Is it the best we can do? No. most of the posts in a blog use the standard format, so that is the first thing to check:
if ($post_format == '') {
} else if ($post_format == 'gallery') {
} else if ($post_format =='image') {
} else if $post_format =='video') {
} else if ($post_format =='asaid') {
} else {
}
Theme code, I love you, but take care of that: the web needs speed!
