WordPress puts food on my table.

Post Formats vs. Custom Post Types

Some people are confused about the Post Formats feature that will be made available to themes in WordPress 3.1, especially how it differs from Custom Post Types.

Custom Post Types

These were poorly named. Think: Custom Content Types. That is, non-post content. Examples: employees, products, attachments, menu items, pages, pets. If you want it to show up in your site’s main RSS feed, then it’s probably not a custom post type.

Post Formats

A Post Format is a formatting designation made to a post. For example, a post could be a short “aside,” or a Kottke.org-style link post, or a video post, or a photo gallery post. The data you input might be slightly different — video post should contain a video, an aside should probably not be very long, a link post should have a link. And the way that the post is displayed on the site might be very different — an aside will typically be displayed without a title, a link post may have the title point to the link. A video post may be wider, or have social sharing buttons auto-appended. But they’re all still posts. They still show up in your feed, and you still find them in the Posts section of the WordPress backend.

The important thing to note about Post Formats is that they are going to be a standardized convention. So any theme that supports Post Formats and follows the standard will display your posts in a way that makes sense. Before, themes had to set up category-based conventions, and these conventions weren’t shared by other themes. This is a better way of handling that, and it should make it even easier to switch between themes than before!

Themers should turn to the Post Formats page in the Codex for info on implementation. Note that we’re not yet in beta, so expect this page to change a bit.

Could Custom Post Types make use of Post Formats? Picking up on some of your examples:
-Employees: Different formats for different departments or levels of employee.
-Products: Different formats for digital vs physical

I can see the value in having standardized formats as it relates to themes where WP = CMS and wanting to offer much stability for those scenarios. But please give API accessibility equal consideration for the rest who could leverage this in other ways.

They could. But there’s not much of a point, since the benefit comes in standardization. With Custom Post Types, you likely have specific support for it in your theme. They’d be just as well off by creating a custom taxonomy.

I agree that CPT were poorly named, but why wouldn’t it be changed now?
– CPT are still fairly new
– people knowing about CPT are mostly devs who keep up current with WP development, so they’ll know if it’s renamed
– there have been much more important name changes in the past (theme / presentation for instance)

It doesn’t take long for someone to understand that there is a different between “Posts” and “posts” assuming we just make sure to explain it to them. Changing names means creating “Content” on the outside yet “Post” on the inside. That’s what they did with Drupal and “Nodes”; it created far more confusion than it is worth.

That an explanation is required to make people “understand that there is difference between “Posts” and “posts” ‘ cries confusion. Every now and then WordPress does something that seems to lack foresight. Don’t get me wrong, I LOVE WordPress (so much so that even capitalise the “P” in type). But if even Mark is saying CPT were poorly named – let’s change it WordPress.

@Thao – It may seem to have lacked foresight but it wasn’t without a lot of thoughtful discussion and debate. Ultimately the consensus was that “post_type==’post'” was the *least* problematic option. You can read most of the debate here:

Thanks for that link Mike. There sure were much bigger brains with much greater foresight (than mine) in long discussion over it. I expected there would be much (discussion) on it.

Looks like Post Formats will be a big winner anyway. Wonder if they could’ve/should’ve preceded CPT’s?

I still think WP needs the ability the edit the “Posts” label in WP Admin (label ONLY!). This would allow for much better understanding for end users. It is dumb that every time you build a site for a client who is a total WP and/or CMS noobs, you have to explain what a post is, and why they need to change their way of thinking to adapt to “posts” mentality. That is NOT a flexible CMS WordPress.

For these people “Post” is an entirely foreign word with ZERO meaning or context. It should be WordPress that is adapting to their existing understanding, and/or environment.

If they’ve got a small business website with 5 pages and a “News” section (posts), allow us to edit the “Posts” label to “News” and they’ll know what to do. IMMEDIATELY. News > Add New

If they’ve got an educational website and their publishing mentality is for “Articles”, allow us to edit the “Posts” label to “Articles” and they’ll know what to do. IMMEDIATELY. Articles > Add New

It doesn’t warrant any table name changes. All it does is modify the backbend label for flexibility.

@Thao – It’s already completely possible to change the labels, and it’s not too hard. Here’s a screenshot showing that it can be done:

And here’s the code to do it (put in your theme’s functions.php file):

You can probably also just remove the “post” post type and add in a custom post type of “News Item” but getting that right would take me longer than the 10 minutes the above took, and both will probably work.

Of course there may be something else that you’d need to do to make this work perfectly; I’m sure Mark will chime in if so.

BTW, if you don’t want top code I understand that are also existing plugins that will allow you to sculpt the labels for both post types and menus; have a look around the repository and I’m sure you’ll find all you need.

1. Does each individual theme get to style each post format on its own?

–everyone has a different taste in what a post format should look like.

2. Does each individual theme get to decide which custom fields and taxonomies belong to each post format?

–example video: It is very important to me to allow the user to input the author, location, topic, series, etc of each video. May not be to you, but who decides?

If I create custom fields or taxonomies that belong to a specific post-format, those don’t transfer between themes, so what is the point? seems rather limiting compared to post-types.

3. Are there separate template file locations available for the archives of each post format?

I have nothing against post-formats, as this is the first I have ever heard of them. I guess that I just don’t understand why I would want them when post-types gives me complete control over every aspect of my data set, both information content and display.

Hehe, as ever, a great new feature in a release scheduled for a couple of weeks after the launch of a project I’m working on that it’s ideal for!

The Backwards Compatibility section seems to suggest that this is just an interface for a “built-in” custom taxonomy? So, looking at “forwards preparedness” rather than “backwards compatibility”, could I just get going with this feature using a custom taxonomy? Then when 3.1 comes out, switch off the taxonomy code in my theme and add support for Post Formats? Would I just use conditional code in single.php, or will the templating system be affected, e.g. you’ll be able to create single-aside.php, single-link.php etc.?

This is a step in the right direction and a great new featured. Thanks for explaining Mark.

Our philosophy has always been that wordpress is much more than a blog and really functions well as a full CMS system. We’ve been using a combination of category specific templates in combination with custom fields to drive all sections of our site. Whether it’s our press section, testimonial section, gallery, video section, etc…it’s all driven by wordpress…

Post Formats will be a convenient addition: like lotsa others, we’ve been using categories to approximate them. Any idea if 3.1 will include a tool for adding a specific Post Format to all Posts in a selected Category — kinda like the cat-to-tag conversion tool included when WP added tags?

So, technically – people who created themes using custom post types to make Tumblr-style blogs: were they doing it right or wrong? From what you have said, it seems to me that this would be more logical.

If custom posts are not really “posts” that show up in your rss feed (why this is the measure of what a “post” is… is beyond me)… why call them posts? Sure, I can hack into my theme and force custom posts to show up in my posts feed… but… why not make that an administrative option? Or enabled by default?

While I am very excited about the post themes and think they are a better feature, I agree with some of the other posters when I say lets re-name and re-work custom post types feature so they actually make sense as compared to these new formats.

I love the new feature and am very excited to have a central place (with a feed attached) to post all of my status updates and links as well as full articles. I’m just a little nervous about implementing the custom post types into sites that are using themes that clearly were not built to support such. I think its going to be an uphill battle to get this adopted unless there is something built to help us less experienced users get this up and running without messing with the core of our sites.

Thanks for this short clarification – I think one aspect of your article needs to be emphasized: The part where you write about post types being part of RSS Feeds. This implies that custom post types are not which could be a surprise to some putting important content into custom post types expecting to see this in their RSS feed.

Yep Andreas. CPT are definitely not part of the standard RSS feed. They can be incorporated into separate feeds. I’m sure it’s a shock to a lot of people. Especially those buying premium themes who have used CPT’s because they’re new and cool.

There’s one point I couldn’t get information about: can the Edit/Write page for a specific Post Format be customized (via add_meta_box in functions.php), as is the case for the Custom Post Types?

Otherwise, i don’t see this as a major improvement to the category/tag workarounds we have been using so far.

For instance, in order to start using the new “Video” Post Format, I do want to add specific fields for “OGG format URL”, “mp4 format URL”, “width”, “height”, “duration”, “Subtitle file URL” (which will then be used by my template to display the ultimate cross-browser movie player).

If I can do that, that’s awesome. Otherwise, I will go for a Custom Post Type, if I want a clean solution. But since I want those “Video” posts to behave much like ordinary posts, except for those specific custom fields, it would have made more sense for them to be a Post Format.

Yet there are at least three major post formats missing. Event or Calendar, geolocation or maps, and reviews. In my humble opinion wordpress’ post formats should, at the very least, incorporate and mirror all the draft microformats, even hRecipe.

Maybe Automattic doesn’t perceive these as post formats instead as content types? But hard-coding these into the core creates such a great standardized environment. Why not?

Looking in from the outside the difference I see between post types and post formats is that post types bring along addition metadata whereas post formats not so much and there has thus far been little-to-no standardization of custom field naming.

For an Event you need date, time, location. For Calendar you need month, year. For Geo/Maps you need location(s) to highlight. And so on.

In the past I’ve pushed for the core team to add such post types but they’ve said they aren’t needed by the majority of users and that they are plugin material so I’ve come to the conclusion the are right.

Of course, that’s me outside looking in; Mark my contradict anything I’ve just said and if so, listen to him.

Exactly. A limited set of categories, which may seem frustrating for experienced WP site devs (who will continue using custom post types and taxonomies), but useful for the end user, since he will be able to freely switch between themes that support those standardized post formats.

It must be me but I keep getting more confused about this.
Maybe this example of what I want to do will help.
I have a blog with posts (obviously). Some of my posts are book reviews. For these I want to have a number of custom fields to fill in ( title, author , etc ) and I want to make it simple so that I can select to create a book review and all these fields are there. Also, I want to have a custom rendering of these post types so that they have the relevant metadata tags for google to use.
BUT I want these to be part of my main RSS like other posts.
Now what do I use, I would have thought custom post types…..

You make a good point that “Custom post type” should probably be called “Custom content type”. A similar issue exists with register_sidebar()/dynamic_sidebar() which should actually be register_widget_container()/dynamic_widget_container() or something to that effect (and hopefully more concise!).

What is the process for renaming things like this, so that they don’t cause confusion in the future?

@Jesse Taylor – There was a lot of discussion about renaming them something other than Custom Post Types but given the legacy decisions including post_type==’page’ it became pretty clear that any other choice would cause even more confusion than what was chosen.

“Post” was used instead of “Content Type” because of the legacy code in WordPress. There was a very long discussion on Trac after which it was agreed that calling it a “Post Type” was the least bad option.

I have created Custom Post Types using the “Custom Post UI” plugin. This in my case is “Products”.

This works. I see in the admin area a menu item called Products.

Then I create some custom fields for Products type, with the “Custom Fields” plugin. (Which is so cool, and the very best among similar CMS-wannabe plugins, that it really should be in core WP install, without which WP is only a toy cms.)

This works too. Within the Products “post”, I see these custom fields.

BUT NOW comes the problem.

How do I:

(1) Show the archive for these products and design it to be different from regular category templates? I tried naming my category template differently (“category-products.php”) but this doesn’t work, because Products is not a category per se.

(2) Show a specifically designed Single template for this Products post type?

The “has_post_format” does not work for custom post types. I am using the latest WP as of this comment, which is 3.2.1.

There doesn’t seem to be any sensible documentation on WordPress on this subject. What gives? Is WP serious about becoming a CMS?

Ask a WordPress Dev

Do you have an interesting WordPress-related question? Submit your questions, and I'll periodically pick the best one and answer it here on my blog! It can be anything from usage tips to hardcore WP development questions.