Post types and formats and taxonomies, oh my!
A lot of people have been debating back and forth lately about post formats and custom post formats. This discussion also gets all confused with post types, and custom taxonomies, and categories, and tags… It’s time for some clarity. Mark had a really good post on the topic, but I think this needs to be explored in more detail.
Also, can’t have a good explanation without a bad analogy. I mean, this is the internet, right? So I should probably try to relate it to cars somehow.
A Post Type as a Car
Okay, so let’s say we have a post type. It’s called “car”. Anything that even vaguely resembles a car (including trucks, SUVs, jeeps, fire engines) gets lumped together in this post type.
We can categorize cars by type: Truck. Van. Hummer. Ford. Whatever.
We can add tags to cars: Four-door. Premium-sound. 6-disc-changer. Etc.
We can come up with custom taxonomies for them: A Color taxonomy could contain red, blue, black, silver, white, brown, etc.
The point here is that the post type is the thing itself, the various taxonomies are merely descriptions of it. You wouldn’t have both a “car” and a “truck” post type, because those are the same type of thing. If you prefer to be generic, you could make your post_type into “automobile”, which sorta fits both. That’s just a matter of naming choice.
Post types are NOUNS. Taxonomy terms are ADJECTIVES. Taxonomies themselves are related groups of adjectives.
This is why people using post types for things like Podcasts or Comic Strips or Video or something else are just fundamentally wrong. They’re using different nouns to describe the same thing, when they should be using the adjectives to sort out what those things are.
Displaying Different Things Differently
Historically with WordPress, categories have been used for more than just ways to classify posts. They’ve often been used to define different ways of displaying something.
The classic example is an “aside”. An aside has been traditionally defined as, basically, a short form post. Matt loves asides and he uses them far more often than long format posts:
A couple of aside posts on ma.tt
Matt also uses a special format for his gallery posts:
One of ma.tt's gallery posts
Compare these to his normal long format posts:
A normal long format post on ma.tt
You can easily see some of the differences. Asides don’t display a title. Galleries display a photo on the left hand side and the title is shortened and to the right. Long format posts have that double line underneath them, and also show the categories (essays in the above case).
The way he does these, and the way they have traditionally been done in WordPress in the past, is to co-opt categories. So he has an “Asides” category, and a “Gallery” category. In the code for his theme, he then has code that looks kinda like this:
if (in_category('asides')) {
// stuff to display the aside format post here
} else if (in_category('gallery')) {
// stuff to display the gallery format post here
} else {
// code to display the normal format post here
}
Then, when he makes a post, he just picks the right category for it and that changes how it shows up on the site.
The problem is that this is a bit lame. Categories should be adjectives describing the post, not sorting them into functionally different buckets for use by the theme. Sure, you can use them that way, but that’s confusing to some users. You could use tags in the exact same way with the has_tag() function, but that doesn’t make it a good idea.
Post Formats (coming soon to a WordPress 3.1 near you)
Enter Post Formats. Tumblr has had these for a long time:
Tumblr's post formats
Basically they just define a format for a post to fit into at display time. So the theme could say “asides won’t have a title displayed for them”, and voila. A theme can do something like this to define what formats it supports:
add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );
And it can do something like this when displaying things differently:
if ( has_post_format( 'aside' ) ) {
// display the aside format
}
So there we go. Theme authors can define what formats they support, and they can style those formats appropriately. And we didn’t use categories at all.
Additional: For those people trying to implement this in themes, post formats also add new styles to the post_class() call. You can use .format-XXX to style based on post formats on a post.
Custom Post Formats and why you don’t need them
As soon as this was announced, naturally theme authors got up in arms, because theme authors are a rowdy bunch of folks. They like to do things their own way. So there was instantly the question of “how do I add my own format”? The answer is: you don’t, nor should you even think about it.
Why? Why prevent customization? Think of it from the perspective of the user:
- They’ve got an existing set of posts.
- Those posts have formats.
- They switch to your theme, which uses some custom formats.
- Now their own posts don’t display properly with the new theme, because it’s using a whole different set of formats.
- Bad user experience, that is.
Now, from the perspective of a theme author, I understand the reasoning here. You want to be able to display things differently.
The problem is that you were already able to do that before.
Custom taxonomies have been around a long time. All you had to do was to a) create a custom taxonomy (call it “mytheme_formats”), b) allow users to sort posts into your taxonomy, and c) display things differently in the theme based on the terms in that taxonomy.
Post Formats is just a taxonomy. It’s a set of adjectives, describing the nouns that are the posts. So now we have “aside posts” and “gallery posts” and “chat posts” and “video posts” and so on. If you want to make your own formats, then you’ve had that ability forever. Why have you not already used it?
The answer to why you didn’t do it before is because there was no standard set of formats.
Without a standard set to work with, users won’t have any idea what your formats mean. You have to write documentation. You have to educate the user. You have to explain what this weirdness in your theme is.
Post formats changes that. Now you have a standard set of formats, and the user, having used other themes that support those formats too, will have some idea of what they mean already. But in order for this to work, themes must all use the same basic formats. There has to be a standard set of adjectives to describe the posts.
If you want to create your own set, then create your own taxonomy and box to have your set in it. But don’t complain when users don’t understand why your theme’s formats don’t mesh with the formats of every other theme that does support them.
The point of standards is to be standard. You don’t have to support the standard, but you also will have to deal with the consequences of being non-standard.
Summing up
In the end, you want to present things to your users in a method that causes the least confusion. If your user wants to display things in a single stream, then those things need to be Posts. If the user wants different things in that stream to display in different ways, then you should use a taxonomy to do that, and the post format taxonomy provides a nice and easy way to standardize that and be compatible with other themes.
If you want to go it alone with custom things, feel free, but be aware of the risk.
Agreed. Nice write up.
What’s the harm in having 1) a standard list of post formats (and possibly requiring all-or-none support for that list), and 2) allowing “custom” formats? I understand that you’re saying you could already create “custom formats” e.g. “genesis-post-format”, but with official post formats coming in 3.1, then you’d have two lists of post formats, which I think you’ll agree is wholly impractical.
Requiring all-or-nothing support for Post Formats is unnecessary and impractical, and very well may stifle creativity/innovation.
I’d rather see a Theme demonstrate an awesome, innovative implementation of one or two Post Format types – that would be the most useful to the users of the Theme – than to do a half-baked job implementing all of the Post Format types.
Besides, someone running a Podcast blog, who presumably would make great use of an “audio” (has that obvious omission been added to the standard list yet?) Post Format type, very likely would have little-to-no use for some or all of the rest of the Post-Format types. “Quotes” would be used by people who often post quotes; likewise for “video”, “image”, “aside”, etc. I’ve not often (or ever?) seen one site that publishes ALL of these Post-Format types.
That makes perfect sense.
My recently launched site – steppinofftheedge.com – would be one example where all the examples you list would be put to good use. I have currently gone down the route of category to distinguish blog from podcast, and then an entirely separate custom post type for quotes (commonplace), but could see how post formats would better serve that need.
I agree that the all-or-nothing aspect is bothering me greatly – but primarily because like most people involved in this conversation thus far, I am one who is comfortable creating or customizing my own theme. For those who aren’t – and WP.com users fill this niche heavily – transparent theme portability would be highly important.
You must not visit very many tumblr sites, Chip, lol. Just as an example… http://mustanghalle.tumblr.com/. I’m not saying every site would use all the formats or that the formats they will chose are necessarily the best for every site, but having a standard pool to draw from is key to portability – which is the whole point of formats to begin with. Otherwise, we may as well keep doing things the way we have – using categories or custom taxonomies to “hack up” our own brand of post formats (featured, asides, quotes, etc.). And of course that is perfectly acceptable for a developer who isn’t worried about his custom theme being compatible with an out of the box theme down the road.
“Official post formats” isn’t on by default. It requires theme support. So if you want to roll your own custom taxonomy to do formatting, then do that *instead* of using the post formats.
Also, it’s not all-or-none, as that indeed makes no sense.
Excellent write-up, Otto! The analogy fits beautifully. If I might try to extend it:
The Post-Type here is transportation. The default Post-Format type would be automobile. Other Post-Format types might be train, airplane, or boat.
Some people think that jet-ski or hovercraft or Segway would be useful as Post-Format types.
The problem we’re running into is that such custom Post-Format types but won’t be included in the “standard” list – and (at least right now) there is an intention not to make the standard list extensible.
As I said to Nacin, I’m cool with adding the feature with a non-extensible, standard list of Post-Format types initially, with an eye to making the list extensible in the future. The problem, though, is that users will want immediate extensibility, and Theme developers, identifying a need/demand, will find a way to meet that need/demand. In fact, Justin Tadlock has already roughed out a way to do so.
So, whether Post-Format types are intended to be extensible or not, they will be extended. I think the core devs will avoid considerable headaches if they recognize up front that there will be a demand for extensibility, and said demand will be supplied, one way or another.
Also, I disagree that portability is the only possible feature gained by Post Formats, which is, essentially, the current defense for not making Post Formats extensible. Post Formats also provide a much better way to display different Post “formats” without having to hack up the Loop. So, the functionality provides a benefit even to a one-off implementation in a custom Theme.
That didn’t work very well with custom post types, did it? People are still using them entirely wrong. You think allowing custom post formats would be any better?
If you want to roll your own taxonomy, then that’s the proper way to do custom categorization (which is what we’re really talking about here). Extending post format instead of simply rolling your own format is a poor idea in the long run.
Custom Post format is a good idea – if used properly by experts. You need to “Architect” your site properly. This feature is far more for professional use. Simply extending the posts would not work.
I think this is more properly:
Hopefully, this helps clear up the issue.
Wouldn’t a custom format just default back to a regular post format if someone changed themes? Aren’t there the same portability issues if someone registers and uses a custom taxonomy vs. a post format in a theme? I do understand the point here about how mass adoption is easier with a set list, but I think people who register their own formats will be the outliers rather than the rule.
I’m also thinking of other areas in WordPress where we’ve predicted what fields/formats people would should use. The user profile in WordPress has items like “website”, “AIM”, Yahoo IM”, and “Jabber”. I hope I’m not mixing metaphors too much here, but you can plainly see the benefit of providing hooks.
I also like Chip’s suggestion of releasing with a set list, and providing a hook down the road once it’s more established. It seems like once people get used to the set list and are comfortable with it (and once a few major themes adopt them), if a custom format pops up down the road it won’t be all that confusing.
Honestly, I don’t even see the need for waiting to provide the hook. I’m not suggesting there should be functionality provided in the UI for adding a custom post format, but why not let advanced users add them with code in their functions.php? Custom Post Types aren’t supported across themes, but that doesn’t keep them from being useful, so why would it keep Custom Post Formats from being useful?
A custom format would indeed have portability problems. Which is why they’re not allowed.
And that’s why you should use a custom taxonomy instead, if you want custom categorization. At least that way your custom taxonomy won’t interfere with other themes using regular post formats.
How would a custom format interfere with other themes using regular post formats?
What happens when two themes create different custom formats using the same name, and don’t agree on the general idea of them? With a controlled list that everybody pretty much agrees on, the display between themes will at least be similar.
Require that custom format names be prepended/appended with something (e.g. Presentation – Genesis in the adming section and presentation_genesis in the code).
Again (and I’m not trying to be rude – I think this is a valid question): How would a custom format interfere with other themes using regular post formats?
The simple fact that it’s “custom” interferes. When I switch themes, my available formats will change completely if one of the themes has custom formats. Requiring a prepended text doesn’t change the fact that the available formats are now different.
If you want custom formats, then roll your own taxonomy. Roll your own meta box on the edit screen for the user to select them. This is perfectly within the grasp of a theme, and it leads to less user confusion. They’ll expect the “Genesis-Formats” box to disappear when they are not using Genesis anymore. But they won’t expect “Podcasts” to disappear from their non-theme-specific format selection box, which is would if the theme was adding it as a custom format.
I definitely agree with the value of standards. And I want to advocate for your suggestion to just use custom taxonomies too.
But in reading through Travis, Chip and other’s concerns the one thing that custom taxonomies don’t address is to provide UI that doesn’t confuse the user, i.e. “What? I don’t understand? If I want a ‘gallery’ I select from the post format list, right? But if I want my format to be ‘super gallery’ I have to select from the where?!?’
So, sad to say, I do see value in allowing the theme developer to hook into post formats. I know it ain’t gonna happen, at least not in 3.1, but I do see value in it.
No, look at it from the user’s side of the coin. They change themes and “why aren’t my super galleries showing up like galleries anymore? This new theme sucks!”….
If you want to create your own “format” types, then you need to separate them out to the point where you can specify them as belonging *specifically* to your theme. That way you’re not sabotaging everybody else.
And realistically, if you’re going to create your own formats, then don’t use post-formats at all. Make your own taxonomy, which will have it’s own meta box, with your theme name in it, which is then clearly custom to your own theme. Nobody said you can’t put a “gallery” in your own custom taxonomy. There’s no need to cause user confusion, simply support post formats or support your own custom solution, but don’t support both. Easy.
“No, look at it from the user’s side of the coin. They change themes and “why aren’t my super galleries showing up like galleries anymore? This new theme sucks!”….”
Well, they’d likely view the theme negatively, not WordPress…
“If you want to create your own “format” types, then you need to separate them out to the point where you can specify them as belonging *specifically* to your theme. … There’s no need to cause user confusion, simply support post formats or support your own custom solution, but don’t support both. Easy
Fair point.
[…] of these Post Formats, you will have any easy way to display each format with a unique style. As Otto illustrates, Matt Mullenweg has done this for some […]
[…] past two days has revolved around a new feature slated to hit WordPress 3.1 called Post Formats. Otto as well as Mark Jaquith do a great job explaining what these are. To make a long story short, […]
Hey Otto,
I read this as well as Mark’s article about it on his blog. I just spent the past few weeks building a theme using Matt’s method based on categories. I was debating whether to keep it the old fashion way or to switch over to new method. While I agree that using categories to determine style is weird, it works easily. It also won’t break if there’s a fall back theme or if someone switches to a different basic theme. On the other hand, having to use the new post formats seems like it needs a bit more baking in the oven. Don’t know if I’m ready to use it yet.
P.S. I’ve been noticing this where ever the SFC plugin is being used: http://min.us/icvma0.PNG Is it a FB problem or related to your plugin?
Post Format is a taxonomy, the same exact way that Category is a taxonomy, but it’s specifically a taxonomy for Formatting Posts. They simply added some UI for it, and a predefined list of Terms (Category names). It should “fall back” in the same manner, and be as safe as (or safer then) using the Category method, ie. simply displaying the post content as a post.
[…] WordPress Is Not A Community Post Formats vs. Custom Post Types Post Types, Formats, Taxonomies, oh my! […]
[…] of these Post Formats, you will have any easy way to display each format with a unique style. As Otto illustrates, Matt Mullenweg has done this for some […]
I like this idea, and I have started implementing this via the Woo Tumblog plugin, however I also have a WP 3.1-alpha installation, and can’t find this feature anywhere. Can someone shed some light as to how to activate it so I can play around with it?
Look at the post again. Specifically, under “Post Formats (coming soon to a WordPress 3.1 near you)”.
All you do is to put the add_theme_support line into your theme’s functions.php, to add the formats you support. List of possible formats to support is here: http://codex.wordpress.org/Post_Formats
[…] 15 ways on how to speed up your WordPress website. Which reminds me, I need to start too.Post Types & Formats & Taxonomies New feature coming out in WordPress 3.1. Isn’t that cool. WordPress is becoming more […]
I use this kind of Technique for my site …
[…] Post types and formats and taxonomies, oh my! » Otto on WordPress […]
[…] not to say it hasn’t been done. And can you really replicate the Tumblr experience on self-hosted […]
[…] OttoPress: Post Types and Formats and Taxonomies, oh my! […]
[…] OttoPress: Post Types and Formats and Taxonomies, oh my! […]
[…] have been a few articles posted already with examples of how to add support for this in your theme. And they all made me […]
Hi Otto,
i hope there will be a central function (template tag) that simply returns the array of those new taxonomies. This would help automating a lot of things with foreach loops on the one hand. On the other we would possibly be a lot of future/update/post-format-extended safer and could have nice fallbacks in themes or plugins…
[…] on Post Formats Otto on Post Formats Dougal on Post Formats Lisa Sabin Wilson on Post […]
I like the analogy but lets say we also want to separate brands from car types, that means we should create 2 main categories for post type “cars”: one for “brands” and one for “type of car” and use tags and custom taxonomies in both ? Is this the best way ? Thanks in advance, i´m new to wordpress and i´m loving it !!!
[…] that I’m getting it. You can get it from Otto’s post here: Post types and formats and taxonomies, oh my! A long quote follows, but before we go there, I’d like to point out that (1) I don’t […]
[…] Post Formats, Custom Taxonomies and Custom Post Types is to be found on Otto Wood’s blog: Post types and formats and taxonomies, oh my! and on Mark Jaquith’s blog: Post Formats vs. Custom Post Types. This entry was posted in […]
[…] Menge Infos in »Post Types and formats and taxonomies, oh my!« von Otto on […]
[…] Post Types and Formats and Taxonomies, oh my! […]
[…] may also be worth noting that post formats are not the same as custom post types. However, formats will undoubtedly replace a tendency by many users […]
[…] add a few lines of code to their templates and stylesheets.WordPress contributor Otto wrote a great post about Post Formats several months ago that is definitely worth the read.Internal LinkingInternal linking is a new […]
thanks for the info i was bit confused of this …
I get the intent of Post Formats and how it will help users recognize familiar to create content, but not all theme developers will necessarily implement this the same way.
For instance, Let’s say I create a Theme with a Video Post Format that only requires the user to insert a textual LINK to the video in the post content to work (think oEmbed ie: http://vimeo.com/14270619).
If a users switches to another theme that implements Video Post Formats in a different way — maybe by requiring the full embed code() — then the Video Post Format will not be displayed correctly in the new theme. The user will experience the same exact frustrations that they would in your “Super Gallery / This new theme sucks!” example above.
For Post Formats to really work across themes that support them, users’ implementation of the Formats as it relates to creating the content will also need to be consistent and independent of the theme. Looking at the codex, that doesn’t seem to be the case. Most of the documentation suggest that the code might or could be used in a certain way. Are developers expected to account for the many different ways that Post Formats can be implemented by users?
This feature is really more simplistic then people are envisioning. It’s a simple taxonomy (with a predefined set of terms) that, on theme display, essentially tweaks the css/html of the marked post.
The formating part of Post Format occurs on the Theme’s Output, not on the user’s input. From your Codex link, “the actual post content entry won’t change.”
The “Post Type” of the post content is still “Post” and therefor has the same fields and meta data behind the scenes as any other post. Putting harsh conditions and filters on what content can be entered and saved (other then possibly hiding non-essential fields… and that’s only maybe) isn’t a good implementation, and having the theme fail or be incompatible would be a really bad implementation.
In your example, I think that such an implementation is erroneous by the requirement that the user’s input has to be of specific type.
Hope that helps clarify things 🙂
[…] WordPress employee wrote a great post on Post Format Styles here at Otto on WordPress You might want to check it out. […]
[…] i.e. aside, gallery, link, image, quote, status, video, audio or chat. I defer to a quote in Otto’s blog: Post types are NOUNS. Taxonomy terms are ADJECTIVES. Taxonomies themselves are related groups […]
[…] Here is a pretty good write-up on post formats by core contributor of WordPress, Otto. […]
[…] contributor Otto wrote a great post about Post Formats several months ago that is definitely worth the […]
[…] contributor Otto wrote a great post about Post Formats several months ago that is definitely worth the […]
Hi,
I still don’t get. Why should I use a post format? We survived without them until now, so why do I need them?
I still don’t get. Why should I use [new feature]? We survived without [new feature] until now, so why do I need [new feature]?
See the problem with that logic?
New features are welcome. Especially if they fill a previous gap. Is Post Formats filling any gap? What can we do if this [new feature] that we couldn’t do before?
Cheers
The Gap is evident by how people were misusing CPTs to merely apply different Formats to Post content (of the “post” post_type).
What we can do now (as Theme Devs), is format post content (based on a standard list of formats) using a fairly easy User Interface, and (as Users) expecting a variety of alternative Theme’s to offer implementations of these formats (in a reasonably compatible way).
I like it how both you and Otto say ‘people were misusing CPT’ – if a lot of people ‘misuse’ a feature surely it means the feature was either planned badly, documented badly, or both… don’t blame the user
Thanks! That was much clearer than the Codex!
[…] Post Types and Formats and Taxonomies, oh my! […]
[…] contributor Otto wrote a great post about Post Formats several months ago that is definitely worth the […]
Like always, good write-up.
I think of Post Formats as:
1) A portable feature for posts, expected to work the compatibly in all supporting themes, and
2) A great example of how to implement such a feature.
It’s extendable by its nature as an example.
The problem of extending of the default list (and the strength of not extending it) comes from the idea that using a Format from the standard list implies (at least in the near future) that there are alternative themes supporting that Format. An off-standard Format implies no other theme support (or possibly incompatibly conceived Formats).
Again, it’s still extendable, just in a different manner. If you’d like to extend the default Post Formats, please implement the feature using a separate taxonomy, and please also define a standard collection of Formats (as a way for other Theme authors to adopt your Formats).
Also, extending for “Custom Post Types” is fairly straight forward, and even clearer in why it deserves to be separate. “Post Formats” is Formats for content of the “Post” Custom Post Type. The Standard list of Formats for Posts wouldn’t likely make sense for any other content type.
So, the proper way of Extending “Post Formats” for other Content Types is to implement the feature (using Post Formats as an easy and convenient example!) with a new taxonomy for the Custom Post Type you are working with. But please provide a standard list of Formats that are appropriate to your content type!
[…] Why might you find this format useful? It simply means you can designate a post as an aside, link, video, image, quote, status, audio, chat or gallery depending on what has been created for your theme by the designer. This will create more of a Tumblr like experience for your readers. For a more techincal discussion on Post-Formats you read about it from WordPress contributor Otto. […]
[…] contributor Otto wrote a great post about Post Formats several months ago that is definitely worth the […]
Thanks for this explain, now this case more easier to understand on my side
Hi Otto,
I think I kindof get the idea and difference between formats and types. Now I miss an ‘event’ format. It would be great if I can use posts to announce events. How would you implement that? Use custom post types to define the event? That would mean it’s not part of the normal ‘posts loop’ right?
Hope you can give me a hint how to implement this 🙂
Vincent
[…] of these Post Formats, you will have any easy way to display each format with a unique style. As Otto illustrates, Matt Mullenweg has done this for some […]
[…] Post Types and Formats and Taxonomies, oh my! by Otto […]
[…] Last,post types and formats and taxonomies, oh my! from Otto on WordPress. […]
[…] looking at how Matt Mullenweg handles Galleries according to this article on Post Types, Taxonomies, and Formats by Otto. I think I’m going to rewrite the Gallery format for my version of Tapestry to […]
Great explanation. Thank you.
[…] Post Formats, Custom Taxonomies and Custom Post Types is to be found on Otto Wood’s blog: Post types and formats and taxonomies, oh my! and on Mark Jaquith’s blog: Post Formats vs. Custom Post Types. This entry was posted in […]
[…] Post Types and Formats and Taxonomies, oh my! […]
this is how i’ve got mine set up:
<?php if (have_posts()) : while (have_posts()) : the_post(); ?> <?php $page_templates=array( 'aside'=>'/inc/post-formats/aside/aside.php', 'audio'=>'/inc/post-formats/audio/audio.php', 'chat'=>'/inc/post-formats/chat/chat.php', 'code'=>'/inc/post-formats/code/code.php', 'gallery'=>'/inc/post-formats/gallery/gallery.php', 'image'=>'/inc/post-formats/image/image.php', 'quote'=>'/inc/post-formats/quote/quote.php', 'status'=>'/inc/post-formats/status/status.php', 'video'=>'/inc/post-formats/video/video.php', 'link'=>'/inc/post-formats/link/link.php', 'custom'=>'/inc/post-types/custom/custom.php', 'default'=>'/inc/post-formats/standard/standard.php' ); $selected_template='default'; foreach($page_templates as $key=>$file) { if($key=='custom') { if(get_post_meta($post->ID,$key,true)) { $selected_template=$key; break; } } else { if(has_post_format($key)) { $selected_template=$key; break; } } } include(TEMPLATEPATH.$page_templates[$selected_template]); ?>it allows me to call any post type i can imagine. just replace “custom” with whatever.