Content modeling for WordPress, part 2: functional and organizational requirements

In the first post in this series, I mentioned that, as you decide whether you need to create new post types, you should think ahead to the way your content will be displayed and sorted. Let’s go back to Rachel Lovinger’s A List Apart article on content modeling. She writes:

But determining which pieces of information need to be captured in separate fields can be a challenge in some cases. Consider the following:

Layout Do some things need to be displayed in a completely different style, or on varying places on the page? You should avoid having markup and styling stored with the content, so ideally each element that needs to be displayed differently should be in its own field. For example, you could just make the subtitle part of the body text and ask your editors to bold it, but how well is that going to work with the RSS feed or on a mobile device?

Reuse Again, a separate field of data can be pulled out and used independently of the rest of the page, but not if it’s all part of one big body text.

Sorting and filtering If you want to be able to sort content by date, or filter content that pertains to a particular city, then these pieces of information have to be in a field by themselves so that they can be used to sort and filter.

Consider the clothing manufacturer I described in the previous post. Once you’ve separated products from blog posts on this site, you can present the product catalog in a much more meaningful way. You could, for example, create a search function specific to the products. You could design different templates to display the individual products, and design photo grid archives for search results and product categories instead of using the usual text-heavy blog archive style.

Sorting and filtering

By default, WordPress sorts all its post types by date, in reverse order (most recent first). This isn’t always appropriate for things other than the blog, and there are a lot of other ways to sort your content. The WP_Query documentation is pretty technical, but it’s the authoritative reference for the various methods of sorting things.

The WP_Query documentation also describes how to filter content. That is, in fact, the entire purpose of the query: to select certain posts from the database. You can select posts by…

• Author. Who wrote it?
• Category, tag, or taxonomy term. How is it grouped?
• Content type. Post, page, or custom post type?
• Date, including a range of dates.
• Custom field. Find only those posts that have a field, or where the field matches a certain value, or posts that don’t have a custom field.

Once you have the list of posts you want, you can choose how to lay them out using the template system.

Layout

In WordPress, each post type can its own templates for single views and archive lists. For a custom post type called product, you’d create a file called single-product.php for an individual product’s display, and archive-product.php for archive lists.

In situations where several post types might be mixed together, like search results, you might use conditional tags to change they way one of them is displayed. For example, you could do something like this in your theme’s search.php file to make sure prices are always displayed for products:

if ( 'product' == $post->post_type ) {
    echo esc_html( get_post_meta( get_the_ID(), 'product', true ) );
}

I’ll talk more about theming custom post types, taxonomies, and fields in a later post.

Reuse, and creating connections between post types

Let’s go back to the book review site, and the problem of alphabetizing authors’ names. What we really need to do is store two versions of the author’s name, the standard one (Sarah Rees Brennan) and the alphabetized one (Brennan, Sarah Rees). The only extra field available on a category or tag is the description — but we can’t use that to sort. We could perform some acrobatics with the template and use the category title field to store the alphabetical version, which lets us sort by name, and display the description everywhere we want the standard version. That would be a big pain.

What we need here is a custom field. But in WordPress, taxonomy terms (that is, individual categories and tags) can’t have custom fields the way posts can. It’s possible to add term meta data — the technical name for category/tag custom fields — with a plugin. Since the WordPress database simply doesn’t support the underlying architecture, though, this plugin would be very complex — and might break if a future version of WordPress does implement term meta data in a different way.

Let’s think ahead a little. Without custom fields, what would the author-category archive pages look like? Without any customization, they’d be a list of all the reviews of that author’s books, in reverse order of the review post dates, with the author’s name at the top. At most, we could add a brief description of the author using the category description field — which doesn’t allow HTML, so it’d be awkward to try to add something like a link to the author’s website.

Clearly, it’d be great to have custom fields for more than just the alphabetized name. WordPress doesn’t support term custom fields, but it does support custom fields for posts…

What if, instead of tying ourselves in knots trying to add custom fields to categories, we created a post for each author? A custom post type could have custom fields that reviews don’t: alphabetized name, links to the author’s site, Goodreads profile, and/or Twitter profile; a photo; and a rich-text biography or description.

Obviously, we’d need a way to connect the authors to the review posts about their books. Here, we turn to the Posts2Posts plugin. This creates simple connections between posts: authors-to-reviews. It’s easy to get a list of all the reviews connected to an author, which we can display on the author’s post page. And it’s easy to get the authors connected to a review, which we can list alongside the custom taxonomies — making it look like the authors are just another set of categories, but actually providing a lot more information that we could with a category alone.

Keeping in mind the limitations on custom fields for taxonomy terms, revisit your taxonomy list and see if any of them would work better as custom post types with connections.

From model to reality

Once you’ve decided between taxonomy terms and custom posts, and listed all the custom fields you’d want for the new post type, your content model should be just about done. That is, it’ll probably change a little as you work on the site, but you probably have a starting point now. If you’re happy with your model, it’s time to actually build all this stuff.

In the next post, I’ll show you the content model for a complex site I built earlier this year. In the subsequent posts, I’ll show you how to build your own, starting with the custom post types (and connections between them).

If you want to start building right now, grab my new book, WordPress for Web Developers. The last chapter includes a working example of a plugin that creates the custom post types, taxonomies, and fields for a university’s course catalog — and, of course, describes how each part of the plugin works.