Post formats were introduced in WordPress 3.1. They were, and still are, little more than an organizational feature that allows themes to support ten custom content formats such as asides, links, quotes, video, and audio. They are just a taxonomy — similar to categories and tags — and are restricted to whatever the active theme supports.
The concept for post formats made sense at the time, though even then it was a topic of intense debate. Post formats in 3.1 were supposed to be an introduction of the feature, to be iterated on once themes began to show how they would use them. In WordPress 3.6 there was an effort to establish a consistent UI, which failed to land in core. I believe they’ve been dying a slow death ever since.
Were we just chasing a competitor?
When post formats were discussed and launched, they felt like an attempt to mimic what Tumblr was doing so well — to make it easy for end users and bloggers to create nicely formatted content for specific content structures.
The problem with post formats is that they have no standard user interface and there is no intuitive standard for how themes should implement storage for post format data, beyond a general recommendation that everything should be stored in the post_content. Additionally, support for post formats is primarily reliant on the active theme, and keeping post format consistency when switching themes is difficult.
With these struggles combined, post formats have faced issues on nearly all fronts: users hardly understand how to utilize them, theme authors can offer very little consistency for supporting them, and without mass adoption core developers have a hard time investing their efforts to improve the features.
There have been some impressive efforts to standardize post formats
Alex King and Crowd Favorite created a tabbed UI not long after the feature came out, and it was the basis for the discussion for including post formats into core. But this UI required inclusion either as a drop-in to a theme — which is a bit heavy handed for a theme — or to be included a a plugin.
Under that structure, the post format UI was reliable and sufficient for client work, where a developer set it up for the client; but it’s not an effective route for mass adoption amongst users and those that want to use it with whatever theme they have.
Furthermore, it used custom fields for storage of things like link addresses and video URLs, which then would not transfer to another system or if the user decided to abandon post formats altogether.
Therefore, WordPress 3.6 post format UI faced battles on many fronts: data storage, user interface, fallback mechanisms, and battles with altogether different concepts (like content blocks, for instance).
Eventually, after much debate — and very late in the game, during the Release Candidate stage — a post format UI was removed from WordPress 3.6, with many amongst the core team basically expressing that a much more low level content problem needed to be solved.
I fought hard for it, and a lot of people put a lot of effort into it. But the result just isn’t compelling, or obvious, or any of the things that it should be. It’s not just a matter of polish, it seems to be a fundamental issue with the concept.
There were some pretty great things in that 3.6 code that would’ve been tremendous for post format support, even without a consistent UI. However, most new code was meant for that UI and was removed as a part of the revert. This included methods for automatically separating content within the UI so it can be called by themes as separate functions.
I don’t think it’s a bad thing that post formats are dying
I tend to think, looking back, that perhaps we were too strongly responding to alternative content entry methods with post formats, versus creating our own strong ideas for how WordPress can better support rich media and custom content structures.
Now, conversations are more often centered around creating intuitive UI and then worry about putting things back into the content; themes like Make and plugins like Velocity Page are good examples of these structures. Before, we were trying to extract stuff from the main content so we could use it how we want on the presentation side of things.
Additionally, I question whether the right decisions were made about structure for post formats themselves. Did we really need to restrict post formats to ten standard ones, with no supported methods for extendability? And what is the difference between asides and status? And we included formats like chat, which seems like an edge case at best. There’s little use crying over spilled milk, but perhaps in hindsight some things up front could’ve helped the feature long term.
Finally, when we can create much more unique content structures with custom post types, or simply with custom meta boxes within posts, did we really need post formats? What were we achieving by making these organizational standards?
Custom post types for things like links, videos, and audio make a lot of sense to me, and issues like including those in primary RSS feeds, in home screen feeds, and other post-esque things are pretty easy.
Alternatively, the definition of a post itself is evolving. Today we often read posts that include all types of media that is not always easy to reproduce within the confines of the_content; consider “story” style content that’s become so popular in many journalism organizations.
Post formats weren’t a failure. Investing more in them may be though.
Post formats weren’t a failure. There were some excellent theme experiments done with them; Collections comes to mind, as does Twenty Thirteen. They had promise, but it just doesn’t seem the best way forward anymore for highlighting non-standard content. I think the concept gives too little credit to content in the first place; for instance, what if a post has video, audio, and quotes? How does that fit in a post format organizational schema?
I don’t think people have to start ignoring alternative display methods for things they may currently identify as “post format material.” Creativity will and should survive with displaying post content in themes; but I don’t believe that doing it through post formats is the best way.
And if we do double down on post formats (I really don’t think we will), then there will need to be some really serious iterations on the presentation, because since inception the UI has been in no-mans-land.
I’m glad WordPress had this experiment with post formats. I think it helped evolve our collective thinking about content and the many shapes of it.
I also don’t think we should just go and deprecate the feature; I think deprecation can happen naturally, as fewer themes support post formats out of the box.
I’d rather see themes and plugins create more creative, intuitive, and eventually standard methods for highlighting all kinds of content, in a way that allows site owners to manage and access that content whether those methods are active or not.
Hmmm yeah definitely seems like copying of tumblr like content, never used them, probably never will. Carry on 🙂
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
Never really used post formats, but it did seem like an attempt to “tumblrize” WP a little bit. Good info though Brian!
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?
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!)
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.
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.
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 WordPress.com, 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.
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.
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… 🙁
Blogging interest is on the decline; hence, the formatting wanes. ©2014
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.
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.
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.
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 https://core.trac.wordpress.org/changeset/24021 (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.
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 WordPress.com 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 🙂
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.
“…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!
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.
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:
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.
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?
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” 🙂
Great post. I have long said Post Formats should be plugin territory and I stand by that (http://mor10.com/post-formats-plugin-territory/). 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.
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!