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.

116 thoughts on “Post Formats vs. Custom Post Types

  1. I’m just trying to get my head around this, so basically instead of creating categories to create different post types/layouts, we would create a post format to get the different layout types?

  2. Like Andrew, I’m wondering that if we’re already using category templates, would we really need to transition to post formats? Especially for custom designed blogs or content management systems?

    I’m wondering if this is going to make feed handling easier – showing custom fields in the feed for specific post formats, etc?

  3. 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.

    1. 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.

  4. 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)

    1. 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.

    2. 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.

    3. 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.

    4. @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):


      <?php
      /*
      news-items-instead-of-posts.php
      Changes WordPress "Posts" to be called "News Items" instead.
      Copy this code into your theme's functions.php file.
      See comments here: https://markjaquith.wordpress.com/2010/11/12/post-formats-vs-custom-post-types/
      */
      add_action('admin_menu','change_post_menu_label');
      function change_post_menu_label() {
      global $menu;
      global $submenu;
      $menu[5][0] = 'News Items';
      $submenu['edit.php'][5][0] = 'News Items';
      $submenu['edit.php'][10][0] = 'Add News Item';
      $submenu['edit.php'][16][0] = 'News Item Tags';
      echo '';
      }
      add_action('init','change_post_object_label');
      function change_post_object_label() {
      global $wp_post_types;
      $labels = & $wp_post_types['post']->labels;
      $labels->name = 'News Items';
      $labels->singular_name = 'News Item';
      $labels->add_new = 'Add News';
      $labels->add_new_item = 'Add News Item';
      $labels->edit_item = 'Edit News Item';
      $labels->new_item = 'News Item';
      $labels->view_item = 'View News Item';
      $labels->search_items = 'Search News Item';
      $labels->not_found = 'No News Items found';
      $labels->not_found_in_trash = 'No News Items found in Trash';
      }

      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.

      Hope this helps.

      -Mike

  5. You are right, it is very confusing.

    I guess I have a number of pertinent questions.

    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.

    ok.. make me a believer lol…

  6. Yes, Yes, Yes…….

    I’m sitting here racking my brains on how my dear mr X will add random project videos without buggering up the whole works.

    Any chance of publishing this feature before Sunday (lol)

    From the bottom of my heart “Thanks for all the changes since 2.6 ……..”

  7. 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.?

  8. How’s that going to be handled in terms of UI? will selecting a certain post-format will update the editing view/screen of the post to only include what’s needed?

  9. Nice conversation and grate post to open all this.Tnanks.

    @Thao try this method to explain what post is :

    1 each site might have 2 types of content :
    a) more or less static – pages
    b) frequently upgraded – posts (news, products, services etc)

    2 classic site runs on pages and you delete previous version of page when updating your content.

    3 “Blog” or whatever you call it lets ou update your contenbt whithout deleting of a previous version…

    4 WordPress is a software that helps you to have both , pages and “posts” within the same site ( just click the Publish button )

    that works nice in france .

    cheers

  10. 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…

  11. 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?

  12. Definitely makes a lot of sense format wise. People are still trying to understand tags versus categories just in blogging alone.

    I am going to try this out on one of my upcoming projects.

  13. 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.

  14. Is there a way to test this out on a site running WP 3.0? Maybe some function code we can add or something? I’d like to start developing sites with this functionality built in if possible.

  15. 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.

    1. Joel can you force CPT’s to show up *in* the standard posts’ feed? Or are you referring to them in their own separate feed?

  16. 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.

  17. 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.

  18. 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.

  19. Just after I’d managed to wrangle custom post types to do my bidding on a project, now I have to second guess myself as to whether these would be more appropriate. Oy vey.

  20. Post formats are just what I need for my community blog.

    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?

    1. 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.

  21. So, if I got it right, post formats = post categories? And, it would enable us to tweak posts to make them look like we want?

    1. 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.

  22. 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…..

  23. Mark —

    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?

    1. @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.

  24. Why can Custom Post Types not function without the post-type prefix slug (ie /mark_jaquith instead of /employee/mark_jaquith)

    In theory this seems relatively simple, by intercepting some level of hierarchy by choice…is this doable right now? or even hackable?

  25. I’m actually a bit confused as to why the term “POST” is used instead of “CONTENT”.

    Why not change “post types” to “content types” then make “post formats” specifically to post content type it could be like:
    • Content Type
    – Page
    – Post
    • Standard
    • Aside
    • Status
    • Quote
    • Video
    • Image
    • Gallery
    • Link
    • Audio
    • Chat
    • (PDF / ebook)*
    • (code)*
    *maybe future post formats? 🙂
    – Media
    – Links
    A way to cross post / embed posts would be great too.

    1. “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.

  26. I came to this page looking for some help.

    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?

    Would appreciate any pointers. I have also started a thread on WP Forums which no one has really responded to:
    http://wordpress.org/support/topic/custom-post-types-archive-page-and-different-single-page?replies=5#post-2369873

    Could you please reply to my email address (as mentioned here) or on the WP forum.

    Thank you!

Comments are closed.