Post Format Loops in WordPress

Post formats in WordPress are pretty cool. According to the Codex, “A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post.” In my mind post formats are to present content in a way that makes sense for a given format. For example, video posts should highlight the video. Or maybe link posts should link directly to the site you want your readers to see instead of the permalink for that article.

Here I’m going to take a look at creating different templates for specific formats.

First, I’ll say that a good way to get started with post formats is just to enable the ones you want with the appropriate call to add_theme_support()1 in your theme’s functions.php file and customize them with CSS. If your theme takes advantage of the post_class() function to add classes to posts, each post will get a class in a style like “format-$format”, where $format is the name of the format — “format-gallery”, for example.

If you decide that you need to take it a step further and actually generate different HTML depending on the format, the following is a technique that I’ve used. Let’s start by looking at the loop in index.php of the _s theme, available on Github.

<!--?php /* Start the Loop */ ?-->
<!--?php while ( have_posts() ) : the_post(); ?-->

<!--?php <br ?--> /* Include the Post-Format-specific template for the content.
* If you want to overload this in a child theme then include a file
* called content-___.php (where ___ is the Post Format name) and that will be used instead.
get_template_part( 'content', get_post_format() );


The most interesting part of this is get_template_part( 'content, get_post_format() ), which will look for a file with a name like “content-$format.php”. If no such file exists, it will fall back to “content.php”, which will be our default for post types that we’re not going to specify special templates for.

If we think ahead a little bit we’ll realize that all of our posts will probably share some common structure. In my case, I want the title to be displayed if one was specified, certain meta information should be displayed, and of course I want to display the content. So I’m going to create a file called “content-base.php” with that basic structure. Then in content.php, I’ll basically just make a call to get_template_part() to include that base stucture.

In my v11 theme, “content.php” looks like:


Other Formats

Now we can create the templates for other formats just by adding the correct files. An example of my status format template looks like:

> echo ‘

echo ‘


In this case, content-meta.php just defines what meta information to display on a post.

Another example that reuses the base layout is my video format template:


$video = get_post_meta( $post->ID, ‘_format_video_embed’, true );
if ( !empty( $video ) ) {
$url = esc_url( $video );
if ( $embed = wp_oembed_get( $url ) )
echo $embed;
elseif ( !empty( $url ) ) {
printf( ‘‘, $url );
} else {
echo $video;

get_template_part( ‘content-base’ );


Again, there is some more complex stuff here — I use a custom field called “_format_video_embed” to define what video to use. But the general idea is that it displays a video and then just grabs the base structure.

#Tips for Links

A common way of implementing link posts is to grab the first link in the post and set that as the reference for the title link. I have a function in v11 that lets you grab the first link in a post. Then you can output that as the href in content-link.php instead of using the permalink.

if ( ! function_exists( ‘v11_url_grabber’ ) ) :
* Grab the first URL in a link post so we can use it as the href
function v11_url_grabber( $content ) {
if ( ! preg_match( ‘/<a\s[^>]
?href=\'”[\'”]/is’, $content, $matches ) )
return false;

return esc_url_raw( $matches[1] );

#WP Post Formats

As a final note, I like Crowd Favorite’s WP Post Formats plugin. It gives you some nice looking meta boxes for interacting with custom fields on your post formats.

  1. There’s some good documentation on adding post formats in the Codex. 

HTML Demos

I posted a video a few weeks ago of a plugin I was working on to manage HTML demos in WordPress. I’m publishing the code now as version 0.1 — meaning it works, you should feel safe about using it, but it’s not finished. For example, I just realized that the only Javascript library you can include on your page is jQuery.

I think it would be cool to be able to have options to do some post-processing. So, maybe Markdown and HAML for HTML. Obviously SASS and Less for CSS — maybe Stylus? CoffeeScript for Javascript would be nice.

One other thing that I think would be really awesome is if you could associate a demo to a post somehow. Then I could add some extra template tags like the_demo_link(), which would automatically grab the link to the demo for that post. Or maybe another tag that would automatically grab the link for the associated post? Anyway there’s a lot we can do with this.

It’s on Github. I’d love to take pull requests, or any bug reports filed through the issues tracker.


Lots of web people have some way of hosting demos on their site. The one I always think of is CSS-Tricks, but there are many others. I’ve actually done it in the past on my site, but no matter how easy I made it for myself, it was always too hard so I just never used it. But that’s dumb because I publish everything else around here with WordPress and WordPress is really good at keeping track of stuff like this. So I decided to create a custom post type for HTML demos inside WordPress.


The plugin is actually smart enough to insert the HTML after the_content(), which is cool. The styles and scripts are enqueued into the header through external files that the plugin also generates. Bottom line, this should work out of the box with any theme.

If you want to customize how your demos look though, it’s pretty easy. Just add a single-html_demos.php file to your theme and WordPress will use that to generate those pages. So, just like you would customize any other template, you can customize the template for your demos.

View in Plugin Directory Download on Github

Version Control Themes with Git

I really like being able to deploy my current theme to production from my local environment. I can test locally and then deploy to the live site when I’m ready.

Some people like to keep all of WordPress under version control. I don’t think that’s useful unless you’re a WordPress developer. You’re unnecessarily tracking changes to WordPress and your environment. I like to keep each theme and each plugin in it’s own repository. They’re separate projects so they should get separate repositories.

I constantly go back to this great tutorial when I have to set up a bare git repository on a production server.

Facebook: Building the WordPress plugin

WordPress developers will be familiar with many of the problems described here.

I’ve been thinking about this quite a bit lately — writing open source software (where you have a whole variety of environments to support) will be entirely different from working at a company like Facebook (where you probably know more specifically what the servers will look like). Each is going to have his own challenges to think about. Once you get used to developing with certain challenges in mind, it’s probably not obvious what new challenges there will be in a different context.

Using LESS as a Live CSS Engine

It generally just seems like a bad idea to trigger processing of LESS (or SASS) with a page load. Honestly, CodeKit does so much more than just compile your stylesheet into CSS that it doesn’t even seem worth it to me. You should still be generating minified CSS and Javascript as well as optimizing your images. Plus the syntax checking I get on my Javascript. Not to mention all the cool stuff it does with my browser. I’d still be using CodeKit even if I didn’t have to worry about compiling SASS.

Andrew Powers:

One of the coolest things about implementing LESS inside of the framework is that we’re able to dynamically control colors and typography based on user selections. This allows us to design things well, while still giving users the ability to customize colors and type.

Since WordPress 3.4, there is a theme customizer built in that allows you to dynamically control colors and typography based on user selections. Otto has a couple of really good articles on how to use it. The first, How to leverage the Theme Customizer in your own themes, is a good introduction to the customizer. I was happy find that there’s even Javascript that reloads the page within the customizer if you choose a new color so you don’t have to save it and manually reload to see what it will look like (possibly only in 3.5 and up).

Users are able to actually add their own LESS in the admin options panel. They can use common variables for the background color or main fonts.

If your users want to write custom code for their theme, don’t add a textarea to your admin panel that allows them to write code, encourage them to write a child theme — it’s what they’re here for.