WordPress Post Formats: The Good, the Bad, and the Ugly

WordPress Post Formats: The Good, the Bad, and the Ugly

Microblogging gets a nod from WordPress core team

When I first saw the post formats feature in the works for WordPress 3.1, I was in the middle of building a live action scavenger hunt site based on the P2 theme. P2—a microblogging theme—makes it easy to add short posts to your blog from the front-end, classifying them as “Status update,” “Blog Post,” “Quote,” or “Link.”

Post formats work for me

Post Format stylized set of icons for various content types
Post Format icons suggesting the mainstream content types used by microbloggers

I thought “Wow, this is going to save me some custom coding on my tumblog-style site!” I needed to add support for video and images folks would upload as part of the game. Post formats would allow me to classify a post as one of the following:

  • aside
  • gallery
  • link
  • image
  • quote
  • status
  • video
  • audio
  • chat

Developers narrow their eyes

It struck me as odd that something so narrowly targeted would be included in WordPress core. Historically, WordPress core presented a solid base of APIs that plugin and theme developers extended to make the web a more wonderful place with shiny new features for end users. Post formats seemed more fitting as a plugin than as a core feature.

I see what you did there

The original 4 formats in P2 were implemented as categories. Why couldn’t these additional format types just be added as categories? I raised an eyebrow slightly as some other questions lingered faintly in my mind, but my enthusiasm for all things microblogging won out. Post formats were good for me.

No good deed goes unpunished

Post Formats angry mob of lego people descends upon the post formats Codex page
Post Formats misunderstood by developers

Little did I know, the post formats feature was about to open a whole can of worms on WordPress TRAC during development and in the WordPress developer community as a whole after 3.1 launched.

It turns out the original idea for post formats was to create a page in the WordPress Codex simply suggesting the creation of a custom taxonomy for a standard set of post formats. The goal: post formats people could reliably use without fear of losing content classification between theme changes. WordPress heavy Andrew Nacin later expands on this to suggest post formats were intended “for a segment of bloggers” and “themes used for microblogging.”

It’s not you—it’s me

So, if post formats only fill a specific role for microbloggers, why was there so much backlash from the community at large over the feature’s implementation—namely, the limited list of formats with no tools to add custom formats? I mean, if you don’t care about microblogging, then just move along, right?

From suggestion to cool blue code

First, let’s understand why post formats evolved from a page of documentation to an official part of WordPress core. The suggested post format custom taxonomy would not work for everyone, as some users might be using other custom taxonomy terms whose names collided under the hood. Therefore, universal standardization of post formats from a simple Codex suggestion could not really be universal. The suggestion would quickly lose staying power, if it was ever taken seriously at all.

How could the team make this standard list of microblogging-related post formats available for all, then? Simple. Just lock down the namespace used for post formats. To lock it down, however, the team had to put some code behind their intentions. That’s where the trouble started.

Upsetting the status quo—and developers

WordPress developers are used to the WordPress team releasing tools that present wide-open possibilities. When they saw post formats, they undoubtedly threw the feature into the same brain basket as Custom Post Types and Custom Taxonomies—both of which can be extended at will. The problem is, they were only half right.

Post formats are more like a child of Custom Taxonomies. The core functions added for post format functionality are simply a hard-coded custom taxonomy with tools to make it easy to use. Unlike most of the API, post formats were never intended to be extended.

Slippery slopes go both ways

Kudos to the core team for not bowing to pressure and allowing custom post formats. Custom formats would negate the very reason the function came to be: a future-proof way to classify content. Had the core team caved, post formats would be nothing more than an official custom taxonomy littered with willy-nilly terms dreamed up by well-meaning site managers. Theme developers would find no value in such chaos.

On the other hand, adding too many features like post formats in core threatens to give the core team enough rope to hang itself with. If they add special functions for microblogging, then what’s next? Special libraries for responsive theme building? Most would argue that is the domain of theme developers, not core.

An exception of the rule

Post formats are, as Nacin says, “an exception of the rule.” I don’t think we’ll see a lot of exceptions like this going into core. The core team—as a whole—makes well-balanced decisions.

I do think post formats were a prudent move, as the WordPress team realizes the power and place microblogging has in the blogosphere. Post formats are a tip of the hat to microbloggers and theme developers using the likes of P2, PulsePress, WooTumblog, Pink Touch 2, and more to keep the web world up to date.