I’m going to make a confession I actually like Post Formats, not the silly implementation made as part of an ill-conceived and bolted attempt to appeal to get tumblr users to WordPress.com but the post formats of the future the ones where they actually are useful.
Post Formats have had a pretty ugly existence since their conception in some seedy back-room IRC they have pretty much divided the community like nothing else.. except the Customiser and automatic updates oh and Distraction free writing. Ok so they have been one of â€œthoseâ€ features.
Recently there has been some movements to kill off post formats, and while I suspect many would favour the beheading of them, I would like to take the time to think about what could have been.
What are Post Formats?
Not every blog post you write is going to be the same, some might be long meandering, artwork heavy tales, others short and punchy pieces. Different styles of content might work better with different theming, typography or visual layout. These posts still share the same basics a title, content and share a common taxonomies they are both â€œpostsâ€ in the same loop.
The difference really is in how we want them to look or perhaps more interestingly in the semantic markup of how we describe them.
That’s what post types are a way to differentiate â€œpostsâ€ visually and maybe semantically where there would otherwise not be any differences.
What are they really
Here is the dirty secret, Post Formats are nothing more then a hidden taxonomy with an API wrapper. Indeed while the API wrapper has been designed to deliberately prevent you from adding your own custom post formats. The taxonomy has the â€œofficialâ€ post formats hard coded, but like all taxonomies it’s terms can be manipulated. From the theme side, the taxonomy of post formats is filtered, using the theme supports function to let WordPress know which post formats to show in the write/edit screen.
A lot of themes, and developers already create a sort of custom post format, it’s quite common to see theme designers create a custom taxonomy which is used to determine visual styling, without realising it replicating a large portion of the post format code that already exists.
Page Templates or Post Formats or Custom Post Types?
So let’s take an example of where we might use a Post Format (all be it a custom one) and use this site.
This site can be split into a few general posts (note I’m desperately avoiding the word types for now)
- Pages â€“ these rarely change, outside of the loop and contain stuff like About, Privacy Policies and contact forms.
- Long Form Articles â€“ Articles over 3k+ words, generally quite technical in nature and to be honest rarely read
- Blog Posts â€“ Your traditional affair, top x in y or editorial pieces
- News â€“ Relatively time sensitive stuff
- Videos â€“ Nearly always the video content is actually Youtube based but each video post has additional information and eventually transcripts.
So we have 5 different post like things, which we could easily break into two groups Pages & Posts based on are they in the main loop or not. Of the Posts Videos are a potentially special case so we can ignore them for a minute.
For the pages, page templates exist to perhaps remove the sidebar.
For the 3 traditional posts, our news, Long Form and Blog posts, there is no real difference between them. Yet each is quite distinct.
Imagine the site had 3 Post Formats:
- Blog Posts â€“ Standard post format
- Long Form
Each post format could be styled differently, and could be marked up using the correct schema.org semantic markup. Yet for all other purposes these posts are identical.
What about video?
So even though Video is a type of post, the reality is you will probably want to make it a collection of custom post types, the Video post type, which contains the descriptions and the video location in the post meta and a second post type for transcript, containing a transcript of the video, linked to the first.
I would treat video as a custom post type as opposed to a post format because it contains this extra meta data. The irony that in my example I have chosen to show video as a Post type when in the current implementation it is a post format is not lost on me.
For me a post type should be used when one of the following occurs:
- It requires a separate or distinct taxonomy
- It has multiple custom meta
- It no longer sits within the main loop
- It requires different permissions to manage content
If the difference is purely a visual one then a custom post format maybe more suitable.
Creating your own Post Formats
While I would like to see changes to Post Formats, you can add your own custom post formats today though it does feel like a bit of a hack.
The current Post Formats API is basically missing a single filter to make it useful, unfortunately a couple of attempts have been made to add this filter which have met resistiance. Consequently to add a new term into the post format taxonomy requires repeating a lot of the existing API to reach the same point to add the needed filter.
Couple of years a go I wrote a little plugin that did this Additional Post Types and put it on Github, I have been through and updated the plugin and tided it up a bit for this post.
To use it, simply install as a normal plugin.
To add new post formats you need to declare it to the brilliantly named filter:
$new_post_formats = array(
'example' => _x( 'Example Additional Format','Post format' ),
'example2' => _x( 'Second Example','Post format' ),
This adds two new custom post formats to WordPress, however a theme can’t make use of them till it adds theme support, in exactly the same way as it would do a â€œofficialâ€ post type:
add_theme_support( 'additional-post-formats', array('example','example2'));
The result, you can add post formats as you see fit, though you can’t get the nice pretty icons.
The useful future
Post Formats were ill thought out, badly implemented and an example of when perhaps commercial interests forced through features before they had matured. The sad thing is custom formats have never been loved, yet actually could have a place within WordPress and become an integral feature. They just need some love.
As we move into a new world of API first, the post format is in danger of becoming even more irrelevant but this new world could be it’s salvation.
Presentation Separation in our API world
With the REST API becoming increasingly popular and almost certain to land in core â€œat some unspecified future point, maybe 2018â€ it’s worth starting to consider how we markup and style the humble post. One interesting issue, is the average blog post contains a large amount of HTML markup, which is fine when you are rendering it to a web browser. However the REST API means our humble blog posts might not just be living in a HTML world and instead be found across a multitude of data stores and presentation layers.
Therefore it’s in everyones interest to limit the amount of hard coded HTML sitting in posts. For me at least a lot of this hard coded HTML has historically been related to styling â€œpostsâ€ to look different from other posts, a role that a custom post format could have in part helped with.
Post Formats might still have a place in a API world, with a little tweaking.
Let’s make post formats useful!
The might not be interesting or cool, and they may be mocked but Post Formats could have a future, if people are willing to give them a second chance. If we open up the Post Format API and admit that the â€œofficialâ€ formats are not quite fit for purpose.
For me, post formats make more sense then page templates and if we open them up and give them the flexibility they could easily replace page templates all together. Helping to continue to standardise posts within WordPress.
So what do you think, should we save the post format or kill them in the fiery pits of hell?