It’s time for me to hold a funeral. Actually, many funerals. I’m saying goodbye to post formats.
Post Formats were introduced in WordPress 3.1 as a way to display posts in different ways depending on what the focus of each post was. For example, if you’re posting a video, there’s a video post format which can be used to put the video front and center and show it off in a different way than if it were just contained within the post content itself. There are 9 different post formats supported by WordPress (aside, gallery, link, image, quote, status, video, audio, chat).
I embraced them, as I loved how the feature worked in Tumblr, and thought that it was a perfect addition for certain types of sites, primarily personal blogs, where one might post all different sorts of content.
I used them on all of my personal sites and also put them to good use on my daughter’s website, because I was frequently adding images and videos of her, as well as links to other sites which had good articles about things that matter to our daughter. It was a good fit for a while.
But then came the inevitable: I wanted to change my theme.
Anyone who has jumped on board the post format bandwagon and tried to change their theme has undoubtedly crossed this bridge before. As for me, I knew what was coming, but most other users are probably completely unaware that as soon as they change their theme, all of the post format metadata that they had entered over time will no longer be used and their posts will look nothing like their former selves. This is because theme authors never had a standardised way of adding post format metadata to their posts (like the featured video’s URL, or the main link that you’re talking about), so everyone came up with their own. As such, when you change themes, the post format data won’t match up with the new theme, so the new theme doesn’t know how to display your post format any more.
This was the reasoning behind the proposed Post Formats UI feature, slated for 3.6. If you’ve been around that long, you may remember that the feature was pulled at the last minute, causing a lot of rework (pulling code out of the codebase) and being the driver for the new development method of “features as plugins“.
The idea was to add a section to the post editor where you could select the post format you wanted to use, which in turn would provide you with standardised fields for entering your post format information. Because this feature was going into core, it would always be active, and would be portable from one theme to the next, thus ending the major issue of portability.
However, the feature was axed, so it was back to the status quo of each theme author coming up with their own way of adding post format metadata and each one being incompatible with the next. There have been attempts to overcome this, such as Crowd Favourite’s Post Formats UI plugin (on which the WordPress core feature was modeled), but these haven’t caught on very well.
Being locked in to a theme is a big obstacle to WordPress’ user satisfaction and further adoption. It’s one of my bigger annoyances with WordPress and is the reason that I’ve dropped support for the feature altogether. I spent the last few weeks going back through my posts and turning them all into standard posts, formatting them how I want. Fortunately, I “only” had 400 or so posts to go through, but many others are not quite so lucky. People can’t be expected to revise all of their posts to transfer metadata from one format to another, nor can they can be expected to edit the theme themselves to match the new post format meta keys and/or implementation in the theme.
And theme lock-in is not the only issue. Consider emails (maybe from MailChimp or Jetpack) for new posts. Or RSS feeds. Without writing functions to change how the post content is displayed in these formats (where that’s even an option – it isn’t in Jetpack), they will just typically display the post content (ignoring the post format information) as a catch-all for not knowing what the post looks like (this again goes back to not being able to write a common function to account for how every theme developer has implemented post format metadata).
This results either duplicating information (adding the video’s URL to the post format meta, which will automatically display it above the post for example, while also including it in the post content, so that it is accounted for when viewed from an RSS feed or an email, resulting in the video showing up twice on the site) or receiving emails / reading RSS items which don’t make any apparent sense, because they’re missing the main component of the post (whether that be the video, the image or the link that you’re discussing) because on the site, that information is displayed by the theme from post meta, which is ignored by emails and RSS feeds.
In its current form, post formats are, in my opinion, relegated to companies with large budgets, who can afford to have custom themes built every time they iterate their site, or developers, who are comfortable enough to edit the theme to incorporate the different post format meta, assuming that they have enough time to do that.
It also seems that WordPress is resigning to the issues of post formats as well. The new Twenty Fifteen theme looks gorgeous, and I’m already using it on three of my own sites, but they’ve approached post formats in a bizarre manner. The theme adds support for all 9 post formats, but the only post format which displays the information any differently is the link post format (which retrieves the URL from the post content using the new get_url_in_content() function and links the post title to that link instead of the post permalink).
That is to say that for every other post format, the post content looks exactly the same whether you mark it as a video, image, gallery, quote or standard posts. I don’t know why WordPress has done it this way. Initially I thought it might be so that theme authors could write their own post format templates in a child theme (acknowledging that they wouldn’t have a clue how to show existing post format metadata because it’s unique for each former theme): but then, they could activate the post formats in the child theme anyway, so why bother activating them in the parent theme when you’re not going to add the templates to go along with them?
Brian Krogsgard also prophesied about the demise of post formats a few months ago and up until then, I was still hopeful that they would find a new wave of love and get the support they need. Instead, I acknowledged that he was probably right and gave up on the idea of using them.
In trying to allow theme developers to be flexible by leaving it up to them on how to store and implement the metadata that went along with post formats, WordPress inadvertently made post formats virtually unusable for anyone who ever wants to change their theme. I think it was a mistake to not have standards when the feature was implemented and I think it was an even bigger mistake to not follow through on trying to standardise when we had the chance in 3.6. I fear that we’re probably past the point of no return and endless frustrated users are giving up on them (and maybe WordPress altogether) because of this frustrating caveat that goes along with using post formats. Hopefully I’m wrong and I can embrace them again, but only once I’m sure that they won’t be a barrier to developing my site with ease.