WordPress Post Formats Admin UI

The Post Formats feature that landed in WordPress 3.1 is a great framework feature. I’m leveraging it extensively on this site to drive my link, status, photo and gallery posts.

While it is a great framework feature, it only really exists as something developers leverage to extend WordPress. There is no UI that ships with the feature, which limits its accessibility to users.

My team and I have been working on FavePersonal (the theme you see here) for a while, and one of the features we’ve built is an admin interface for post formats.

We have released this code on GitHub (pull requests welcome) and encourage any and all theme developers to use it, add to it and improve it.


Here are some details on how it works.

The plugin is a completely additive solution that leverages the default WordPress functionality, while improving the UI and standardizing the names and presentation of custom fields that support the various post formats.

A set of tabs are added to the post authoring screen that allow users to select the post format they would like to use. The built-in radio button interface is hidden, and the tabs simply control the selected radio button.

Standard Format

Status posts are treated as “content only” – similar to the short form seen in Facebook status updates and Twitter’s tweets. Behind the scenes, a title for the post is set using the first 50 characters of the content.

Status Format

Link posts have an additional custom field (_format_link_url) for the URL of the website/page being linked to. This URL is then utilized in the theme to implement linking directly to the external site from the title link (if desired).

Link Format

Image posts utilize the WordPress built-in Featured Image functionality. The Featured Image is treated as the image for the post, and the theme displays it accordingly for this post format.

Image Format

Gallery posts display the WordPress gallery in the tab so that it’s clear that these items will appear with the post. The theme then implements the gallery view based on the post format.

Gallery Format

Video posts have an additional field added for embed code or an oEmbed URL to be added. This information is stored in a custom field (_format_video_embed). Then the theme can use this to display the video in an elegant way.

Video Format

Quote posts have two additional fields. One for the name of the person being quoted (_format_quote_source_name), and one for an attribution link (_format_quote_source_url). These can be used in the theme to present the quote and attribution in a consistent manner. Similar to status posts, a title for the quote is created behind the scenes from the first 50 characters of the quote.

You’ll notice that we have adopted a consistent naming convention for custom fields used to support post formats. That convention is:

_format_{format type}_{descriptive data name}

The underscore at the beginning of the key prevents the field from showing up in the default Custom Fields interface (since we are managing it behind the scenes) and the rest is set up to logically describe the type of data being stored.


We look forward to releasing our theme in the near future, and hope that this code will be widely used to help bring adoption of post formats in a way that is truely portable between WordPress themes.

Several people I’ve shown this to have asked if I’d like to see this adopted in WordPress core. Yes, of course! I had an interesting conversation with Ian Stewart about this at WordCamp SF this year. He had some reasonable concerns about the data being stored in custom fields not being portable to themes that don’t implement post formats; while acknowledging that having the data in a structured format (separate fields) was very valuable for presentation purposes.

One possible solution we discussed would be the addition of core functionality that would look for these custom fields and post format support, and would auto-prepend/append the custom fields to the content accordingly (add the featured image, gallery, quote attribution, etc.). A solution like this is definitely preferable to requiring all of the data to be present in a single content field.

UPDATE: see my follow-up on this.

This post is part of the following projects: Post Formats Admin UI, FavePersonal. View the project timelines for more context on this post.