The Post Format Makeover

There has been a lot of talk recently on the state of the post format in WordPress. Added to WordPress 3.1, post formats were a way to differentiate ways of displaying posts: an aside is a short form style post, a link post format would be, well, a single link and so on. WordPress’s post formats were added to mimic Tumblr’s similar feature. The basic idea was that a post would be given a format and a theme developer would create a special way to display that format on archive and single pages.

In 2013, during the development of version 3.6, a initiative was put in place to bring post formats to the forefront on WP’s admin side and give them a proper UI. Before this, the only indication that post formats existed was a meta box on the sidebar that allowed you to choose the format of your choice. Development was done to try and have the UI of a post edit page change whenever the post format changed. Unfortunately, the feature never made it to the final version of 3.6 and Mark Jaquith, one of the lead developers for the project and WordPress proper, decided split the UI project into a plugin do to a consensus of the developers working on it.

The Problem with Post Formats

A lot of the talk that’s been going on since then about post formats has been their usefulness and whether or not they belong in WordPress’s core code. Morten Rand-Hendriksen has an interesting opinion piece on why the feature should be relegated to a plugin. His case is that post formats are too niche a feature to include and that there isn’t a clear definition on how they should be rendered to begin with. Although I agree with some of his argument, such as there not being any focus on what they are, I disagree with it being separate from the core. My main issue with post formats have been that their implementation needs a lot of work.

Post formats have always been a little confusing to me. Although I don’t think I’d ever use an aside, I can see other bloggers using that style of post. It always seemed like post formats were a distinction without a difference. The post format is basically a weird layer of distinction on the post type that I think shouldn’t be there, at least where it is currently residing. Currently, post formats are terms of a semi-hidden taxonomy primarily in the post type. Looking at the blog posts that heralded the coming of this feature in 2010, its main hook was that it gave template developers and designers a standardized way of displaying types of posts. The only problem was that we had ‘types’ of posts: the custom post type.

To me, post formats are types of content, each with their own types of data and meta data: asides only have text without a title, a link post would be just a link with a description, an image post’s content is an image, etc. In a blog post trying to differentiate between post formats and post types, Mark Jaquith stated that post types should have been called content types and were not post content, where as post formats were akin to sub types of proper posts, ie content that belong in the main feed. I personally feel that this is a weird distinction; to me they are all content type and therefore all should be post types.

The Alternative

I think that post formats could be useful to a lot of people, but I think that some changes need to be made in order to both stop some confusion and make them easier to work with:

  1. Post Formats should be default post types: Just like WordPress comes with posts and pages, I think that the 9 post formats that are currently just taxonomy terms should be upgraded to built-in post types inside the WP core (or plugin, whichever you prefer). I think this would solve a few problems. It would would add some distinction between the formats and it would allow each of them to have unique their own unique UIs, separate from posts. Theme developers would just need to create post type templates for these new types.

  2. They should be optional: not everyone wants to use them and we should respect that. There should be a way in settings to allow users to disable individual post formats so they can use the ones they want without the others clogging their sidebar. A user that only wants posts and asides should be able to have just those types.

  3. They should be allowed in the main loop, if you want: I think one of the main reasons post formats were implemented as they were as a ‘type’ of post was that they showed up in the main loop/archive/feed of a site. Separating them as post types would, by default, both give them their own feeds and remove them from the main one. There are coding tricks to add them back, but I think there should be a standard setting in the admin UI to allow a user to add whichever post type they want into the main loop. Giving a user a choice gives them control to either add those image posts in the main feed or have them have their own feed. Of course, I think this should be extended to all custom post types.

  4. Rework the Quick Draft dashboard widget for post formats: The UI that was proposed for post formats for WordPress 3.6 had one big glaring flaw for me: it was in the wrong place. The basic design was a bar on the top of a post edit page that allowed you to choose your post format, which caused the page’s UI to change. The effect was cool but it confused some of the usibility testers, who thought the bar was a way of inserting content. I think that UI should be included in the Quick Draft widget on the main WordPress dashboard. My idea would have the format icons front and center; when a user clicks the format they want, the inputs of the widget would change and a user could either post the content then and there or click the edit button to bring them to the edit page.

  5. They should be extensible: Each of the post formats have different sets of data/ meta data and by extension different sets of fields dependent of the format. A developer should be able to take a post format and create a post type based on that format, like how PHP classes can be extended from other classes. This is something that I think should be combined with the new meta box/field features that are coming to WordPress 3.9/4.0; having the fields and meta data tied to a post type will allow developers to create and extend post types based on the existing post types and create/extend UIs of their own.

  6. They need to be defined more strictly: Right now the structure of the current post formats are loosey goosey. They define basics on what they are but don’t give specifics on how to display/ implementing them in themes. I think there should be specific standards on them in the future, especially when it comes to their meta data.

Closing

That’s my take on the post format situation. I think that they could be a great way of enhancing the blogging experience with WordPress and at the same time give developers some tools to make WordPress a better CMS. I may start working on a plugin that showcase my ideas soon. If you agree, disagree or hate my ideas, feel free to comment below.

Removing the Slug in a Custom Post Type Permalink

For a long time, having a slugless permalink aka a postname permalink was a luxury feature that only posts and pages in WordPress shared. Though the performance issues that plagued using the postname permalink was resolved with WordPress 3.3, it was still sort of tricky to implement it. I found a few tutorials online but I decided to find my own way of doing it.

  1. Create your post type. Simple enough:

    function event_activate() {
    /**
    * Register a custom post type, set rewrite to false
    */
    view raw sluglesspermalink hosted with ❤ by GitHub

    Notice how I set rewrite to false. This disables rewrite functionality, which is okay, because we’ll add it next.

  2. Add your permalink structure:

    /**
    * Set the permalink structure
    */
    view raw sluglesspermalink hosted with ❤ by GitHub

    This will add the permalink structure for your post type. First argument is the post type name, second is the permastruct, which WordPress will use to create permalinks for your post type.

  3. Resolve the conflict with post and page post types:

    }
     
    add_action( 'init', 'event_activate' );
    /**
    * Make the permalink work by setting post types when none are given
    */
    function parse_event_query( $query ) {
    $post_name = $query->get( 'name' );
    $post_type = $query->get( 'post_type' );
    if( ! empty( $post_name ) && empty( $post_type ) ) {
    view raw sluglesspermalink hosted with ❤ by GitHub

    The tough part to figure out. You notice that if you only did parts one and two, WordPress would give your new post type links but the links would 404. The reason? WP doesn’t know what post type to query for when it is given only a post name, like our permalink would resolve to. When all else fails, it’ll default to post and with that, won’t find our custom post.

    The solution uses the parse_query action to check all queries for two conditions: whether a name is being queried (ie name is not empty) and whether a post_type is set. If there is a name but not a post_type, the function will set post_type as post, page and our custom post type. Refresh your permalinks and the link should now work!

The only issue found with this is (thanks to Simon Blackbourn of wp-hackers) that if you happen to have a post or page of the same name, both will occupy the same page. Trashed posts of the same name will cause 404 errors until you delete it.

If you’ve found any flaws to my technique, please let me know. Feedback is appreciated!