Post Formats, is this really a good idea?

January 25, 2011 • Topics: ,

WordPress 3.1 doesn’t just add an admin bar, among the new features are also Post Formats. This is basically a new way to sort content and it does indeed solve a lot of small problems. The Post Formats are:

  • aside (for short asides)
  • gallery (for post being just galleries)
  • link (for post that are really links elsewhere)
  • image (for posts that are really images)
  • quote (for quotations)
  • status (for short status updates)
  • video (for posts that are really video embeds)
  • audio (for posts that are really audio)
  • chat (for chat transcripts)

Now, obviously you can have anything in any post with any Post Format. They are meant for the things above (sort of, I’ve kept it simple), but you’re not limited to it. This is your content.

Assuming you’ve got Post Formats activated in your theme, you’ve got a box called Format under your Publish box in the Edit Post screen in WordPress admin. There you pick from the Post Formats that are active, as well as the Standard one which is what we’ve been using all these years, to put it simply.

The functionality is easy enough to work with. You can do conditional tag checks for what Post Format it is, and you can style it with CSS thanks to logical CSS classes added by the post_class() template tag. I’m using it here on TDH.me for asides (and more, soon), being the short posts without a title on the front page. Before we did the same thing with a separate category, a custom field, or even by adding a taxonomy. In that sense, Post Formats are a great addition to WordPress. After all, it means that we can basically build our WordPress sites looking like Tumblr if we want to. Sweet huh?

So what’s the problem?

My main gripe with Post Formats is that it is limited to the ones listed above. Technically you can add your own formats without much hassle, but the developers doesn’t want you to. This is from the Codex page, a good source for more information on how to use Post Formats:

The Post Formats feature provides a standardized list of formats that are available to all themes that support the feature. Themes are not required to support every format on the list. New formats cannot be introduced by themes nor even plugins. The standardization of this list provides both compatibility between numerous themes and an avenue for external blogging tools to access to this feature in a consistent fashion.

Highlighting by yours truly. Now, you can add new Post Formats if you like to, the developers just don’t want you to.

I get why, in fact it is stated in plain English above. The idea is to stick to a standardized set of Post Formats to make sure that themes and plugins can support it in a wider range in the future.

But what if you need an additional post format? Just add it using a custom field, your own taxonomy, use a category, or any other solution that worked so well in the past, right?

You could do that, but it is poor design.

Think about it. You’ve got your users managing asides and galleries and whatnot in the Format box. But your custom format won’t be there since the WordPress developers disagrees with this practice, meaning that the end user will have to do what should be similar things in two different ways.

That’s not good. That’s bad design.

I don’t hate Post Formats

Don’t get me wrong here, I think Post Formats are a great idea. I’m using them here, I’ll be releasing a theme utilizing them all, and it is pretty nifty all in all. I understand the standardization thought, but I disagree with it.

Here’s my suggestions:

  • Have a set of official Post Formats, and communicate these.
  • Let theme and plugin developers add additional Post Formats easily.

It’s really pretty simple, and all we – and by we I mean all of us working with and developing for WordPress – have to do is clearly communicate when we’re stepping outside of the official set of Post Formats so that users know what will possibly misbehave when they change their themes.

Leave it to us, dear developers, rather than deciding this for us. Isn’t that the WordPress way, after all?

  • http://andrewnacin.com/ Andrew Nacin

    I’m afraid you’ve not quite gotten the point of the post formats feature. I’ll take some responsibility for that, as we haven’t gone out to fully explain our thinking.

    Post Formats do not do anything new. It’s just a custom taxonomy with a custom meta box, which are two things that any plugin or theme can register and leverage. It uses APIs that largely existed since WordPress 2.5.

    Originally, the entire ‘feature’ was going to be a single Codex page. No new code. It was going to outline the name of a taxonomy, and a list of standard terms. We looked at our Taxonomy API and realized that this just wouldn’t allow the kind of portability that we wanted, so we ended up making it a core taxonomy. We went through great lengths to ensure this was as portable as possible.

    The point of the feature is standardization and portability for bloggers, and designers themes used for microblogging. It’s designed so when you switch to a different theme — a specific kind of theme, at that — your content doesn’t lose its context.

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

    If you want a custom post format, then chances are you shouldn’t be using post formats. Just use the existing API to create your own custom taxonomy and meta box, and use the existing template tags to show them in your theme and style the posts based on that.

  • http://twitter.com/kolombiken Ida Franceen

    Agreed. If I want to implement a new post format I should be allowed to do so. This is one of the reasons that I think wordpress is not suited for all sites. Lack of flexibility.
    Where to complain about this?

  • http://tdhedengren.com Thord Daniel Hedengren

    I disagree on the whole flexible thing, WordPress is extremely flexible overall. Post Formats are an anomaly, and what I disagree with here is how Post Formats break out of that. You should read Andrew Nacin’s comment for some background (which might have been directed at you, I’m not sure).

  • http://tdhedengren.com Thord Daniel Hedengren

    Thanks for commenting Andrew, I’m not sure if this comment was directed at me (as the post author) or Ida Franceen’s comment.

    I’m well aware of Post Formats not being anything new per se, and I think it’s a great addition, but I still think it would be better off as I propose as the end of the post: In the hands of the theme and plugin developers. Have a set amount of “official” Post Formats, but don’t tell people they can’t create their own. That sends the wrong message, I think.

  • http://andrewnacin.com/ Andrew Nacin

    Hi Thord, the comment was in reply to the main post; there weren’t any comments on the post at the time. It does send an interesting message, but I don’t think it’s the wrong one. It just happens to be a unique one. It’s not that it’s a list of “official” formats, either, which implies there’s such a thing as an unofficial one — it’s simply the list of formats.

    I am telling people they can create their own: Just create your own taxonomy. There are good reasons behind that. I wrote a lengthy post (spurred by your post here) that I’ll be publishing later today. I’ll link you once it’s published.

  • http://tdhedengren.com Thord Daniel Hedengren

    I know you’re not sending any official/unofficial message, I just think that would be a better way here. Post Formats can be done with a taxonomy, but as I wrote in the post I find that the end user will be suffering if some post formatting will be managed with Post Formats, and other with a custom taxonomy.

    Looking forward to that post!

  • http://andrewnacin.com/ Andrew Nacin

    I’m not referring to creating your own taxonomy to be used in conjunction with post formats, I’m saying post formats shouldn’t be used at that point.

    Post coming up soon.

  • http://tdhedengren.com Thord Daniel Hedengren

    That’s sort of my point. Let’s say you want to build a site which has the aside type of post styling (common enough). You’ve seen other sites doing that, and you’re accustomed to just marking asides as aside in the Format box. All good right?

    Well, the new site needs both aside, just like you’re used to, and something completely different, let’s call it XYZ posts. Now you need to decide: either you do aside as a Post Format and XYZ as a taxonomy, or you do both aside and XYZ as taxonomies. The latter will work, but it will add confusion since the users might wonder why they should do asides like this when they’re used to the Format box.

    See where I’m going with this? By limiting Post Formats to a select few, we’ll get these scenarios, especially when Post Formats have caught on. Better to solve it now, I think.

    Looking forward to that post!

  • http://andrewnacin.com/ Andrew Nacin
  • http://tdhedengren.com Thord Daniel Hedengren

    Nice post, but it really doesn’t answer the criticism (if you want to call it that) in the post and further explained in the comment above. Bottom line: the end user might get confused because the same thing isn’t done in the same way on every site, despite it generating the same result. That sort of clashes with the whole idea of standardization in my book.

    Don’t get me wrong here. Post Formats are a great idea, and I do fully grasp (and often use) the power of creating your own taxonomies. My gripe is with the confusion this will cause and the fact that we’ll have to resort to different solutions to similar problems without any real need for it.

  • http://www.chipbennett.net/ Chip Bennett

    I finally understand (I think): core Post Formats are simply a core-defined custom taxonomy, using the already-existing custom taxonomy API.

    The core Post Format taxonomy is intended for Theme-to-Theme portability of a specific set of Post content-types. But what if a one-off Theme wants to have a one-off Post content-type, and has no need for Theme-to-Theme portability?

    This question used to represent my primary complaint with the decision to standardize the list with no means of extensibility. However, I think I’ve changed my mind.

    Here’s why: the developer of this one-off Theme simply doesn’t call add_theme_support() for the core-defined Post Format custom taxonomy, and instead defines its own custom taxonomy. It can use the same name (‘post_format’), the same slugs (‘post-format-slug’), can add the same post-classes (‘format-slug’), etc. – all using part or all of the same set of types, as well as any custom types.

    While this route is a (minimal) amount of extra work for the developer, it results in an invisible, seamless experience for the end user, who wouldn’t know the difference between the core-defined ‘post_format’ custom taxonomy and the Theme-defined ‘post_format’ custom taxonomy.

  • http://tdhedengren.com Thord Daniel Hedengren

    Should work, but I’m not sure it’s such a good idea given how wrong things can get (especially in the future) when reserved names are being used. Maybe that’s just me being paranoid. :)

  • http://www.facebook.com/jrtayloriv Jesse Taylor

    I was starting to grok how to use standardized formats, but didn’t really understand the purpose until reading this. Thanks for a great article!

Since 2002 by Thord Daniel Hedengren • Quotes and links are fine, but don't steal. ♥WP