Working with WordPress post formats and quotations

Recently I published an article about marking up quotations with HTML5, a prelude to this somewhat more practical post about working with quotations and WordPress post formats. My goal here is simple: use WordPress to post quotations conforming to the HTML5 specification without having to enter markup by hand. To accomplish this I will be using the Post Formats Admin UI plugin and a custom content-quote.php template.

WordPress introduced Tumblr-like post formats in version 3.1. However, as lead developer Andrew Nacin says, “the actual implementation of post formats is pretty dry”. Adding post format support to a theme doesn’t really do much of anything. Presently, WordPress post formats are little more than a set of vague standards for theme and plugin developers to follow. Here is the specification for the “quote” post format (and be sure to see some notes on usage at the bottom of this post):

quote – A quotation. Probably will contain a blockquote holding the quote content. Alternatively, the quote may be just the content, with the source/author being the title.

Well, that’s helpful. Maybe the post will contain a blockquote element, maybe not. (Justin Tadlock offers a quick fix for this.) Not much is said about quotation metadata.

The WordPress team acknowledges that the implementation of the post format feature needs a lot of work. In fact, post formats will receive a major update in WordPress 3.6, currently under development. Follow the post format tag on the Make WordPress Core blog for the latest.

In the meantime, my weapon of choice is Crowd Favorite’s Post Formats Admin UI, a proof-of-concept plugin released on GitHub and submitted to the WordPress core. The new tabbed interface is slick but I am more interested with what is going on behind the scenes.

This plugin uses custom fields to store additional post format metadata (where necessary), an approach that has a few drawbacks (as well as a fallback plan). Not that it really matters, but I support the use of custom fields; storing post format metadata with post content in hidden tags or shortcodes sounds like a recipe for disaster. Besides, it won’t be difficult to add a few wrapper functions to WordPress 3.6 to allow easy access to specific post format metadata (e.g. get_post_format_meta( $post->ID, 'source_name' ) or something like it).

Aside from proposing how to store post format metadata, the Post Formats Admin UI plugin also proposes what post metadata to store. The “quote” post format joins the video and audio post formats in using custom fields—two of them, by default. From Alex King’s original introductory post:

Quote posts have two additional fields. One for the name of the person being quoted (_format_quote_source_name), and one for an attribution link (_format_quote_source_url). These can be used in the theme to present the quote and attribution in a consistent manner.

This is a good start.

Now, consider a hypothetical scenario. Let’s say that we wish to share quotations with WordPress using appropriate markup while conforming to the HTML5 specification. (Read my post on marking up quotations with HTML5 for a discussion of the semantic gymnastics involved.) Since the cite element can only be used for the title of a work, not the name of a source, we are stuck. Either we use some kind of nasty kludge, enter additional markup by hand, defy the specification, or avoid using cite altogether. Given that 22% of web sites run WordPress it strikes me as a sensible idea to structure post format data to at least make it possible to mark up quotations using relevant elements while conforming to the HTML5 specification!

The fix is simple: add another custom field, _format_quote_source_title. With the addition of a “source title” field it will be possible to use the cite element and mark up quotations according to the HTML5 specification.

Personally, I would also add _format_quote_source_date, but that’s just because I like seeing quotations attributed in the format “Name, Title, Year”. The semantic argument for doing so is not nearly as strong so I will focus on the merits of adding a dedicated title field for the remainder of this post. This feels like a more important case to make given that the WordPress team is currently defaulting to only two additional fields for the “quote” post format.

Modifying the Post Formats Admin UI plugin to handle an additional field or two is a straight-forward cut and paste job, but you can also try out my fork on GitHub if you’d rather not make the edits yourself.

By default the Post Formats Admin UI generates titles for quotations and status updates from the first 50 characters of the post contents. I prefer generating titles based on the first ten words; the results tend to be much cleaner. This isn’t hugely important since post titles are seldom displayed for these post formats—but titles will still show up in the feed, sidebars, navigation between posts, etc. Check out this gist for an example of how to generate titles from the first ten words of a post.

Another thing to keep in mind: slugs are generated from post titles but post titles are generated after a post is saved. If you care to have a nice post slug you will want to save a draft of a quotation or status update before publishing it.

Now to the markup and styling of quotations.

This gist features a modified version of the Twenty Twelve content-quote.php template and some example styling appropriate for a child theme. I based the markup on the pattern I outlined in my previous post about quotations and HTML5. I happen to prefer nested article elements with quotation metadata wrapped in a footer element; this makes the most sense to me based on my interpretation of the HTML5 specification. More reputable designers than I prefer to use figure and figcaption instead. There is no real standard here so it is really up to you.

Perhaps I should outline the logic of using a nested article element instead of mixing post metadata with quotation metadata. Twenty Twelve already uses the article and footer markup pattern for post metadata. Conceivably, we could include quotation metadata as well and do without the nested article or figure element wrapping the quotation and its metadata. This results in less markup but makes a semantic mess of things: is the author of the post also the author of the quotation? How about the post date—is that when the quotation was first uttered or written? To avoid confusion the metadata within the footer element should describe just one thing. Wrapping a quotation in an article element defines it as an independent piece of content with its own metadata.

As for styling, the only thing worth noting is the use of the content property. This adds quotation marks and a quotation dash to the quotation so users needn’t worry about such conventions.

If you follow all this you’ll end up with neatly formatted and semantically sound quotations like this one.

In conclusion: patching the Post Formats Admin UI to handle extra fields is a snap, presenting quotations according to the HTML5 specification isn’t rocket science, and I hope the WordPress post formats team considers the merits of adding a dedicated “source title” field to the project.

Finally, an admittedly pedantic note on usage: English is an extremely mutable language but this doesn’t mean we should settle for linguistic anarchy. There are conventions that should be followed in specific contexts, for instance with regards to the use of the words “quote” and “quotation”. The word “quote” is a verb in formal English, not a noun. You can quote a quotation—but you really shouldn’t quote a quote in polite company.

While the use of “quote” as a shorthand way of saying “quotation” is well-established in everyday, casual usage, it strikes me as unwise to standardize on the informal in the WordPress core simply because Tumblr did it first. Again, with so much of the web using WordPress it strikes me as important to get this sort of thing right.

Related posts