My Opinion WordPress

Why Post Formats Should Be Plugin Territory

Post Formats is arguably the most poorly defined and confusing feature of WordPress core both for developers and users. Post Format behaviour is inconsistent across themes and the guidelines for the feature are ambiguous at best. When the core developer team started work on a proposed Post Formats UI around this time last year they unwittingly went down a path that eventually led to a lengthy delay of WordPress 3.6 and the restructuring of how core features for WordPress are developed.

Currently Post Formats themselves remain as a core feature and there is sporadic talk of restarting work on the Post Formats UI. I question it’s valid claim as a core feature and propose a radical shift and a rethink: Redefine post formats and their function, draw up strict guidelines, and move the entire feature into a plugin.

The Post Formats Inception

From the original introduction in version 3.1 it was pretty clear Post Formats is a blogger-first feature introduced in large part to compete with Tumblr. WPTavern has a great write-up if you want further info on its background. The general idea was that a blogger should be able to easily publish a quote, a link, a picture, a video, and so on without having to go through the trouble of assigning categories and tags and structuring her content. And this makes sense if you are Automattic and you fear Tumblr may be a serious competitor to It may even make sense if you consider WordPress to be primarily a blogging application. But WordPress is not a blogging application – it’s a light weight CMS. And a large portion of WordPress users are not bloggers.

This begs a question: Should a bloggers-only feature be a core feature in WordPress?

A lack of definition

If you’ve ever used Post Formats you will know that pt what it means to apply a format to a post is largely unclear and entirely at the whim of the theme developer. This is exemplified in how different Post Formats work in the default Twenty Thirteen and Twenty Fourteen themes. This inconsistency can be traced back to the lack of a clear definition of what a certain Post Format is or should be. The breakdown of Supported Formats and Suggested Styling in the Codex article for Post Formats provides some general guidelines but the language is non-committal and ambiguous leaving ample room for interpretation. Take the Image definition as an example:

image – A single image. The first <img /> tag in the post could be considered the image. Alternatively, if the post consists only of a URL, that will be the image URL and the title of the post (post_title) will be the title attribute for the image.

This example outlines three wildly different user scenarios, all of which are more or less mutually exclusive:

  1. An image post should have one image, and one image only.
  2. An image post should have one or more images where the first image is considered the image.
  3. An image post should have one URL pointing to an image and the theme will wrap this URL in an <img /> tag and use the post title as the title attribute.

There are also many unanswered questions: Can an Image post have text content? Should the more tag be used? What content should be displayed in index pages and in the single post template?

But the biggest issue is what this ambiguity does to consistency:  If you use a theme that employs interpretation 3 and then switch to one that employs interpretation 2 or 1 you will have to reformat your content or end up with a sub-optimal user experience for the visitor (in this case providing an unlinked URL in place of an image). The same goes for other combinations, and this extends to all the different Post Formats.

From a design and development perspective this may seem like an attractive lazzis-faire approach, but for the user it is a setup for chaos. When the designer and developer are left to interpret the Post Formats as they please the end result is that the user cannot expect consistent behavior across themes when using the feature. Which is an excellent reason not to use the feature at all.

Interestingly this is not far from the reasoning Justin Tadlock uses for keeping Custom Post Types out of distributed themes: When the user can’t expect consistent behavior between themes, the feature should be a plugin that be applied independently of themes. I argue this is the case for Post Formats as well.

A solution looking for a problem

As I stated earlier the inception of Post Formats seems to have been a desire to make it easy to post single images, single videos, and other simple content to a WordPress blog. From my experience interacting with WordPress users of all skill levels this is not a typical usage scenario. While many use WordPress primarily as a blogging tool, few post the types of content that Post Formats seem to be intended for: Single images, videos, and audio clips with no text, single quotes, chat logs, links, and so on. The only justified and consistent use of Post Formats I’ve seen anywhere is on Matt Mullenweg’s own blog where he frequently posts Asides. In most other cases the format seems relatively irrelevant and the display goal could just as easily be met with standard layout techniques.

Furthermore Post Formats have no purpose for those using WordPress as a CMS. In fact, the proposed Post Formats UI with it’s ambiguous interface would be a major distraction and cause of confusion to many of these users. As for the type of content intended for Post Formats there are important SEO and RSS issues and questions of whether mass-posting of small pieces of content has merit.

One could argue the infrequent use of Post Formats is due to the lack of theme support and the feature being hidden away, but the whole concept of “QuickPressing” seems foreign and even detrimental to what I’ve observed as the typical user behavior. It may well be that the front-end editor in generates a lot of this type of posts and that Post Formats should be a primary feature on that service, but I have my doubts that a Post Formats UI will change the core behavior of self-hosted WordPress users in a significant enough way to justify its wholesale inclusion.

A Way Forward, as a Plugin

I propose a rethink of the concept of Post Formats and a removal of the feature from core and into a plugin. As it stands right now Post Formats is essentially a locked taxonomy developers can test against in conditional statements. There is no clear definition of exactly how the formats should behave, the user has no clear explanation of how she should use them, and there is a question begging to be asked about whether the feature is something the general WordPress user wants or needs in the first place.

To start the process a usage scenario has to be clearly defined and stated. That means answering four key questions:

  1. Who is the Post Formats user?
  2. In what scenario is using a Post Format better than a regular post?
  3. What does she expect from Post Formats in terms of new content and different display modes?
  4. When and where would she use Post Formats (From WordPress admin? As a browser bookmarklet? In an app?)

Based on the answers to these questions the goals and intentions of the user can be defined and the feature can be built to meet them.

To ensure ease of use and an informative user experience the Post Formats plugin will likely add a new panel to the post editor UI not unlike the proposed Post Formats UI. The panel should have clear instructions explaining the difference between Post Formats and the regular editor and when a Post Format is selected the UI should change to accommodate the information required for that format. This might mean adding new input fields for dedicated content or hiding existing fields in the editor or a combination of both. That way the ambiguity in the existing solution is eliminated, the user is provided with clear instructions about what to do, and the correct type of content is provided to be displayed on the front end.

On the development side baseline output behavior must be established to ensure the output from the Post Formats plugin is integrated into the output of the regular post content in such a way that the intention of each Post Format is preserved. This likely means placing any Post Formats meta content at the top of the post and pushing the regular post content down. It may also mean wrapping Post Formats meta with hooks so the content can be displayed separately from the main content in index pages and widgetized areas. If a theme developer chooses to create custom templates for the Post Formats plugin, the behavior of those templates must stay within the parameters of the guidelines. If the developer chooses not to ship custom templates the visitor should still have an enhanced experience in line with the intentions of the site owner.

By removing Post Formats from core and placing them in a plugin, establishing clearly defined usage scenarios and goals, and providing strict guidelines for theme implementation, the feature will turn into an optional enhancement for those that want it rather than a confusing and frustrating addition to an already complex admin panel experience. It will also allow the feature to evolve and change to fit the demands of the user in a way a core feature never could.

A lot of impressive work has gone into this feature and Post Formats has merit as part of the WordPress ecosystem, but the way it is currently implemented is not beneficial to theme developers, users, or those who visit their sites.

That is my opinion. I’d love to hear yours in the comments below.

More perspective on Post Formats

Much has been published on this topic. Here is an incomplete list for further reading: