The next major release of WordPress is already around the corner. This is a big one for theme authors with a major focus on post formats. There's a new post formats UI for the WordPress end-user, along with a new system of handling and displaying this data in our themes. In this article, I'll cover what you need to know as a theme author for post formats in the upcoming WordPress 3.6.

Introduction

In terms of recent major WordPress releases, 3.3 made some significant improvements to the overall admin interface, 3.4 introduced the theme customizer, and 3.5 incorporated a new way for users to manage media. If you're an author with themes currently out there, you've probably been pretty comfortable with these last few major releases and haven't had to do much in terms of updates or customer support. However, this might not be the case with WordPress 3.6.

The big focus of 3.6 is on post formats. Post formats were introduced back in 3.1, but until now, have always come with quite a bit of inconstancy. Everyone has a different take on post formats and they seem to be more or less popular in different circles of the WordPress community, and with different types of themes.

Whether you're a fan or not, WordPress has taken a bold, new stance on post formats. So it's time to start thinking about them in your theme designs, no matter what kinds of WordPress themes you're creating, or whether you're already incorporating them or not. Although you should always be doing this, at a minimum, this is one of those major WordPress releases that you'll really want to test with your themes before it gets officially released.

As a WordPress theme author, you'll want to understand the new post formats UI that'll potentially be presented to the end-user, how this corresponds to the new concept of structured post formats, and all of the new theme functionality 3.6 introduces for post formats.

Hopefully, this article will encourage you to take an early look at WordPress 3.6 beta, start working with post formats, and get things rolling with your themes before it hits the masses.

Post Format UI

The first thing WordPress end-users are going to notice when updating to WordPress 3.6, and what is going to effect you as a theme author, is the all-new post formats UI.

This post formats UI design has already gone through some changes in the beta stage, but here's where the WordPress team is currently at when the end-user adds a new post, thanks to a little design inspiration from Sara Cannon in Re-thinking WordPress Post Format UI.

Additionally, WordPress has also incorporated a subtle, graphical enhancement when managing all posts by adding an icon representing the current format next to each post title.

Structured Post Formats

The new concept of structured post formats is essentially that WordPress is now establishing standardized structured data that can be used in displaying certain items associated with posts of different formats.

The new post formats UI is more than just a prettier way of selecting the format of each post. With some of the formats, users are now presented with fields to collect this structured data to be associated with the posts. For example, when selecting the "Video" format, the user is then presented with a field to input a video.

Until now, theme authors choosing to incorporate post formats have had to make tough decisions about how users are going to input data for these formats. This has surely added quite a bit of inconstancy for users working with different themes.

The post formats that now have structured data associated with them include the following:

• Image
  The user has an option to designate an image URL and can put in a website URL if they want that image to link somewhere.
• Link
  The user gets a single field to put in a URL for the link.
• Video
  The user can insert a URL or embed code for a video (self-hosted video now supported in 3.6).
• Audio
  The user can insert a URL or embed code for an audio file (self-hosted audio now supported in 3.6).
• Quote
  The user has a field for the quote source and a website URL for that source. Note the actual quote is taken from the content of the post; it'll take the first <blockquote>, or the entire content if that doesn't exist.

While we're still in beta, and all of the above isn't set in stone at the moment, a lot here has been done ultimately for the sake of standardization.

When it's all set, no matter what the outcome, there will always be room for debate. For example, the "Link" format has a field for the link URL, but should it also have a field for the text associated with that link? The default functionality here is that the title of the post serves as the text for the link. Is this right or wrong? Everyone will have a different opinion on these things and you can surely start debates with all of the structured post format data.

With standardization comes these kinds of bold decisions and we need to accept that for the good of the WordPress community to move forward. We need to work with the new standards and do our best to give users a more unified admin experience.

Post Formats Compatibility

For those that do not specifically add support for structured post formats in their themes, WordPress 3.6 has incorporated the new post_formats_compat() function. This new function is filtered automatically onto the_content(). This works hand-in-hand with the new structured post formats concept to output default fallback behavior for this structured data.

For example, in a theme that doesn't specifically add "structured-post-formats" support for "Image" posts, when the theme outputs the_content() with a post of this format, WordPress automatically filters in a display of the image the user selected.

What's interesting about this, and what's cause for some confusing discussions, is around what it means to actually add theme support for "structured-post-formats" for a certain format. When you do this, you're not saying your theme supports the data inputted by the user, but instead, you're effectively saying that you don't want the data automatically filtered onto the_content() for the given post format.

In other words, when you add "structured-post-formats" support for a specific post format with add_theme_support(), you're turning off post_formats_compat() when your theme outputs the_content(). This is the case for the formats -- image, link, video, audio, and quote -- which all prompt the user for structured data.

This idea is a little confusing because until now, using add_theme_support() always meant adding support for some kind of feature that WordPress doesn't support by default, like post thumbnails, custom backgrounds, etc. However, the structured data of post formats is now a default feature of WordPress. So, the use of add_theme_support() in this case is more about how you approach handling that structured data in your theme files.

Don't worry if this isn't quite clicking yet. We'll discuss this further with specific code examples in the next section, and it'll make more sense with some of the new theme functionality you can use.

New Theme Functionality

With the new post formats UI and structured data, WordPress 3.6 introduces quite a bit of a new functionality you can start using in your themes.

Adding Support for Structured Post Formats

Whether or not the final release of WordPress 3.6 has post formats UI on by default, you'll still want to register that your theme supports post formats from your theme functions file, as you did before, for continuity. However, the difference is now that also you want to specify which formats have "structured-post-formats" support.

add_theme_support( 'structured-post-formats', array(
	'link', 'video'
) );
add_theme_support( 'post-formats', array(
	'aside', 'audio', 'chat', 'gallery', 'image', 'quote', 'status'
) );

Notice in the above example, because "link" and "video" formats have "structured-post-formats" support, they didn't need to be added to the general "post-formats" support, as this happens automatically.

The formats it makes sense to add "structured-post-formats" support to could potentially include the ones that collect data from the user -- image, link, video, audio, or quote.

What tangible effect does adding theme support for structured post formats actually have? -- Basically it means that any calls to the_content() for the supported formats will not have 3.6's new post_formats_compat() applied that we discussed in the previous section.

A New Way to Display the Content of the Post

In every WordPress theme you've ever created, you've used the_content() to display the content of the post, right? Well, WordPress 3.6 has a new function called the_remaining_content() that can be used instead, if you want.

<div class="entry-content">
	<?php the_remaining_content(); ?>
</div>

This essentially just outputs the content of the post without the structured post format data in it.

So for example, let's say you're setting up how an "Image" format post displays in your theme. Using the_remaining_content() will output the content of the post, allowing you to display the associated image from the structured post format data in your theme's markup somewhere else. Note that in this case, you would not need to add "structured-post-formats" support for the "Image" format because you're not using the_content().

Displaying Post Format Structured Data

In terms of displaying the structured data, WordPress 3.6 has given some very easy-to-use functions that encompass it all. Within your theme files, these allow you to display the structured data separately from the content, if that's what you want to do in your theme design.

<?php the_post_format_image(); ?>

<?php the_post_format_link(); ?>

<?php the_post_format_video(); ?>

<?php the_post_format_audio(); ?>

<?php the_post_format_quote(); ?>

A practical example in utilizing one of these might look something like this for the "Image" post format:

<div class="entry-media">
	<?php the_post_format_image(); ?>
</div>
<div class="entry-content">
	<?php the_remaining_content(); ?>
</div>

And again to reiterate, with this example of displaying an "Image" post and using the_remaining_content(), you would not need to add "structured-post-formats" theme support because you're not using the_content().

However, if you were to do the following with the_content(), you would need to add "structured-post-formats" support for the "Image" format, or else you'd end up with the image displaying twice.

<div class="entry-media">
	<?php the_post_format_image(); ?>
</div>
<div class="entry-content">
	<?php the_content(); ?>
</div>

Displaying Structured Data at the Top of the_content()

If you're not using the functions we've discussed so far, and you're simply relying on using the_content() to display all of the structured post format data, there's one thing you're going to notice that you may, or may not, find strange. With the exception of the "Link" format, WordPress has setup post_formats_compat() to display all structured data after the content of the post.

If you don't like this, there is a filter you can utilize to change it. Here's how you'd do it from your theme's functions file:

function my_post_format_compat_args( $args ) {
	$args['position'] = 'before';
	return $args;
}
add_filter( 'post_format_compat', 'my_post_format_compat_args' );

Manually Retrieve Meta Data Associated with Structured Formats

If you want to do something custom with this structured data, they're just saved as meta to the posts that you can easily retrieve with get_post_meta(), as always.

<?php
$foo = get_post_meta( get_the_ID(), '_format_quote_source_name', true );
$foo = get_post_meta( get_the_ID(), '_format_quote_source_url', true );
$foo = get_post_meta( get_the_ID(), '_format_link_url', true );
$foo = get_post_meta( get_the_ID(), '_format_audio_embed', true );
$foo = get_post_meta( get_the_ID(), '_format_video_embed', true );
$foo = get_post_meta( get_the_ID(), '_format_image', true );
$foo = get_post_meta( get_the_ID(), '_format_url', true ); // Image URL
?>

And to retrieve a single array of all of the post format meta data for a given post, you can use the new get_post_format_meta() function to grab it all in one shot.

<?php $format_meta = get_post_format_meta( get_the_ID() ); ?>

Displaying a Chat Post

I know that when post formats first came out, the "Chat" format was always one I didn't really know how to handle. How does the user input the chat into the content of the post? How do we display it? With the new the_post_format_chat() function, there is now more of a clear standard.

It's expected that the user is going to put a chat into the content of the post formatted something like this:

John: foo
Mary: bar
John: foo 2

The user can also include dates and times, as well. Note that this would be what it looks like if the user copy and pasted directly from a Skype conversation, which is the idea behind the cool, new chat parsers.

[4/10/13 4:20:30 PM] John: foo
[4/10/13 4:20:58 PM] Mary: bar
[4/10/13 4:22:22 PM] John: foo 2

And then in your theme, where you're displaying the "Chat" post format, you can simply replace the_content() with the_post_format_chat() something like this:

<div class="entry-content">
	<?php the_post_format_chat(); ?>
</div>

This will automatically convert the user's chat entry into some standardized, semantic markup we can all begin to style across our themes. The only real catch with this is that it's assumed the content only contains the chat and nothing else before or after. However, I believe this was pretty common for most theme authors in how they handled the "Chat" post format previously, anyway.

Also, if you want to retrieve the raw parsed data from a post's chat transcript you can use the function get_the_post_format_chat(). This will return an array of the chat transcript data that you could then manipulate with your own HTML markup.

function my_chat_display() {
	$stanzas = get_the_post_format_chat();
	foreach( $stanzas as $stanza ) {
		foreach( $stanza as $row ) {
			// ...
		}
	}
	// ...
}

Hiding the Post Formats UI

And finally, what if you just want to hide the new post formats UI? Well, of course, WordPress gives you a filter for this.

add_filter( 'enable_post_format_ui', '__return_false' );

But I guess the question is more should you do this? I would tend to say that this probably wouldn't be the best thing to do in most cases. Since the post formats UI might now end up being a default part of WordPress, you'd essentially just be stripping it away from the end-user.

If you've created a whole other custom system for collecting data to use with post formats, and you hide the default UI, this might confuse the end-user a little with standardization in the long run. Is that bad or good? I don't know; it's just something to think about. -- Ironically, I think those that have incorporated post formats previously in their themes will have the most work to do with updates for the 3.6 release, as opposed to those that haven't bothered with them yet.

If it turns out the WordPress 3.6 officially has the post formats UI visible by default, and you're hiding the UI just because you're not addressing it in your theme, then I could see how possibly some might perceive this as a little lazy.

Conclusion

With a bold decision to incorporate all of this into WordPress, it's clear that there is a major emphasis on post formats moving forward. It's probably best that you make sure your themes provide at least basic support, if nothing else, to contribute to a more standardized WordPress experience.

Realistically, this is probably a piece of cake with the new post formats compatibility feature. There's a good chance your non-post format theme already pretty much works with the new structured data. At a minimum, you may just want to make sure things like chat transcripts and the quote format display nicely in terms of your theme's CSS.

And for those that want to get creative with displaying posts of various formats within your themes, you now have a ton of awesome new theme functions to play with.