List of post formats
The current list of post formats is on the Codex page: http://codex.wordpress.org/Post_Formats
- aside – Typically styled without a title. Similar to a Facebook status update.
- chat – A chat transcript.
- gallery – A gallery of images.
- link – A link to another site.
- image – A single image.
- quote – A quotation.
- status – A short status update, usually limited to 140 characters. Similar to a Twitter status update.
- video – A single video.
- Edit: audio has also been added as our final post type.
There has been suggestion of an “audio” format, which makes sense given the other multimedia posts. Another one recently suggested to me was a “code” format, which I could get behind.
I know we changed “photo” to “image” to be more generic, but I’m thinking we should change it back, and define a gallery as a gallery of photos. Not that you couldn’t use images there as well, but our target here is photos in particular, I’d imagine.
We need to make sure we get these right the first time, so if you have a suggestion, you should weigh in. I’ll be sending a link to this post out to a number of theme developers to hear their insights based on their experiences.
As a reminder, the main focus of this feature is portability and standardization, thus, custom formats are not being supported by the API. (For more, see Mark’s post and the comments.)
Alex theberge, 
Edward Caissie 6:34 pm on November 11, 2010 Permalink
I would definitely support a ‘code’ format, seems a sensible and likely to be often used one.
mfields 6:39 pm on November 11, 2010 Permalink
+1 for code format
David B 9:09 pm on November 11, 2010 Permalink
Liking the code format concept as well.
Aaron D. Campbell 2:47 am on November 12, 2010 Permalink
While I definitely post code, I’m not sure I ever post it all by itself. Usually it’s part of a post that explains what it does, and it’s just wrapped in code tags. Do you see places posting just code?
Banago 8:27 am on November 12, 2010 Permalink
Code is very developer centric and won’t have wide adoption. Even us as developers might only use it for snippets but not part of a regular blog. I don’t think it would be a good idea to implement code format – KISS formats!
Jeffikus 1:12 pm on November 12, 2010 Permalink
I agree with Aaron, it seems too niche to have a “code” format. Very developer-centric, microblogging is primarily aimed at developers.
Andrew Nacin 6:38 pm on November 11, 2010 Permalink
Obviously, a post can also have no format. A theme would explicitly register support for some or all of these formats using add_theme_support().
redwall_hp 10:05 pm on November 11, 2010 Permalink
Great idea. I’ve actually been thinking about hacking together a Tumblr-style Link thing using post types, for my own usage. (Gruber’s Daring Fireball site is actually what gave me the idea…) I like the idea of having something like that built-in to the core.
Remkus de Vries 6:39 pm on November 11, 2010 Permalink
Both suggestions I can fully support. Photos, to me, makes more sense than images and a code version is almost a must imo.
Ian Stewart 6:39 pm on November 11, 2010 Permalink
I like image only because I imagine artists using that post format.
Mo Jangda 6:39 pm on November 11, 2010 Permalink
A generic “image” is far better than “photo” (because photos are essentially images). Also would maintain consistency since the tooltip for images says “Upload an image”.
Brian Gardner 6:40 pm on November 11, 2010 Permalink
I think that adding “code” as a post format would be cool. Lots of devs (including me) would like to drop snippets from time to time. if this doesn’t get in, perhaps a way to register our own post formats?
Brian Gardner 6:43 pm on November 11, 2010 Permalink
Eh, #fail on me – for missing the “no custom formats” line of the post.
Banago 8:29 am on November 12, 2010 Permalink
I missed that to – it would be really nice to have custom formats though.
Eric 6:44 pm on November 11, 2010 Permalink
I second both ‘code’ and ‘audio’ formats. There’s a lot of custom formatting that comes with posting code, but there’s even more that comes from a blog that also houses a podcast. You could argue that podcasts would be better suited as a custom post type, and some people use it that way, but many times a podcast is posted as part of the blog’s general timeline in association with a transcript …
Chip Bennett 7:01 pm on November 11, 2010 Permalink
+1 to “audio” post-format type. As with “photo” vs “image”, a podcast is a highly likely use case of “audio”, but not sufficiently different to warrant a post-format type more unique than “audio”.
Travis 6:47 pm on November 11, 2010 Permalink
I agree that “image” makes more sense than “photo”. No need to suggest/push the usage in one direction.
Rich Pedley 6:50 pm on November 11, 2010 Permalink
Surely photo would be limiting, image is better – after all they are all images on the web.
Nathan Rice 6:51 pm on November 11, 2010 Permalink
+1 for ‘image’ rather than ‘photo’
Andrew Nacin 6:51 pm on November 11, 2010 Permalink
Okay, ignore the whole photo/image thing.
Banago 8:30 am on November 12, 2010 Permalink
+1 We want audio though.
Matt 6:54 pm on November 11, 2010 Permalink
Do you have examples or ideas of these being used in the wild, meaning a post is composed of entirely code and styled significantly differently than it would be if it was just one of the other types plus a pre element? I’d like to follow the Microformats-style standardization of existing usage rather than trying to predict every possible use in the world. We could have as many formats as there are tags. But the fewer there are, the more likely themes are to support a meaningful subset of them.
Chip Bennett 7:00 pm on November 11, 2010 Permalink
It would make sense to me that a “code” post-format would be sufficiently niche not to warrant a place among the “standard” post-formats. However, that said, might it also be an argument in favor of allowing extensibility of post-formats?
Eric 7:08 pm on November 11, 2010 Permalink
Actually, now that I think of it ‘code’ wouldn’t really stand alone as a post micro-format. Yes, a post of just code would be styled significantly differently than a content post, but at that point it would be more of a custom post type (non-post object, as @Nacin called it elsewhere) and wouldn’t fit with this schema. I rescind my vote for a ‘code’ post format.
Otto 8:13 pm on November 11, 2010 Permalink
Tumblr supports a set of formats. Mostly similar to these (and they do have “audio”):
Lloyd Budd 9:55 pm on November 11, 2010 Permalink
I’m with Matt, a short pragmatic list eases adoption and transitioning between themes, and reduces the pressure of getting it *all* right the 1st time.
Jeffikus 1:10 pm on November 12, 2010 Permalink
I agree with you Matt, the list should be kept simple and short, Tumblr is probably the best example.
Lance Willett 7:04 pm on November 11, 2010 Permalink
+ 1 for audio.
What about “recipe” as a common format?
I would argue that code snippets don’t warrant their own post format.
Chip Bennett 7:26 pm on November 11, 2010 Permalink
I think “recipe” is another example argument for making post formats extensible.
Eric 7:51 pm on November 11, 2010 Permalink
Perfect example of extensibility. “Recipe” would fit on the list as it’s the right *kind* of category for a post format, but it’s a bit too specific to be included in a common list of defaults. I doubt it would ever be used by the vast majority of bloggers, though it would definitely be used by many.
Knut Sparhell 1:07 pm on November 12, 2010 Permalink
A recipe as hard to implemet as a post format. It’s more a custom post TYPE (CPT), as it will require custom taxonomies and custom fields. Displaying a recipe is not just a matter of formatting, but having a lot of structured data to present.
Now that we have CPTs I see no reason for a lot of post formats as well.
As I see it the only reason to implement formats is compatiblity between themes. The list wil be published ad a standard. If they were to be custom, the reason to implement the feature disappers. We do have CPT’s, and they are almost completely customizable, but will require explicit support by the new theme, or a plugin.
I also view this new feature as a way to avoid making a new CPT for things that may be displayed as a normal post.
David B 9:11 pm on November 11, 2010 Permalink
What about lists (like to-do lists or any generic ‘list’)? Or is that too fuzzy of a concept?
Mark Jaquith 5:29 am on November 12, 2010 Permalink
Recipes are timeless.
It should be a custom post type (or just a sub-page).
Will Anderson 7:11 pm on November 11, 2010 Permalink
Slight side tangent here, but is there a specific reason that get_post_format() returns false rather than null if there is no format associated with that post? 99% of the time I assume it wouldn’t make a difference, but there’s one place I can think of where returning null would be more convenient. Template ‘parts’.
Assuming different post formats display using different HTML as well as CSS, being able to leverage the get_template_part() function would be really cool. A good base name would be needed, but let’s call it “foo” for this example. It’d be nice (if somewhat inefficient on archive pages) to be able to call…
get_template_part( ‘foo’, get_post_format() ) inside the loop. This would work for the most part, but would be broken by the fact that get_post_format() returns false instead of null. Am I missing something?
This brings up another point, that a third argument for get_template_part could be nice too. Why not get_template_part($slug, $name, $format)? If the last argument defaulted to false, it would make the first point moot.
More generally speaking, intelligent selection of template files based on post format would be really nice. I dread the thought of having massive if/else blocks everywhere to cover the different post formats.
Andrew Nacin 7:19 pm on November 11, 2010 Permalink
#15385, and http://core.trac.wordpress.org/ticket/14746#comment:124.
get_template_part(): It’s intra-loop styling, so it’s up to the theme to decide the best way to do this.
get_post_format(): It makes sense for it to return false if post formats aren’t actually enabled, but probably ‘default’ if enabled.
Will Anderson 8:21 pm on November 11, 2010 Permalink
Ahh. Cool. I was under the impression the function would return false, not ‘default’ (based on the Post Format Codex page. Maybe it should be updated.
Mike Schinkel 7:15 pm on November 11, 2010 Permalink
Question: Does a Post Format mean that the post will be that in it’s entirety? For example, if it is a video will it not have post content? Or will it have post content in addition to the video? Maybe some guidance on this will be helpful?
Patrick Daly 7:25 pm on November 11, 2010 Permalink
Are “aside” and “status” so different that they deserve their own formats?
Mark Jaquith 9:24 pm on November 11, 2010 Permalink
Facebook and Twitter have muddled these, but I do think they are distinct. Status is shorter, and is a status. Aside is a short entry, but not necessarily a status.
Ian Stewart 7:32 pm on November 11, 2010 Permalink
The aside and status formats sound awfully similar to each other.
Mike Schinkel 7:38 pm on November 11, 2010 Permalink
Additional potentials:
Q&A/FAQ (Question and Answer format)
Interviews (Question and Answer but with speakers)
Lists (i.e. Top 10 Reasons why…)
Review (Products, Movies, Albums, etc. Might be too complex to be included as a format, though)
Another question: Can Post Formats imply “standard” custom fields for that format?
donnacha | WordSkill 7:44 pm on November 11, 2010 Permalink
+1 for FAQ
Eric 7:49 pm on November 11, 2010 Permalink
I see some value in ‘lists’ as a post format, but an FAQ would be more along the lines of a custom post type. I’m ambivalent towards interviews and reviews, though.
donnacha | WordSkill 7:52 pm on November 11, 2010 Permalink
A good argument could be made that EVERY website should include a FAQ section, both to save users confusion and to reduce the support burden. Owners of active sites often find themselves answering the same questions repeatedly.
David B 9:13 pm on November 11, 2010 Permalink
Was thinking ‘directions’ (like directions from Point A to Point B – think Google Maps) but I suppose lists could cover this.
Andreas Nurbo 7:45 pm on November 11, 2010 Permalink
Will custom posttypes be able to configure custom post formats? Or will that have to be dealt with using either tags/categories/metavalue etc?
donnacha | WordSkill 7:49 pm on November 11, 2010 Permalink
Product
Event
Profile
Map / Directions
Kel 7:53 pm on November 11, 2010 Permalink
Yes – Event seems to be missing here. Would Time based (sub) formats cause further issue with the post format itself?
donnacha | WordSkill 8:26 pm on November 11, 2010 Permalink
Actually, I’m not sure if all four of my suggestions shouldn’t actually be handled by Custom Post Types – I’m not sure what the dividing line between CPT and CPF should be.
Peter 1:40 am on November 12, 2010 Permalink
I was also thinking of exactly these 4 items. We’re doing a large project right now that has all of these post types.
Rich Pedley 9:59 am on November 12, 2010 Permalink
It would be wrong of me not to support Product as a suggestion.
I assume these can also be applied to custom post types?
Chip Bennett 7:50 pm on November 11, 2010 Permalink
I agree with Ian that “Aside” and “Status” are really the same thing, and can/should be merged.
Also, the many legitimate, if (to varying degree) niche proposed post-format types – FAQ, recipe, code, list, etc. – all argue strongly in favor of providing a means of extensibility.
The list of standard post-formats is – and should be – quite limited. But this feature has great potential, and very well may become wildly popular – which means that many people will find good, legitimate reasons to extend the format.
Patrick Daly 7:53 pm on November 11, 2010 Permalink
+1 on a short list of standards with option for custom formats.
With each version of WP we can discuss which custom formats are clearly popular and decide to add them to core or not.
donnacha | WordSkill 7:56 pm on November 11, 2010 Permalink
Hi Chip. While keeping things simple is almost always a good thing, extending the range of standard post-formats might be a powerful encouragement to people to use WP for a greater variety of purposes. The “WordPress is just for blogs” meme still has quite a foothold out there.
Otto 8:16 pm on November 11, 2010 Permalink
I disagree and think aside is different enough from status to be given a separate type. Status is more like a twitter post. Text only, no (or few) links, maximum length restriction, etc. Aside is more like a short form post. Paragraph format, probably highly anchor tag linked text.
Chip Bennett 8:22 pm on November 11, 2010 Permalink
I’m still not seeing how the two are functionally distinct enough to warrant each getting a (coveted) place in the core/standard list. To me, the only functional difference between a Twitter tweet and a Facebook status message is the allowable number of characters.
They’re both a brief, untitled bit of text content.
IMHO, just pick one of the two, limit it to some # of characters (say, 255 or something), and call it a day.
that girl again 1:20 am on November 12, 2010 Permalink
I get this, but the terminology bothers me. If you’re explaining the concept of asides by comparing them to Facebook status updates, people are going to get confused when you go on to say that statuses are modelled on tweets, rather than, um, statuses. ‘Txt’ or ‘mobile’ might be more helpful, if you really can’t use ‘tweet’. Or you could invent a new, WP-specific term for the things.
Michael 7:08 pm on November 15, 2010 Permalink
‘that girl again’ is right — instead of trying to explain things by referencing Twitter or Facebook, I think it’s simple enough to say that a “status” is what you’re doing right now, whereas an “aside” is simply a short blog post that doesn’t require a title.
Rich Pedley 9:56 am on November 12, 2010 Permalink
My take on this -
Status – best served by an example: I’m ill
Aside – is like a side comment or even a QOTD. – Have you had your 15Mb’s of fame yet?
So I see a case for both.
Rich Pedley 10:45 am on November 12, 2010 Permalink
oops ignore my example for aside, forgot quote was in the list.
Chip Bennett 2:05 pm on November 12, 2010 Permalink
I was going to mention the “quote” format.
But, doesn’t that further illustrate that there’s really no need to differentiate between an “aside” and a “status”? A “status” is merely one type of “aside”.
Ken 7:52 pm on November 11, 2010 Permalink
I’d think most things that fit as a Microformat or (Google) Rich Snippet would be better suited as a CPT (or non-post object) and not as a Post Format. These would include hCard, Review, Event, People, Business, Recipe, etc. The rational being that they contain specific data which doesn’t fit the post object well, and their data must be formatted and marked up a specific way.
On the other hand, doing posts of that sort without concern for data and markup (ie, just styling) then perhaps there’s an argument, but I still think they are better served by CPTs.
Marc Lavallee 9:03 pm on November 11, 2010 Permalink
Roundup. For link roundups, we style each link and add an icon next to the headline. ex: http://informant.kalwnews.org/roundup/the-blotter-thursday-november-11/ .
+1 for Q&A (or Interview). For this type of post, a custom format could allow theme developers to style the Q’s and A’s. ex: http://docs.argoproject.org/2010/07/13/content-type-qa/
Also, +1 for Audio.
Ptah Dunbar 9:18 pm on November 11, 2010 Permalink
This “standardization” is clearly causing more trouble than it’s worth and is the complete opposite way WordPress has been shipping new features.
Put the filter back into get_post_format_strings() and educate the community on the differences between post formats and post types (e.g. because events, product, and recipes are CPTs not CPFs). Links, Status & Quotes are.
Let WP core ship with it’s “official” post formats but allow the community to experiment with their own custom formats if they feel like the official post formats aren’t relevant enough for their theme. You can then guage based on popularity which custom post formats should warrant inclusion into core. Rinse and repeat.
If WP ships with this “limitation”, we’re going to find ways around it so make the commit.
Mark Jaquith 10:59 pm on November 11, 2010 Permalink
It’s not much more than standardization. Themes can (and are) doing this currently using categories or a custom taxonomy. The whole point of this isn’t to make it possible, but to make it portable.
We’re working on making the specs more detailed, so that these formats are completely portable from theme to theme.
Alex M. 11:08 pm on November 11, 2010 Permalink
I think allowing custom formats would be a bad idea. Photo vs. image above is a good example of why this would be a bad idea.
Matías 10:59 pm on November 11, 2010 Permalink
I echo the need to keep it short. The list sounds great, though I concur that Status seems like a skinnier Aside. It certainly would be difficult to accommodate naturally design wise while having it widely adopted, which is the purpose of the standardization. Are three types of text posts really needed?
Nathaniel Taintor 11:33 pm on November 11, 2010 Permalink
I’m still trying to wrap my mind around the concept here.
If anything, I think maybe there should be a “Column”, “Editorial” or similar post format – not sure of the terminology. I see a lot of news-driven blog where authors have a regular column that follows a different logic, perhaps more personal, than their regular reporting or asides.
Jon Brown 12:29 am on November 12, 2010 Permalink
First I could really use an example/demo of each of these formats.
Second, and more importantly, plead keep generic terminology (ie images).
Third, what about a format for lists? I’m actually thinking about recipes in this use case.
jb510 5:20 pm on November 12, 2010 Permalink
Sorry, that was written way earlier than it posted, ie before all the other comments explaining/answering all that
Jeffikus 12:47 pm on November 12, 2010 Permalink
Here’s my experience of actually building a tumblog theme and a tumblog plugin.
A standard format per ‘post format’ is necessary otherwise everyone is going to be doing their own thing. That defeats the purpose of this effort and frankly developers should follow standards. When I built the tumblog plugin I kept the formats standard so it would be easy for dev’s to follow a standard format and get more microblogging themes out there. Tumblr is, in my opinion, the best model to follow for microblogging and I think their items (text, photo, quote, etc) should be included.
I am going through the code this weekend and will post my thoughts shortly.
enej 8:39 pm on November 12, 2010 Permalink
What about “Question” as a format?
Chip Bennett 1:11 pm on November 13, 2010 Permalink
Couldn’t a “question” merely be a subset of “aside”, or “quote”?
Tara 3:13 pm on November 13, 2010 Permalink
+1 for Audio. Podcasters would truly benefit from this.
Andrés Sanhueza 10:24 pm on November 14, 2010 Permalink
Tumblr also has another post “format” based on formspring.me functionality I believe is called “Answer”. It can’t be made by the frontpage, but by answering a message another user sends you by a contact form. It displays the question, the name of the asker and your reply. The first two are not editable, I believe.
Also, I wondered how something from Scribd, SlideShare or Issuu conceptually fits in those. In Tumblr, raw embed codes are supported by ‘video’, but still.
Andrew 3:09 am on November 16, 2010 Permalink
I know that I’m a bit late to be posting to probably have any effect, but limiting it to those that are used on Tumblr is probably the way to go.
I see ‘status’ and ‘aside’ as being very similar, and probably similar enough to warrant the use of just one of them. From what I see, they are virtually identical, so why the need for 2 of them?
I think it should stay as ‘image’ because not every image is necessarily a photo. They should be generic terms, and photos are just part of the types of images possible.
Otherwise, the list looks fine, but personally, the final list I think should be:
But allow for others as well. There is no point in fixing the number of post formats when there are many others that people could use that aren’t necessarily used by others, such as ‘podcast’/'audio’
Alex M. 1:53 am on November 20, 2010 Permalink
It was purposefully decided to not allow the extending of the post formats feature. The whole point of the feature is standardization. Post formats aren’t a new feature (tons of themes have already implemented similar functionality), they’re strictly a way of creating a list of types that all themes should support.
If one theme supports podcasts by creating the type “audio” and another theme supports podcasts by creating the type “podcast”, then if you switch themes your type won’t carry over. That’s exactly what post formats is seeking to avoid.
Beau Lebens 2:39 am on November 17, 2010 Permalink
I wonder if some of the work for Activity Streams could help drive this: http://activitystrea.ms/schema/1.0/activity-schema-01.html#anchor5
Andy Beard 10:26 pm on November 20, 2010 Permalink
1. A generic “embed” type for pasted code
There are lots of embeds, documents, maps, full scrolling timelines etc
2. A generic embed type which is Oembed – thus it is a link that actually uses oembed, whereas the standard link wouldn’t necessarily do this.
For both of these the class could be modified based on source for some extra styling possibilities.
Azizur Rahman 1:58 pm on December 30, 2010 Permalink
@nacin: link to Codex Page is broken in your original post. remove the “.” from the end of the link.
Alex theberge 7:08 pm on January 9, 2011 Permalink
I’m also wondering why not “review”, “business card” and “Location” as well? Even “Recipe” would be wonderful. Why not create Post formats that adhere to or coordinate with the drafted micro-formats?