Post Format UI and saving is in core. Th…
Post Format UI and saving is in core. Themes announce their support of various formats like so:
add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );
The UI looks like this, right now:
That UI only shows up if your theme supports it. By default, only Posts support it, but you can add support to other post types like so:
add_post_type_support( $post_type, 'post-formats' );
Twenty Ten has support for the “gallery” and “aside” post formats (it retains its backwards compat support of the special “Asides” and “Gallery” categories).
Post Format is shown on the post listing screen:
That was done very quickly, and I’m soliciting feedback for how that should be conveyed. Head over to the ticket.
Mike Schinkel 4:55 am on November 5, 2010 Permalink
Awesome work! Kudos.
Melvin Ram 5:57 am on November 5, 2010 Permalink
This is great. I’ll give it a spin in the next says. Kudos on this feature.
Banago 7:41 am on November 5, 2010 Permalink
That is great – I’m so exited to make use of them.
Louy 8:58 am on November 5, 2010 Permalink
Cool!
quicoto 9:50 am on November 5, 2010 Permalink
So cooool
Edward Caissie 1:02 pm on November 5, 2010 Permalink
There is a great deal of potential with this concept. Great job!
John Blackbourn 2:28 pm on November 5, 2010 Permalink
Is there a method for adding new post formats? It seems the supported post formats are hardcoded into get_post_format_strings().
Otto 2:32 pm on November 5, 2010 Permalink
There’s a filter on the output of that function. Called, oddly enough, “post_format_strings”.
John Blackbourn 2:48 pm on November 5, 2010 Permalink
As of r16205 there isn’t. Something gone missing?
Peter Westwood 2:51 pm on November 5, 2010 Permalink
Removed in r16198:
Mark Jaquith 3:42 pm on November 5, 2010 Permalink
There was, but I yanked it. The idea here is to standardize. Post Formats are, to start, not much more than a taxonomy convention with a UI wrapper. So if you have “Asides” on one theme, you can transport them to another theme. If people create their own formats, their portability will be zero, or close to zero. While this feature is getting started, at least, I think it makes sense to have requests for new formats go through core. That way we can announce new ones with fanfare, put them on the Codex page, and themers can update their themes to support them. Maybe once we’ve iterated a few times and have covered all the common use cases, we can make it easier to deviate. But to start, a managed economy will result in better standardization.
It’s an unusual way to do things for WordPress — the difference here is that the main sell we’re offering is portability, and flexibility would hamper that goal.
Otto 6:57 pm on November 5, 2010 Permalink
Well, if we’re going to standardize to a set, then might I suggest adding “audio” for podcast usage?
Otto 6:59 pm on November 5, 2010 Permalink
Possibly also “media” or something else for generic multimedia usage. Say for including Flash content that doesn’t fit into Video?
Alex M. 8:25 pm on November 5, 2010 Permalink
Since it requires the theme to add support, why not just add a bunch? Video, audio, a generic media, image (for a photoblog style), etc.
Mike Schinkel 12:01 am on November 6, 2010 Permalink
@Mark – That is beyond awesome. Just wow! As many on wp-hackers know I’ve pushed many times for additions to the core to enable standardization on various fronts and every time I’ve gotten push-back and told that I could write the feature myself. Clearly the idea of creating a standard to promote interoperability among themes and plugins wasn’t a concept that was being appreciated, at least not related to my suggestions. So I’m just REALLY glad to see a feature added to core not because core needs it per se but because it enables themers to add layers of functionality that can be ported between themes. This has the potential to be hugely beneficial to the WordPress ecosystem. Double kudos to you and the team for this one.
Tung Do 3:20 am on November 8, 2010 Permalink
@otto and @alex – i agree. besides multimedia (image/ videos/audios), i’d like to add one for events. and maybe in future releases, we could link event format to calendar and create a unique archive page for event format, which displays event posts within a calendar like layout.
Nicolas 3:12 pm on November 5, 2010 Permalink
Don’t the post formats get their own template in the template hierarchy? Like single-postformat.php, although that could conflict with custom post types.
Nicolas 3:34 pm on November 5, 2010 Permalink
Wouldn’t it be nice if the default post format was post? get_template_part( ‘the-post-’, get_post_format() );
Lloyd Budd 5:06 pm on November 5, 2010 Permalink
How does it feel with “Format: Post” as “Default” conveys little information?
Jane Wells 5:21 pm on November 5, 2010 Permalink
I think the issue with that is that they’re all Posts. Blog post, maybe.
Lloyd Budd 7:38 pm on November 5, 2010 Permalink
Great point. “Blog post” sounds good to me, or pretty much anything other than “default”. I remember a theme named default. She was a good theme.
Jose Pardilla 10:08 am on November 12, 2010 Permalink
I’d use “Regular post” to be clearer. Another option is “Normal post” but i think that might convey other posts formats are not “normal”, that’s why Regular post sounds best to me.
Mike Schinkel 10:44 am on November 13, 2010 Permalink
@Jose – Wouldn’t “Regular” imply the others are “Irregular?” (See, problem is it’s turtles all the way down.)
Jose Pardilla 5:18 am on November 14, 2010 Permalink
Got me there
Matt 5:30 pm on November 5, 2010 Permalink
I think hiding this behind another publish box line is too invisible and will lead to poor visibility of this functionality for themes that support it. Right now that box is bad for a lot of reasons, like all of the identical action links that lead to different things, but I still feel the ideal UI for this is a radio selector. (Which would be useful for other taxonomies too.)
I would rather most themes do not use this default UI, even if it’s improved as I suggest above, because ideally we want them to go a lot further. For example: If something is an Aside, why show the title box? Formats have the opportunity to simplify people’s posting experience, as-is this is just another option.
Peter Westwood 5:33 pm on November 5, 2010 Permalink
Maybe we need to auto-hide even more of the metaboxes when they don’t apply to the format as well?
Matt 5:49 pm on November 5, 2010 Permalink
To me that suggests more of a tab UI above the whole post area, rather than something inside the publish box. (Things may jump around.) That might be a lot for 3.1, or maybe not.
Nicolas Kuttler 6:16 pm on November 5, 2010 Permalink
If you don’t show a title box you’ll have to re-do the whole posts overview as well. Or your asides will all show up as Auto-Draft (or what it was). Not very user-friendly.
Mo Jangda 3:48 pm on November 11, 2010 Permalink
Something Tumblr-like perhaps? http://yfrog.com/gqazxp (though, Tumblr takes you to a separate page when you select a type — which is lame)
Mike Schinkel 12:02 am on November 6, 2010 Permalink
@Matt – Would love to see a wireframe/mockup of what you are envisioning…
Ian Stewart 8:07 pm on November 8, 2010 Permalink
It would be awesome to be able to select/switch post formats with 1-click (as opposed to 3 right now).
Aaron D. Campbell 12:49 am on November 11, 2010 Permalink
So where do we draw the line between post formats and custom post types? The main difference seems to be that you have a lot more control and power with cpts (including over the ui), and formats are supposed to be theme-agnostic?
Alex M. 1:02 am on November 11, 2010 Permalink
It’s just a way to flag the post as a certain style/type so that the theme can style it differently — they’re still normal posts and therefore don’t deserve a CPT.
Asides are posts for example, but they’re short and so are often styled differently.
Andrew Nacin 12:55 pm on November 11, 2010 Permalink
I like to call post formats intra-loop styling for your blog. Post types are non-post objects. The use cases only overlap when you’re using one of them horribly wrong.
Jose Pardilla 5:14 am on November 14, 2010 Permalink
I did a couple of mockups of what i think would be a nice way to show them. It would be two-click, easy to spot but not distracting (at least to me), and since it’s something i’d probably edit before writing the post, i think the position is not bad at all. In any case i think a little mockup can help others get more ideas too. I did put some quick and dirty icons copy pasting from the admin panel.
The position in the title box may not be the best one for lower resolutions but somewhere near the area would feel right to me.
http://s.moskis.net/formatpostmockup1.png
http://s.moskis.net/formatpostmockup2.png
Andrew Nacin 3:00 am on November 20, 2010 Permalink
Probably not the best position for it given that some formats don’t even have titles, but this is really cool. Also a fan of the icon attempts.
This is too late for 3.1 though, we won’t be thinking about this until 3.2 at the earliest and we’re happy with the UI we have now. But we’ll revisit this at some point and I’ll keep this mockup in mind for sure.
Andrew Nacin 3:01 am on November 20, 2010 Permalink
Also, if you’re a designer, you might be interested in participating in our UI group: http://make.wordpress.org/ui/. See the sidebar on that blog for their meeting times.
Pete Mall 5:34 pm on November 5, 2010 Permalink
What about a post formats drop-down in edit.php so users can easily see all posts of a particular format… http://petem.in/n
mfields 1:32 pm on November 11, 2010 Permalink
I really like this idea, but think that it should extend to all taxonomies which the users could define via screen options.
GarryHJ 2:48 am on November 8, 2010 Permalink
Mark
While you’re looking for post types / formats – please add “events” to the list.
Events have their own format which could be supported by custom fields, taxonomies etc – e.g. when where what who and so on. In many ways, this is no different to media and video/audio needing their own format. Events have (at least) two dates associated – date of posting, and date of event – these are rarely the same.
Gaz
Mike Schinkel 4:23 pm on November 10, 2010 Permalink
I brought up events too, but then they pointed out that Events are really better handled by Custom Post Types which you can already do in v3.0. Post Formats are really for different use-cases. FWIW.
Konstantin Kovshenin 8:05 am on November 8, 2010 Permalink
@Mark, this is great news, stuff that I had to earlier do with post tags and categories is packed into post formats. Although I’m still quite concerned about, say styling out a gallery post with text before and after the thumbnails. I used to do this through shortcodes before, guess I’ll now have to combine the two. Anyways, thanks for sharing this, waiting for 3.1
Cheers.
Tobias Fox 9:15 am on November 8, 2010 Permalink
I really like the idea giving post a certain format. That may save some time for those who insert lots of pictures from time to time.
Can’t wait to see the results. Happy coding!
Daniel Wiener 4:24 pm on November 8, 2010 Permalink
I have wanted this for so long.
Mo Jangda 3:59 pm on November 11, 2010 Permalink
Are there eventual plans to expose fields specific to certain types? For example, a quote should probably have an “Author” and “Source” fields. Or is this better left to plugins?
redwall_hp 10:13 pm on November 11, 2010 Permalink
If the plan is to define specific post formats, Tumblr-style, then that would be logical.
Mike Schinkel 4:35 pm on November 11, 2010 Permalink
A question to ponder; given that Post Formats are “intra-loop styling”, it would seem that some of them could be Post Type-specific? For example, I could see an Event as having different formats such as “Single Presentation”, Single Day”, “Multi-Day”, and probably more. Thoughts?
Andrew Nacin 4:40 pm on November 11, 2010 Permalink
It’s a way to describe their functionality, but that’s not the reasoning behind them, which is standardization and portability between themes.
Mike Schinkel 4:51 pm on November 11, 2010 Permalink
Good point. I applaud the effort to enable a standard for portability; that’s probably more important that too-much flexibility in this case. People can always come up with a custom field value as a switch for their own custom themes.
List of post formats « WordPress Development Updates 6:30 pm on November 11, 2010 Permalink
[...] Comments Mike Schinkel on Post Formats in CoreAndrew Nacin on Post Formats in CoreMike Schinkel on Post Formats in CoreMo Jangda on Post [...]
Nick 4:13 pm on November 13, 2010 Permalink
Love the feature already. It always annoyed me to format posts by selecting a category. Can’t wait to select , or formats in the WordPress for iOS app.