On standardized post formats

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 mitigated by one of my favorite enhancements to 3.1: hiding most of the meta boxes on the Add New Post screen by default.

Published by

Andrew Nacin

Lead developer of WordPress, living in Washington, D.C. Follow me on Twitter.

62 thoughts on “On standardized post formats”

  1. So I assume it is possible for a theme or plugin author to leverage a custom UI and utilize the built in post format feature?

    The lack of direction in the admin for different post formats is the most limiting factor to the end user in my opinion. If a theme or plugin author can customize the admin to make things make sense in this regard, I think post formats will be much more successful.

    1. Customizing the Add Post UI based on Post Format type is a good idea, but I think it will require some widespread adoption/standardization of the nature of content expected for each type. For example, in my Theme, I don’t display Post Title for Aside, Link, Quote, or Status, so it would make sense not to display this field in the Add Post UI for these Post Format types. But the de facto standard may end up being that, say, Quotes do display a Post Title.

      Otherwise, I don’t see the “lack of direction” in the Add Post UI to be an issue. For the most part, the purpose of the feature is not to change the Post Content, but rather to modify how the front end displays Post content.

      1. It’s worth remembering too that even though some fields won’t be displayed (like aside usually shows no title), those fields are still there and probably should still have content in them. What about the post in the feed, for example?

        And realistically, for cases where you’re not displaying something like the title for an aside, you’d probably still want the title in the html of the theme, just CSS making it display:none. For SEO and what not.

        Titles are important to have, even if you’re not showing them. Other fields have similar cases.

      2. Chip. I would have to disagree with you about hiding the post title for the UI in any format. These titles are used throughout WordPress – not just within the loop. Take for example the Recent Posts widget. If a post has no title, this widget displays the ID of the post linked to it’s single view. I have not tested menu’s in this regard, but I would assume a similar outcome.

        1. Of course, this discussion highlights the possibility that perhaps content-types such as “aside” or “status” (or even “link” or “quote”) really aren’t actually posts, and should be their own Custom Post Type (i.e. Custom Content Type – thank you, creators of this unfortunate nomenclature).

          After all: what semantic sense does it make to have a “title” for a “status” (or an “aside”, etc.)?

          1. Yeaaahh… I disagree. A “post type” or a “content type” implies more of a difference than the format does.

            “Appearance” is different than specifying the type. I think most people would want “quotes” and other sort of things to appear in their normal stream of content. Anything that would appear in the main stream should be a “post” post-type.

            Just because you don’t display it when viewing the web page doesn’t mean it isn’t there and isn’t meaningful. Half my audience doesn’t view my web site directly.

          2. But maybe I *don’t* want my status updates or asides to be in my primary feed. Maybe I want them to be output in some sort of secondary loop (think of the way people display their Tweets or FB status updates).

            Just a thought…

          3. Sure, at that point, you’re not considering your status updates or asides to be blog posts.

            For example, I have a ‘tweet’ post type on this blog. One day, I’ll have those all indexed at http://andrewnacin.com/tweets/. It’s a post type, it’s completely different from my blog.

            It all depends on how you wish to define your specific usage of statuses. Some people use them as part of a microblogging format. Others don’t, and desire distinct areas of the site with different functionality. That’s probably the only time you could look at something and say “hmm, post format, or custom post type?” — but ultimately the answer lies in how you use your site, not the content itself.

    2. Customize away. I would proceed with the cautions that Otto laid out, but I did mention in the post that there’s no reason a theme needs to support our core UI. That’s just the beginning.

  2. Andrew, I have been following this discussion since it started and I am still not convinced by this new feature.

    The standardization post formats want to bring is not something there was large demand for. I understand that it may be a useful thing to have in a multisite setup like wordpress.com, where you want users to be able to switch themes and, at the same time, to be able to enjoy a reliable set of standard features across all themes, but is that a sufficient reason for adding something to core?

    Outside of cases like that, themes that wanted to offer alternative post layouts/styles could always do so in a very simple way, and can still do so, as you explain. K2 has been offering this feature since 2006. Any theme can offer it without support from core: “Dear user, I have also made two alternative layouts for you. You can select the categories or tags you want these layouts applied to.”

    So, in short, while I appreciate the usefulness of post formats, I am not sure the feature was a good candidate for core.

    Cheers!

    1. I disagree that it’s an edge case. Tumblr-like blogging is quite popular.

      Just because you don’t use it and it won’t be used for custom-designed sites much doesn’t mean that it shouldn’t be in the core. 30 million people use this code, not all of them use the same bits.

      1. +1 to Otto.

        This is the precise point of Post Formats—it provides a mechanism to have slightly alternate post types standardised so themes can handle them without issue. Speaking personally, the availability of the Aside format in Twenty Ten has meant that doing asides is no longer anywhere near as janky as it was (i.e. using a plugin or a category and then hacking against the theme, which was messy and often resulted in breakage on a theme/version change.)

  3. Nacin,

    Great write-up; thanks!

    While I am in the “in principle, if it’s in WordPress core, it should be extensible” camp, reading this post, I finally had an epiphany that may have brought me around to supporting the decision not to make the post_format taxonomy extensible. It was right in front of me the whole time, and now that I’ve seen it, I wonder how I missed something so obvious:

    If Theme developers really need/want to extend the custom taxonomy, they merely have to define their own, in lieu of adding Theme support for the core-defined taxonomy.

    Maybe that’s what Otto was saying all along, and I was just mis-interpreting it: as in, I was hearing “my_theme_post_format” custom taxonomy and core “post_format” custom taxonomy, but he was actually saying “my_theme_post_format” custom taxonomy instead of core “post_format” custom taxonomy.

    I think it all makes sense now!

      1. I think it finally makes sense to me as well. You don’t need hooks/filters to alter the core post formats- you can just define your own taxonomy which may or may not also include the supported core post formats. It sounds like the same outcome in the end though- devs can customize if they really want to.

        Let’s say you have a site where you post a lot of code snippets, and you want these to be displayed slightly different than any of the other post formats. You have the option of tagging or categorizing these posts to get the different look, but, but if you really want to you could also set up a new separate taxonomy that includes your standard image, audio, link format + your new “code” format. Right?

        If you were doing this with a child theme of 2010, you would deregister all the supported post formats in your child theme, and then register this new taxonomy in order to enable all the post formats + your code format.

        I’m guessing this would be a really edge case, if people do it all- but is that how its being envisioned?

  4. I’d previously had the same misconceptions about standardising post formats that other people on Twitter had. This post completely cleared it up for me.

    As someone already very happily using custom post types and taxonomies for specialist themes, you’ve just made me appreciate them even more!

    Thanks, and thanks for going into real depth on the subject 🙂

  5. I don’t know about most of the rest of the people in the WP community, but after reading a couple posts online about the difference between CPTs and Post Formats, I’ve found it obvious the type of use that could be done with each.

    To me, Post Formats add an extra hook that you can utilize through CSS and perhaps even more things, to add some extra customization to the POSTS you create.

    Custom Post Types allow you to fork off from your primary stream of fresh, incoming content and make management easier, in a separate part of your overall site. Thus uses like Event listings and portfolios, among the many other areas they can and will be utilized.

    1. Yeah, you’ve nailed it. Custom post types are better described as custom object or content types, while a format is how a specific blog post is styled. It’s not just about easiness, either — CPTs are going to be holding non-post content that you wouldn’t mix with blog posts.

  6. I’ve been following this discussion on the wp-hackers list, through a couple of blogs, and now here on your site. I vote we still #blamenacin for this.

    That aside, I finally get WHY it is the way it is. The portability factor makes a TON of sense. In my personal blogging, I’ll probably never use it, but I have friends, family & clients who WILL make use of one or more of the post formats.

    I’ve implemented a couple of post formats using the taxonomy API and once you wrap your head around it, it’s not that hard.

    Thanks for this post – it’s been enlightening.

  7. I haven’t been part of any of the debates about this feature. I’m not a theme or plugin developer as such, although I do dabble enough that I created my own theme and a handful of plugins for my own use.

    Just wanted to say, as soon as I heard about this feature I was eager to move to 3.1 – and have been running 3.1 since the first public beta. While I now understand how a custom theme could do similar things without the Post Formats feature, I’m happier to be able to implement it using the standards that exist in 3.1 – and I like the idea that those standards are portable from one theme to another.

  8. As one of the original detractors, I admit that you had me convinced via Twitter that this was a good idea. Your blog post only reaffirms that. I know I’ll be using post formats in a couple of upcoming theme designs as well. Hopefully this will be one step among the many it will take to increase the interoperability of WordPress themes and third-party systems.

  9. WooThemes has been doing something similar. They are branding it as a “Tumblog”. They also added these standardized types in the quickpress window from what I can tell. I am curious if they are treating this the same as what you are doing in 3.1 or some other way. The idea behind this IS standardization and portability right?

    1. Nathan, I’m having a hell of a time getting the tumblog quickpress function to integrate with other (almost) core functions such as wpmu sitewide tags plugin. I built our new site around the premise of a network of tumblog sites and naturally wanted to present an aggregated view of these tumblog posts on the homepage of our main site.

      Unfortunately due to a lack of standardisation I have now expended weeks of my time trying to get them talking with each other, which is so frustrating because it should not be necessary.

      The (free) wootumblog plugin is the best (i.e. only) UI solution out there and should have been adopted more widely by other developers, but instead it’s been left to the non-developers amongst us to try and glue the various bits together.

      Given Tumblr’s massive growth trajectory and the forecasts that it will overtake the WordPress installed base in the near future, I cannot understand why post formats have not been further embraced and plugins (such as wootumblog) been enhanced and improved upon by other developers.

  10. Regarding the confusion over custom post types vs. post formats: what are the chances you guys will ever bite the bullet and call CPTs “custom content types”, change wp_posts to wp_content, the works?

  11. Honestly, well, first, respect. I like the idea of a few standard post-formats. WP3.0 and 3.1 got me back interested in theming. You guys must have missed a lot of sleep, because the last two updates have been significant to say the least.

    Now, if you are going to limit post-formats and tell people that if they want something else, they should build it themselves (which I totally agree with), then why not post some guidelines for themers as to the ideal usage of each. I think we would all like for WordPress users who want to microblog tumbler style to be able to switch themes reliably without loosing anything.

    For instance, the video post format, I’m using title as the title, the body contains a link or links that jquery throws HTML5 media element js around, and the excerpt is used as a brief description, if desired. It’s the best implementation I can come up with, but what if some chick in Boston makes a theme that looks better, but switches the roles of excerpt and body or worse yet uses a custom field, THE END-USER SUFFERS.

    I know these formats are brand spanking new, but at some point it would be desireable to at least outline a standard/ideal/common usage so themers don’t feel like they are going rogue on core features. Just my 2 cents. Either way, great release, congrats.

  12. 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.

    Repository today = 1,336 themes, and a search for “micro blogging” = 10 themes
    Therefore 0.7% of themes use the function claimed as justification for this method. Under marketing terminology, that’s certainly not a sector, nor a segment, it’s a sub-segment. Or was this more to further integrate BuddyPress and bbPress in preparation for a possible merge and inclusion of those in WordPress core? After all, they (and their themes) are more consuming of micro blogging formats than WordPress themes.

    I guess what’s getting to me, is that use of this feature requires themes to knock out the core formats before implementing custom ones, yet if the core formats are wanted in addition, the theme developer then has to duplicate the formats shipping with core … could I whisper “code bloat” here? Why has the system been coded as a “use or replace” set up, why not a “use, extend, or replace” functionality? I’m not buying the standardisation argument. A simple codex instruction to theme devs to “make your own box” instead of piggy-backing into the defaults’ box is all that’s needed.

    Plus, where is the UI for custom post types and taxonomies that was discussed in trac? I can’t find it in 3.1 in either standalone or multisite mode.

  13. Can we have code or code-snippets as a possible candidate to be a standardized format in the future?

    I can see that having some standard formats is indeed useful, Tumblr looks like the inspiration for the initial set of standard formats since it currently has: text, photo, quote, link, chat and video.

    In addition to the Tumblr ones, you guys decided to include aside, image and gallery. And that’s great, I too think those are desirable to have the possibility for a themed layout.

    But as a Forrst.com user/member, I like the choices they give you on posting time: image, code, text and link and I would love to see code as one of the next to-be-standarized post formats in the future, lots of blogs share snippets, pastebins and gists today, and I really believe that it fits the requirements to be considered post-format 🙂

    Pleeeeeease!

Comments are closed.