Andrew Nacin

A few months ago, when WordPress 3.1 and the new Post Formats feature began to get some coverage in the community, there was a minor backlash over how the core team interpreted and decided to implement the feature. I spent most of the day on Twitter doing damage control.

By the day’s end, I was able to tell a number of detractors that I would spend some time taking my thoughts — communicated in pieces in 140 or less characters throughout the day — into a blog post. I never did that.

For a while, I figured it would no longer be necessary. But as WordPress 3.1 is edging ever closer to release, I’m realizing that failing to communicate the true purpose of this feature is going to be a heavy responsibility on the core team, and on myself for promising an explanation.

I just posted a comment on a blog post about this. I had to tell the author that he didn’t quite understand the point of the feature — and that I felt responsible.

So, here’s our take on what post formats are, what they are not, and why there are what they are.

Originally, the entire feature was envisioned as a single Codex page.

There was no code. It was simply going to outline a standard: a name for a custom taxonomy, and a standardized set of formats. Any theme wishing to leverage post formats could then perform the initial taxonomy registration. A blogger could switch between themes that supported post formats, and things would be seamless. Sounds simple, right?

Not so much. Standardization here would be exceedingly difficult. How a theme implemented the code aside, there was at least one issue that would be a dealbreaker: whether a requested term name and slug would be available for a particular user. Because terms share the same namespace across taxonomies, a gallery tag might mess up a gallery post format, causing for example gallery-2. This would not work; it defeats the purpose of creating a standard. We decided that we would need to namespace terms for optimal portability: post-format-gallery is how it gets stored under the hood, for example.

So, instead of just implementing a Codex page, we went out to write some code — but we kept it as minimal as possible. The actual implementation of post formats is pretty dry. It’s a custom taxonomy, with a custom meta box — two things any theme or plugin could register and leverage on their own. It uses APIs which have largely existed since WordPress 2.5. For all the new cool things we add each version, this feature’s purpose had nothing to do with the code. Literally nothing was added anywhere that a theme or plugin couldn’t already do, for some time at that.

And that brings us back to the point of the feature.

With term names and such, we went through great lengths to ensure formats were as portable as possible. The idea behind the feature is this standardization and portability for a segment of bloggers. Many designers of themes used for microblogging wanted this ability to offer structured, well-defined content, beyond what could be done with categories and tags. It’s designed so when you switch to a different theme — a specific kind of theme, at that — your content doesn’t lose its most fundamental context.

The feature isn’t for everyone.

I don’t expect every theme out there to leverage them. They’re frankly not always useful — it fulfills a specific role. A number of themes and theme companies will benefit greatly from this. Custom implementations will not, and that’s the idea.

Many have suggested that “the WordPress way” would be to establish a standard, but then still allow plugins and themes to hook in and add their own post formats. Ultimately, this feature is an exception of the rule. It’s not like we decided we liked the idea of post formats and then later came across the idea to force them to be standardized. No, the idea we started with — before we had a name for them, even — was the standardization itself. The only new thing this feature brings to the table is the portability enabled through standardization. Without that, the feature is useless.

If you want a custom post format, then chances are you shouldn’t be using post formats.

Here’s the great thing: Nothing is lost. If you want to do a custom implementation, then just roll the feature yourself, as a custom taxonomy. That might sound daunting, but it’s not at all. It’s the same thing you would have done in 3.0 in any custom implementation: a few dozen lines of code to register a custom taxonomy and a meta box. Then you can use body/post classes and template tags in your theme and style the posts based on that.

So, if you’re writing a microblogging theme and wish to leverage post formats, by all means, please do. If you want a challenge, roll your own meta box, add icons for each format, and do whatever you’d like to fulfill the niche. There’s no requirement to actually support our UI for it; that’s just to get things going. I really want to encourage some creativity in this space.

If you’re doing a custom implementation or a special theme and want something like post formats, then think about how you would have done that in WordPress 3.0: You would have registered a taxonomy. Yeah, it really is that simple.

If you have a comment or gripe, please comment.

I’ll do what I can to address it. I’m sure there are stones left unturned, and I want there to be understanding, even if we won’t all be in agreement.

Some further thoughts and suggested reading: My colleague Otto Wood has previously written on this topic, in “Post types and formats and taxonomies, oh my!”, which does a great job summarizing the user’s point of view.

I’ve also been asked quite a few times whether post formats or custom post types makes sense for project X. My answer is generally pretty blunt: If you’re not sure which you should use, then chances are you’re horribly skewing the purpose of one of them. Otto’s post goes into this, and you may also wish to read Mark Jaquith’s post on Post Formats versus Custom Post Types.

Are there flaws? Yes. There are a few confusing factors here. One, as Mark suggests, a ‘custom post type’ is a horrible name for what it really is. Ironically, the best name for ‘post formats’ (trust me, we pulled out our thesauruses for this one) would have been ‘post types.’ Then there’s the confusion where some have used the term ‘custom post formats’ even though they’re not talking about custom ones at all — probably because of confusion around the similar-sounding ‘custom post types’ term.

Finally, on the subject of Twenty Ten supporting post formats: From a theme level, it makes perfect sense. Twenty Ten already supported special styling for asides and galleries, which (along with the P2 theme) was a natural precursor to post formats. Looking at it in the context of a default WordPress installation, you now have categories, tags, and post formats. It can definitely be a bit much. Hopefully, users will discover the Help tab (something we should make more prominent for new users). I also think it is further migrated by one of my favorite enhancements to 3.1: hiding most of the meta boxes on the Add New Post screen by default.