Post formats are slowly dying, and that’s okay

Categorized under:

Photo of author
Written By Brian Krogsgard

26 thoughts on “Post formats are slowly dying, and that’s okay”

  1. I think that this is a very, very well-written piece and very well thought out. Well done, Brian.

    I know that, in my experience, one of the biggest hurdles of post formats – as you mention – is the interface for how we should implement them. Things like quotes, for example, could have a relatively standard interface where, say, the Title represents who said the quote and the Content is the quote itself (then we just place the title field below the content field) – that maps more closely to how quotes tend to work.

    But it breaks down really quickly with links. For example:

    – Does the title represent the anchor text and the content represent the anchor?
    – Is the URL in the title and the anchor text in the content?
    – Do anchors have titles? That is, does the title field serve as a title field and does the content field serve as where you manually create a link?
    – …and so on.

    Obviously, some post formats can be more easily implemented than others, but I think we all have different conceptual models as to what each post format is.

    Case in point: when I think ‘image post format’ I think of a single image with meta data. No title. No content. Some people, though, will want a title, a caption, an area for a description, and so on.

    Until there’s a greater standard in place for how each post format should behave, the portability of the content is going to be tough to manage when each theme is implement each post format differently.

    I *always* err on the side of making sure whatever is in the editor is as close as possible to what the user is going to see on the frontend of their blog. If we, as those who build themes and tools for WordPress, aren’t even sure how to best implement a feature, than I think it needs far more work.

    This isn’t to say that I want post formats to go away, necessarily. I just think that the concept needs to have stricter guardrails around it

  2. I still remember how furious I was when they pulled the Custom Post Types UI from 3.6, and not just because I’d recorded a set of videos for my Mediabistro class that showed them. I really liked that interface, and I’d been using post formats on my personal blog to help organize the content pretty much from the beginning. (I still do, mainly for galleries since I don’t do a lot of single image or video posts.)

    Yes, you can do a much better job of things with custom post types, but custom post types have to be created, and that’s far beyond the average blogger–though I’m glad to see there’s a group working on standardizing custom post types so that the plugins for creating them will have consistency and cross-compatibility. And I agree that it may not have been a good move for WordPress to try to be Tumblr–people who want the Tumblr experience are probably just going to use Tumblr, and that’s a better choice for them.

    I think that if there’d been a proper UI to guide people on using them, post formats would have been a lot more successful, though some of them might always have suffered from under-utilization. (I never much got the point of the aside, though I know someone who used its formatting in Twenty Twelve for another purpose.) Some themes displayed them very well.

    Of course, not everyone uses WordPress primarily for blogging, or uses posts as their main content type. And some bloggers use mainly standard posts because they produce text with very occasional images. So post formats are not interesting to everyone.

    But if post formats die out, what happens to those of us who have been using them for years? Do post formats get converted into categories or tags? Into custom taxonomies? If it’s time for WordPress to move away from them, how does it make that move?

  3. To see what WordPress content editing -might- look like in the future it’s worth checking out Janneke van Dorpe’s editor experiments GSoC project. She’s doing some really interesting stuff. If the Post Formats UI had been implemented it might have tied things down and prevented this level of experimentation within the editor.

    It’ll be exciting to see how content is dealt with in the WordPress way, rather than just trying to give WordPress some tumblr-like functionality.

    (and it goes without saying that this is a fabulous post. keep up the brilliant work!)

  4. I’m actually in the process today of figuring out how to add theme support (Headway) for post format link & quote metaboxes using CF Post Formats UI. I can style the posts, but pulling the metaboxes in is proving to be a huge challenge for me.

  5. I was hesitant in adding support for post formats in my themes in the past, mainly for the reasons Tom already mentioned. I too think that we need better standardization, because they seem to be confusing for both developers and users. But also we need to understand that not every theme needs to support them.

  6. They are very “personal” as they are now. The personal taste of that particular site owner/developer defines the whole experience. I use them some on my personal site as a relatively easy way to segment off a photoblog (which could just as well be done via a category or tag, I admit).

    If I was building a theme for release, though, the lack of how to use it in the downfall. It should be obvious how to add an image post (replace the text editor with an Add Media button).

    Notable, while they are always activated on, there are still fallbacks in some of the places that utilize them, e.g. if an image post format OR there is an image in a post with less than two total paragraphs, treat the image with importance, etc.

  7. The failure of the PFUI project has actually been a good thing for the WordPress project in the long run.

    It directly led to the idea of feature plugins (where prospective features are developed first as plugins), which has turned out to be a great way to develop features and allow many people to test the feature without having to repeatedly find and download and apply patch files from WordPress Trac instead.

    It also once again reinforced that deadlines are not arbitrary and letting them slip too far is a slippery slope. It’s bad for the health of the project and it’s bad for the health of the individuals managing the project.

    Finally, when it became evident that the PFUI was not what WordPress needed and it got ripped out, it demonstrated that we shouldn’t be afraid to say no to something if it’s not working, instead of keeping it in and saying “it’s good enough”.

    Good write-up, Brian.

    • Features-as-plugins has been a good move, but the feature that was supposed to start it off never got turned into a plugin, even though it was supposed to. I don’t remember ever receiving an explanation of why. (Not that Mark Jaquith is personally accountable to me, but the plan at the time PFUI was pulled was to release it as a plugin, and that didn’t happen.)

      I agree that if something is really, really not working, it’s better to discard it than to get trapped by the sunk costs fallacy. And it may be that whatever kept PFUI from working in core also kept it from working as a plugin.

      The only problem with that explanation in my mind is that I was working extensively with the 3.6 beta and as far as I could tell, PFUI was working. So I can only conclude that it was something else that it broke.

  8. It’s too bad that WordPress broke its promise to put post formats into a plugin. There is no standardized way to implement post formats so any blogger using post formats and not willing (or able) to modify a theme will experience serious theme lock-in.

    For example, how should a image post be done? Inserting the picture at the top of the post? With a featured image? Which one will automatically use the correct size image when changing themes? Which will show the image both on the main page and individual post?

    WordPress is trying so hard not to be just a blogging platform (or even worse, Tumblr) that it ran away from a feature that personal bloggers would love and use. Sad… 🙁

  9. While themes that may have used Post Formats heavily will be effected by the decision to abandon them in core, it seems like the best decision for the platform itself.

    When Post Types were introduced, it felt like a reactive response to Tumblr and other blogs that relied on short bursts of varying content as Posts. As Tom McFarlin and others mentioned, this would have led to treating the Post Formats the same way in all themes, or spending time developing custom themes to deal with Formats that required a different treatment.

    It probably would be best to package these Post Types in a plugin and allow for some custom treatment (such as on Images or Quotes). I’m sure the work done between 3.6 and now has not been lost for good.

    I say this death of Post Types in core is for the best, because the platform’s greatest strength is it’s versatility, and Post Types seemed to harken back to it’s blogging roots, and not towards it’s future as a more mature and nuanced framework and application layer.

  10. I’d agree that adding post format into WordPress always felt like we were trying ‘catch up’ with Tumblr as opposed to adding a feature that there was demand for.

    I do believe there is a need to be more flexibility with the content editor, such as styling a post with no title, but I don’t think that need to be standardised as a format called an aside, a quote or status.

    As Siobhan said, Janneke van Dorpe’s editor experiments GSoC project is a much nicer approach to this problem, and hopefully a version of that will make it into core.

  11. I really like them and never used them a lot, because most premium themes doesn’t support them very well and the implementation is a lot of work (you need to add support to the front and the backend).

    Most important while uising post formats is to add different behaviors. A blockquote or link should be visible on the archive pages but not as a single page or at least this one shouldn’t be indexed. The theme for my current website supports them (after a view modifications) very well and it wouldn’t be so nice to remove them at some moment.

  12. I agree we should have followed up on our plugin promise. I’m sorry for not making sure that happened.

    We’re about to enter a renaissance of post formats though, they are far from dead, there is some very cool stuff around the corner and it’ll all be open source and widely available, not a commercial plugin.

    It was never about following Tumblr which is obvious for two reasons: first that many WP developers including myself have been doing that style of blogging years before Tumblr existed, and we wanted to make it easier; second that the most interesting thing about Tumblr isn’t their posting UI, it’s how the reader and reblogs work.

    • Super excited to hear that there is something coming again of these. Seeing you continue to implement them has sparked ideas for how I can implement them on my own blog but also suggest ideas for client integration.

      The css styling has been the easy part. I’d imagine support for styling can be rolled into Customizer.

      I’ve set this in a theme framework (Headway) that doesn’t natively have Post Formats support. Calling the metaboxes used in CF Post Formats UI to display on the front end has been the hardest part of implementation. I went with CF plugin on this per (as far as WP went on integration). Adding functions.php support for Post Formats and even styling the quotes as default blockquotes was easy. Calling metaboxes to display has been my major challenge.

      I would actually love to see the same post default screen on .org self-hosted sites as .com has, including post formats.

      Chasing Tumblr isn’t the issue at all.

    • many WP developers including myself have been doing that style of blogging years before Tumblr existed, and we wanted to make it easier; second that the most interesting thing about Tumblr isn’t their posting UI, it’s how the reader and reblogs work.

      I actually agree with both of these things. I do think though that our backend user experience was designed and developed with a strong focus on what ended up being very similar to the Tumblr format.

      I don’t think WordPress is in any style of arms race with Tumblr, because I agree with you in how they are different platforms.

      I do find it interesting that the new editor on seems to basically ignore post formats, and as Brandon Kraft mentions above, it seems you’re essentially automatically assuming format based on a parse of the content. I think that’s fascinating and wonder where you think we’re heading for .org post formats.

      I’m not closed off to the idea, but as noted in the post, they’d need some serious rethinking from their current state, or that from 3.6.

      Thanks for dropping by 🙂

  13. While Post Formats may have added Tumblr-like functionality, we’re selling ourselves short if that’s the extent to which we use Post Formats. There’s so much freedom that is given to our content in being able to alter how it’s displayed.

    On a homepage or category archive for example, usually it’s the standard featured image and an excerpt for every post. Isn’t every post a beautiful and unique snowflake though? So why should they all display exactly the same? What is going to call out to the reader and get them to click on that awesome piece of content? This is where Post Format-like functionality has power.

    It comes down to the theme level and how we build them, but (depending on your site/content) it’s not necessary to use a special post format template on single posts. In my experience, displaying the special format templates in the blog/archive pages is what is needed, using a standard single-post template once clicking to the full article.

    Because a post is still a post, no matter how we choose to display it, I don’t think that we should be using CPTs for every different ‘format’.

    We also should not be limited to the given set of Post Formats, our content is unique and should be able to be displayed in as many different ways as necessary to properly deliver that uniqueness to our audiences. At the end of the day, we have a glorified taxonomy, and there’s nothing holding us back from rolling our own.

  14. “…and keeping post format consistency when switching themes is difficult.”

    – glad this got a mention since it’s a big deal. What would happen if you use them and then switch themes to a theme that doesn’t support them?! Very worrying… If it hasn’t already, I think this is a problem that really needs to be addresses if post formats are to live on!

  15. I’m a little sad to see that post formats have gotten so little attention. I like them specifically because I don’t want to necessarily go to something like Tumblr to post short things that might be longer than 140 characters (Twitter) but not a long essay either. I also like the idea of being able to share some link, maybe make a comment that’s short, or just link the item with its anchor text as the title and be done with it. I use post formats on my personal blog and am thinking about implementing at least a couple of them on my company website. I’m glad to hear they’re not dead, but would have loved to have seen the UI shipped as a plugin.

  16. I certainly get that post formats aren’t for everyone but I’ve always thought they could be freeing for many people. An interface that says “blog posts don’t have to be 5 paragraph essays” strikes me as an awesome message. As Matt alludes to above, many people have embraced that idea for years.

    Additionally, with an eye toward the open- and indie- web, having WordPress as a CMS that can natively accept post formats from other sites (statuses from Twitter, audio from SoundCloud, etc.) makes it an awesome tool for those who want to own their data.

    And regarding this:

    it seems you’re essentially automatically assuming format based on a parse of the content.

    That makes me nervous. If the post content changes, does the post format automatically adjust? As a user, a sudden unexplained change in display after adding a paragraph (e.g. pushes a post from “Image” or “Video” to “Standard”) would be pretty disorienting. Maybe that’s just a UI challenge to solve, but that might be inherent to the idea of “detecting” post format.

  17. I’m sad to hear from Matt that post formats are far from dead. Just let them die in peace.

    I still do not understand why do you really ever need them? It doesn’t matter how polish the backend UI will be. It will bring misunderstanding for the user. Plus, you are asking the user to change his/her behaviour. Which is usually not a good idea.

    Only developers think in “post formats”. The users only know “content”. So why do you want to give headaches to the users? The last thing I want is to the user stop in front of the computer and start thinking ….should I post this as aside or status? But there is a tweet link, so is it a link, right? Humm I need to open a support ticket now!

    A few questions to put an end to this miserable comment. 1) Is it worth all the stress and work? 2) If you have quotes and aside, why can’t you have lyrics or recipes? 3) Who did choose the post formats? 4) Is there anyone obsesses at Automatic with content formats?

  18. i don’t think post format will be dead.

    i understand that it’s too restricted if we see it as content type/schema, but for me now i no longer see it as content type, buy just a way to present content. like replacement for featured image and not replacement for content type/ post type.

    what if a post need featured video, or audio, or quote, or gallery.

    post format provide a very good solution for me for this “problem” 🙂

  19. Great post. I have long said Post Formats should be plugin territory and I stand by that ( To me the biggest issue (apart from the whole idea seeming to have been a knee-jerk reaction to the sudden popularity of a completely different platform with a completely different target audience) is the lack of proper standards for Post Formats. As they are currently defined it is impossible for designers and developers to know how to implement them in a consistent way.

    If Post Formats are to have a future (as a plugin) their application needs to be clearly defined so users can expect a consistent experience as they switch themes and plugins. That is not currently possible.

  20. I was just looking into adding some custom post types into a twentyfifteen child theme and stumbled on this excellent piece with REALLY great comments. Kudos Brian, so glad you’re going to be going at this full time soon, will be excellent for the WP community as whole.

    I think Post Formats really can be useful, as long as the content is stored in a theme-agnostic way. But I agree that most of the standard types currently seem a bit superfluous and it might be better to just allow for “Standard”, “Audio”, “Video”, and “Link” and emphasize creating custom formats to suit each theme after that.

    The example that got me searching and discovering this thread is basically wanting a post to have any kind of custom formatting outside of the content div. Without post formats that isn’t possible. For example, if you wanted to have posts that had an “Article Overview” or yes, style the video of the post in a way that has dramatic impact outside of the content area, you really need Post formats for that.

    But one thing I think many overlook is also the ability to implement custom editor styles. A lot of posts just need a strong accent box at the top or an attractive call to action at the bottom. Post Formats is too much for something like that, especially when you can implement that seamlessly with custom editor styles that allows the user to see the end result as they type.

    So in my mind a combination of custom editor styles and well-designed and implemented post formats is a really powerful tool. Since I’m writing now post-4.1 launch, I’m really curious what Mr Mullenweg still has in mind with the future of Post Formats at this point. Unless I missed something really obvious in the roll-out of 4.1!

Comments are closed.

A2 Hosting