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 WordPress.com. 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:
- An image post should have one image, and one image only.
- An image post should have one or more images where the first image is considered the image.
- 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 WordPress.com 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:
- Who is the Post Formats user?
- In what scenario is using a Post Format better than a regular post?
- What does she expect from Post Formats in terms of new content and different display modes?
- 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:
21 replies on “Why Post Formats Should Be Plugin Territory”
I don’t yet have a fully-formed opinion on whether post formats should be in core or not. However, one thing you said early on caught my attention:
I’d argue that posts are, while not “bloggers-only”, a blogging-centric feature, at least. Sure, people repurpose them for all sorts of things, but ultimately, they’re a content type (or post type, in WP parlance) with a somewhat specific use-case in mind.
Just some food for thought 🙂
What I meant with that statement was “Should a feature targeted to a small subset of the total user base be forced on everyone as a mandatory element?”
I was really annoyed when they pulled post formats from 3.6, but that was partly because I’d already recorded a series of videos about them for my class. I liked the new UI, and think it made post formats better. But I don’t know whether post formats belong in core for self-hosted WP. Not every WP site is a blogging site. I would like to see the post format UI developed further–it seems to have just vanished.
I put the Post Formats UI in front of five leading experts in UX. They all reacted the same way: First they though it was a feature that allowed them to place images, videos, etc in the content. When that didn’t happen they assumed the UI was some sort of block element to be displayed separately from the rest of the content. When they saw what happened on the front end they all responded with some variation of “This makes no sense” or “Users will be very confused by this”. I had the exact same reaction. While the UI may have looked pretty, what it did was not clear and how the output was affected is up in the air thanks to the lack of direction mentioned in the article. I do think Post Formats have a future, but it should not be as a core feature.
I’m inclined to think that yes, they should be in WordPress core. Travis raises a good point: they’re not necessarily FOR blogging if you don’t use them as posts on a blog.
If some variant of the Post Formats UI is implemented en masse the way it was, it’ll make the UI into a blogging-only solution though. It completely ignores users who don’t blog but do other things. It’s a question of what the base model should offer and how much it should cater to a specific user group.
I never really understood why post formats were separate from post types. Post formats were basically different types of post content and post meta which should have been separated into different post types, but for some reason got mashed together with posts. My image of post formats would be as such:
– They be turned into post types akin to posts, each with their own custom interface designed for their type of content. Take the main post formats, rip them out of posts and make them their own types
– They would be completely optional; there should be a setting that allows you to turn off the post types you don’t use.
– Picking what post format you want should be done on the dashboard, not on the new post page. Have a new dashboard box that asks you which post format you would like to start with.
– They should have the option to whether or not they appear in the main loop. Those who use asides would love this.
– The UIs should be extensible. This would probably tie in with the new Post Meta UI initiative that’s going on. A developer should be able to create their own custom UI for existing and custom post formats
– The post format moniker should die a horrible, horrible death :p
I’m on the fence on whether post formats should be core or not but mashing them all into posts was a bad move, tbqh. Having the default ones be custom post types would make more sense.
We’re on the same page Manny. One of the many things that continues to confuse people is that Post Formats are restricted to the established ones. This makes sense from the point of view that the feature is supposed to be supported the same way across all themes. But then there is no definition of how this support is supposed to look and little direction so the restriction seems largely meaningless. What’s needed is custom post templates and I think that’s what you’re calling for too.
I definitely agree that post formats should be moved to a plugin. And taking your question one step further, I also think commenting should be placed into a plugin as well. Since commenting is purely a blogging feature, and most users are no longer using the platform just for blogging, it makes sense to me to remove it from core and into a stand alone plugin. I have dozens of small business clients who use WordPress as a CMS, but don’t, and never will allow commenting on their blog posts. Thoughts?
IMHO, the only thing Posts Formats really need is a defined data schema for the content types (so that Theme developers have a consistent way to implement the feature). After that, a good UI would help improve adoption/use of the feature.
I don’t buy the “blogging only” argument. Let’s take that to its logical conclusion: Post Format is simply a taxonomy that is registered only for the “post” post-type. But post_tag and category are also taxonomies that are only registered for the “post” post-type. Should those also be moved to a Plugin? Or how about the entire blogging feature? Should it be moved to a Plugin?
And then a comment that the comments feature should also be moved to a Plugin.
There’s a CMS that takes this approach; it’s called Drupal. Nothing against Drupal, but I don’t think that WordPress needs to emulate its modularized-ad-infinitum design philosophy.
And while there’s certainly a valid argument to make for Post Formats being a poor-man’s CPT for the various content types, I disagree that Post Formats are useless to non-blogging applications of WordPress. In fact, Post Formats can actually make the “post” post-type useful to sites that don’t have blogs. Think of using quotes for testimonials. Or galleries (as galleries). Or videos as tutorials. There are lots of non-blog-specific applications for Post Formats.
I also disagree that Post Formats in their current state aren’t beneficial to Theme developers; the number of Themes integrating Post Formats in interesting and awesome ways continues to rise, exponentially as of late.
(Side note – pet peeve: I cringe every time I see the phrase “use WordPress as a CMS”. WordPress is *always* used as a CMS; WordPress *is* a CMS. Even for lowly bloggers, blog posts are *content*.)
One point on which I very much agree: the lack of a defined data schema for content types is the single, biggest hindrance to developers finding creative and innovative ways to use the Post Formats feature, which in turn directly impacts the degree to which use of the feature is adopted by end users.
I think we are in agreement on pretty much everything here Chip. The problem with Post Formats as they stand is the lack of a schema and undefined user scenarios. But introducing an extended UI with more functionality will force sites that don’t use or need these features to address them in some fashion. And as a core feature it will be forced onto existing users and require extensive training. Just imagine an enterprise deployment with a custom setup and thousands of users. When a Post Formats UI suddenly appears after a core update all those users will be confused that the feature does not work and have to be retrained.
As for the distinction between bloggers and “CMS users” this is a distinctions between those that use the site specifically as a blog and those that use it as a site management tool. There is a significant difference and while bloggers manage content, they do not use WordPress as a content management system.
Isn’t this solved by
add_theme_support( 'post-formats', array( 'aside', 'gallery', etc. ) );?If I remember correctly the UI appeared even when no theme support was present. This might have been an oversight in development but I distinctly recall talk that the UI would be “permanent” and not something that could be disabled because the intention was for Post Formats to be an expected feature.
Right now seems it cant be override in functions.php. So with all new updates i lose my post formats. Easy to fix, but whole WP gallery i can override, why not post formats and post-formats.php file ?
I know we have 7-8 of them, can rename them and use own code. But with many websites it gets confusing with all those generic PHP file names in themes. I would like to use my own files in themes and to know exactly what they are about when i copy code (or reuse parts of the code) from one website to another.
On the theme development side post formats are just conditional statements with a couple of dedicated function hooks. You’ll often see something like
get_template_part( 'content', get_post_format() );in a theme. This will get the content from a file called content_$post-format.php (so content_image.php or content_quote.php etc) depending on the post format of the current post.I understand where the post formats were comong from, but their implementation so far has been pretty lackluster. I’ve just finished a new premium theme that uses them, and development was pretty hellish since you’re practically left to your own interpretation when implementing them.
My biggest pet peeve though, is that they are a fixed set of formats and a developer cannot create new ones or modify existing formats to better suit a theme. For example, what if I want to add a Slideshow format? Or a map format? Either I’d have to hack them so offer new functionality, or implement these new styles on my own.
Worse yet, is that they are basically the same thing as page templates, yet they’re much more cumbersome to implement and much more limited. As Chipp said, I don’t think WordPress needs to be Drupal-ized, but the current implementation is really lackluster. Putting them more in line with templates would be more consistent and flexible, plus the added benefit of using the template hierarchy.
I’m working on a new theme too and I’m having a hard time figuring out how to interpret the post format specs in a generic way. It’s actually worse than the W3C spec because there are no examples or best-practice instructions.
Coming from a blogger’s perspective I sure hope they get this figured out. I like to frequently change themes and the lack of standards in the implementation of Post Formats REALLY makes it a pain to use other theme developers themes.
Post Formats is too limiting. As a blogger I should be able to choose the formatting to my own liking. Why do I have to use a theme designers format (standard, Post Formats or otherwise) that he interprets.
For example, lets say company policy dictates all Posts be formatted in a particular manner.
Our company policy is as follows:
*********************************
Date – Who, what and where. (in that order, no more than 3 lines)
Photo(s) (first post photo must also be inserted in featured image) or Video or Quote or Gallery
Story
Author
***************************************
As lead archivist, I should be able to choose the formatting for Posts iaw company policy and then ‘lock-down’ the format so that all Posts are formatted consistently throughout the site.
Not sure if this is pertinent to this subject but, I have very strong feelings about Post formatting since it is a daily pain we editors must deal with day in day out.
Story
I completely agree with the post. If we look into WordPress core, we’ll see that Post Formats is just a custom taxonomy, i.e. it’s just a way to categorise or differentiate posts (with some helper functions). That feature can be plugged out of the core and if user needs it, they can just plug in!
Also I’ve been confused with how to use data for post formats. 100% agree with “lack of definition”! Not only image as in the post said about, but gallery and video also a problem too, even quote or link formats. We don’t have “standards” for post formats right now, and each theme implement it in its own way!
If WordPress separates the Post Format into a plugin, and recommend it to all developers with a consistent styling and organising data, that is a really big improvement for Post Formats.
Nice part of WordPress. But i personally dont have much use of it, and stopped to use them. Only because i cannot use my filenames in post formats templates. One-two websites, and copy/paste goes well. But as numer of websites increase i dont know where is my ass anymore. Difficult to maintain and reuse code. All filenames are generic. I cannot for instance have my own post formats templates “content-team.php” or “content-events.php”.
Maybe there is some unnatural tweak to bypass it, but i could not find it.
Strange, much of it goes to filter in WP, but not this part of post formats.