WordPress 3.6: the Post Formats UI feature
Post formats is going to be a major win for 3.6. It’s one of those features that has so much potential, but it really falls short in usability and honestly we haven’t really taken the time to truly show what it can do. We’re going to re-think the admin UI for post formats, similar to what Alex King did with his WordPress Post Formats Admin UI plugin. The goal is to make post formats much more user friendly and then show them off with the 2013 theme.
We’ve chosen @helen as lead for this project. Helen has done some amazing stuff customizing the post screen for various projects, and we’re glad to be able to leverage that for core.
Anyone interested in helping with this feature, please comment to let us know. The 3.6 schedule is considerably shorter than the 3.5 schedule was, so we really need to get moving on things as quickly as possible.
Manny Fleurmond, 
Paul 6:15 pm on January 7, 2013 Permalink
take a look at what Hybrid does in its latest release
http://themehybrid.com/docs/tutorials/post-format-tools
Aaron D. Campbell 7:32 pm on January 7, 2013 Permalink
That links seems to be for members only
Justin Tadlock 7:35 pm on January 7, 2013 Permalink
Here’s the open link: https://github.com/justintadlock/hybrid-core/blob/master/extensions/post-format-tools.php
Paul 6:45 pm on January 8, 2013 Permalink
thanks Justin
Chip Bennett 6:16 pm on January 7, 2013 Permalink
I think standardizing on the Post Formats UI, the types of data/content used for each post format type, and the method of input of those data will be a HUGE win for Theme developers and end users alike.
The Theme Review Team will support your efforts here. Please keep us in the loop, so that we can update Theme Review guidelines accordingly, and help educate Theme developers regarding any changes.
I’ll pass the word over to the team, in case anyone wants to contribute specific UI ideas.
Jonathan Christopher 6:24 pm on January 7, 2013 Permalink
Really loving the idea of this getting some love for 3.6! Like Alex King’s implementation, will the UI update include customization along the lines of Custom Field storage as well? Thinking specifically about a Link post, will there be a core-defined Custom Field correlated with that? I realize that’s a really specific question so I’ll generalize it by asking if those types of conversations (data storage) will be a part of the UI update?
Helen Hou-Sandi 1:46 pm on January 8, 2013 Permalink
Going to stay away from implementation details here, – “just” gauging interest
Don’t want to have discussion getting buried/lost.
nphaskins 6:25 pm on January 7, 2013 Permalink
+1
Pulling some ideas from Alex’s stuff would be pretty sweet.
http://alexking.org/blog/2011/10/25/wordpress-post-formats-admin-ui
Mike Schinkel 6:28 pm on January 7, 2013 Permalink
I’d love to see the ability in a plugin to move the TinyMCE editor to the bottom of the post screen rather than have it anchored where it has always been. Hopefully addressing post formats would make this a requirement?
Helen Hou-Sandi 6:30 pm on January 7, 2013 Permalink
There’s a hook between title and editor as of 3.5. It’s purposefully not a sortables (metaboxes) area, but perhaps it’s at least helpful in that regard?
Mike Schinkel 7:14 pm on January 7, 2013 Permalink
HI Helen,
Thanks, yes I did notice that hook. In part it triggered me to want to be able to move the editor even more.
Much of the custom post type work I do would prefer to have the body at the bottom vs. at the post. So it’s not really helpful because metaboxes still go below the editor. I can dream? 
Helen Hou-Sandi 2:38 pm on January 8, 2013 Permalink
I guess I find sortable metaboxes above a statically-placed TinyMCE instance disruptive in practice, especially since a user could presumably drag anything into any given sortable area. Since the title is similarly static in placement, it seems sensible that the hook between the two not be a sortable one. I put lots of things in edit_form_after_title, but haven’t (yet) wanted them to be in the metabox “look” or be draggable.
Justin de Vesine 9:22 pm on January 7, 2013 Permalink
Speaking of sortables and TinyMCE, we recently needed to handle that gracefully, and we’re doing so by destroying the editor instances at the start of a sort and re-creating them afterwards, which seems to be both stable and reasonably speedy. (See https://github.com/Annotum/Annotum/commit/28f50e13ee00d63edd5563fa00dd45abcacf4e10 for the implementation in the Annotum project.)
Vitor Carvalho 4:13 pm on January 8, 2013 Permalink
That is very interesting indeed! It would be nice to have it implemented in future WP. Thank you Justin
Vitor Carvalho 4:11 pm on January 8, 2013 Permalink
The problem about TinyMCE is that it cannot be sortable. Once instantiated it cannot be moved through the DOM.
Helen Hou-Sandi 5:29 pm on January 8, 2013 Permalink
We’re not talking about putting TinyMCE in a metabox here.
Manny Fleurmond 12:13 pm on January 19, 2013 Permalink
Just riffing for a bit: I hope people get what I’m trying to convey:
So when I look at a post, I see the content data (the title and content), ie the meat and potatoes of a post and I see meta data/ taxonomies that add to the main data to categorize/tag/describe it. The content has is own area and meta data/ taxonomies/ etc are relegated to meta boxes. Looking at the different post format examples from other CMS’s, you are basically changing the type of content and therefore are changing the type of content fields you are using. Video posts may need a title and description, but they also need a video source url. An aside doesn’t even need a title. Post formats are just presets of custom content fields.
In order to beef up post formats, I think we need to add hooks and an API that allows developers to change the content area of a post; to basically upgrade a few custom fields to content status. Not only should developers be able to add fields that are important enough to be content alongside the post title and post content fields, they should be able to replace those fields entirely, if they so wish. I have a side project where I disabled the title and content, to be replaced by a URL field and it always felt weird to me that I had to put that field in a meta box when it should have been considered the main content. A new post format UI would basically just be picking out a preset of fields that best fits the format of content. As Mike Schinkel suggested in the UI update post, flexibility is key as it would open some nice functionality for plugin developers as well as make WP a lot more robust.
Edward Caissie 6:28 pm on January 7, 2013 Permalink
Something to keep in mind (perhaps more so for the Theme Review Team) is not to go forward with Post Formats pigeon-holed into a rigid display of their associated content. I can see strong recommendation being made for how one might use the Post Formats but I would like to see anything stronger than a recommendation.
Edward Caissie 6:30 pm on January 7, 2013 Permalink
er, I meant: “… I would *not* like to see anything stronger …”
Chip Bennett 6:49 pm on January 7, 2013 Permalink
I think the “big win” opportunity here is in establishing a standard convention regarding what *types of content* apply to each post format type, and what *type of data* each of those types of content are.
For example, some post format types lend themselves well to *not* having a Post Title. That convention can be established, and Post Title hidden from the UI. (The associated Theme Review guideline would be “must not display Post Title for format types X, Y, Z”)
For another example, some post format types have been implemented using post custom meta data. For all such instances, it is hugely important to standardize on hat post custom meta key/value.
Implementation of Post Formats has been a bit of a “wild west”, with different Theme developers making different assumptions about appropriate content and appropriate data types for each post format type. I would love to see those assumptions standardized – and it is on that standardization that I think the WPTRT dovetails nicely into the effort by the UI team.
Mark Jaquith 7:19 pm on January 7, 2013 Permalink
This. We don’t want to constrain theme design, but we do want theme designers to know what data they’re getting, in which format, and to know which assumptions have been made about the utility and availability of various pieces of that data.
Devin Reams 7:25 pm on January 7, 2013 Permalink
Agreed. The frustrating part of formats so far has been the fact we standardized on the formats, but not other benefit/data to go with it. So we still have to “throw” everything into the_content. A consistent meta data format would be a big win here.
But, you say, “what If someone switches to a theme without post formats, don’t they lose that meta data”? Sure, which is why we came up with some code to ‘fall back’ in those cases (attach the meta to the content display, basically): http://alexking.org/blog/2011/11/02/wordpress-post-format-fallbacks
Daniel Jalkut (Red Sweater) 7:45 pm on January 7, 2013 Permalink
I want to strongly agree with this and also point out that from a 3rd-party client developer perspective, this has implications on the ability to present a meaningful editing UI as well. I develop a blog editing app for the Mac, that also supports Tumblr which has the closest comparable feature to this that I know of. With Tumblr, I present e.g. the quotation and the attribution of a “Quote” type post separately, in indepent fields. With the WordPress “everything in content” approach, it would be possible to structure the content of the post on first edit, but impossible to reliably pull it apart again when opening up to re-edit.
I imagine the same problem is limiting the ability of theme and plugin developers to innovate in the wp-admin built-in editor.
Aaron D. Campbell 7:26 pm on January 7, 2013 Permalink
This is huge. We want users to be able to change themes and know that all their posts (in any format) will continue to work as expected. We don’t want one theme using _link_url postmeta and another _url because that’s when content is lost (or at least appears lost to the user, and for all intents and purposes it might as well be)
grantpalin 12:01 am on January 9, 2013 Permalink
I agree, a standard convention will be useful to guide themers in implementation – something that’s seemed lacking since formats appeared. Guidelines, not rules!
Jonas Bolinder (jond3r) 12:36 pm on January 9, 2013 Permalink
A too strict position on which data is allowed or not for a theme too display for a certain post format is discouraging. In particular a theme might want to display a relevant Post Title, which can be beneficial for understanding the content for humans (and bots).
Zach "The Z Man" Abernathy 6:29 pm on January 7, 2013 Permalink
Count me in! I’m on-board for whatever is needed in 3.6
Travis Northcutt 6:39 pm on January 7, 2013 Permalink
@Helen, when/where will you be discussing what needs to be done? I’m not *sure* I can commit time to helping ,but I’d like to follow along in any case.
Helen Hou-Sandi 7:59 pm on January 7, 2013 Permalink
Should be like anything else in development – likely IRC for much of the interaction to keep things moving quickly, along with the ticket #19570 on Trac (especially summaries). Right now we’re gauging interest in various proposed features/release items.
Travis Northcutt 8:04 pm on January 7, 2013 Permalink
Thanks! I haven’t gotten involved in contributing to core really in the past (beyond chiming in on a ticket here and there), so I wasn’t sure what exactly to expect.
Slobodan Manic 7:23 pm on January 9, 2013 Permalink
I’m sure I can commit time
Really, would love to help with this one, agree with everyone else that post formats could use some standardization.
Justin Sternberg 6:55 pm on January 7, 2013 Permalink
I’d be happy to help out with this.
prettyboymp 6:57 pm on January 7, 2013 Permalink
A set of functions like the post_type_supports() functions of custom post types would be extremely useful.
I use it frequently to create a handler (form controls/save callback) for certain types of post meta and can turn it on for any post type by just making that post type support it. Similar functionality for post formats would make it possible to carry some of these over instead always unnecessarily needing a custom post type.
Tammy Hart 6:59 pm on January 7, 2013 Permalink
I’d like to help out with this as well. I’ve customized Alex King’s approach and used it a couple of times myself.
wycks 7:23 pm on January 7, 2013 Permalink
This feature did meet with some pushback when it was first released because of lack of interest ( ≠ tumblr).
Since then has there been any indication that people are using it? Can someone show me some good examples, besides ma.tt?
Do you think it’s apparent lack of use is because of the UI?
™ my opinion , I might be totally wrong.
Devin Reams 7:31 pm on January 7, 2013 Permalink
See Alex’s blog or my blog using the FavePersonal theme which has the aforementioned “post format UI” (and associated meta data) which allows for a pretty nice user experience (both for publisher and visitor) a la tumblr. It allows a lot more to be done when creating responsive designs, too.
I see a ton of other themes marked ‘post-formats’ in the theme browser on WP.org but the sample data doesn’t seem to take advantage of it (or the themes I saw don’t…).
Helen Hou-Sandi 8:03 pm on January 7, 2013 Permalink
The various mobile apps also have post format support built in, with the image format being the one that probably sees the most use, as the “Quick Photo” feature in the apps automatically assigns that format. Of course, it’s up to the theme to do something special with it.
The issues I see with adoption (or lack thereof) is with the lack of UI that makes an actual difference for the end user besides choosing from some radio buttons that don’t show you what’s different about the choices, and lack of data standardization for theme authors to take advantage of. It’s not something that’s going to be used by everybody in every application, and there are no illusions about that, but for those who do use it, it’s valuable and desirable, and we should always be making things better.
sara cannon 10:53 pm on January 7, 2013 Permalink
count me in to help here as well.
Alex King 1:02 am on January 8, 2013 Permalink
Obviously I’m a big fan of this getting into core. The trac ticket is here for anyone interested:
http://core.trac.wordpress.org/ticket/19570
The code in the GitHub repos should work fine with WordPres 3.5, but obviously we wouldn’t want the JS hacks that were needed to implement it as an add-on.
Having thought it through and implemented this once already, I’m still pretty pleased with the overall approach we used and the naming conventions we established. I’d *really* love to see the post meta naming conventions maintained if at all possible.
Helen, let me know if there are things I can do to help out!
Mel Choyce 2:24 am on January 8, 2013 Permalink
I’d like to help out with this, if there’s still room.
Amy Hendrix (sabreuse) 2:49 am on January 8, 2013 Permalink
Sign me up.
grantpalin 12:04 am on January 9, 2013 Permalink
I’d be happy to help with this in the form of suggestions and feedback. I’ve been puzzled by the lack of a real UI for using formats, and have used Alex King’s plugin to fill the hole. Something worthwhile could be to write a guide on migrating from a plugin-based solution to a core-based one, which I might be able o help with.
Jonas Bolinder (jond3r) 12:52 pm on January 9, 2013 Permalink
I’m prepared to contribute (with code and opinions).
davebc 5:41 pm on January 9, 2013 Permalink
I’m no coder, but I’ve been dying for post formats to get this attention since they debuted and have stuck with Tumblr solely for this reason ever since. There are few things I won’t do to help test, if you could use that.
One request: please don’t overlook the bookmarklet when updating the UI for these features.
Japh 9:36 pm on January 9, 2013 Permalink
I know I said it in IRC the other week, but just to be sure: I’m in for this one!
Lance Willett 4:50 pm on January 17, 2013 Permalink
@aaroncampbell Can you tag this post “post formats”?
Helen Hou-Sandi 5:16 pm on January 17, 2013 Permalink
Done.
Aaron D. Campbell 5:53 pm on January 17, 2013 Permalink
Thanks Helen
Lance Willett 4:52 pm on January 17, 2013 Permalink
In case it’s helpful, here is some code that might be helpful even if for how *not* to implement. Heh.
We have several themes on WP.com where post formats are crucial to the theme and where we needed to have “content parts” broken out, like in a Video post. We wanted just the video URL or markup and not the rest of the post content.
From the Esquire theme, for example:
https://wpcom-themes.svn.automattic.com/esquire/content-grabbers.php
The regex there handles URL, video, and audio.
Todo to make this much better:
1. Use
get_children()instead to replace the SQL in all thes grabber functions2. Cache the result in post meta, then refresh it only when the post changes
We’d obviously love to replace all this code once core supports getting the better post format UI and being able to “grab” the content pieces out cleanly.