Content Modeling for WordPress

On fazd.tamu.edu, we found that in addition to the standard pages and posts, we had three distinct things: research projects, tools (the tangible items created during past research projects, like software suites or new vaccines), and people. These will become our custom post types. [Read more…] about Content modeling for WordPress, part 3: a sample content model

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. [Read more…] about Content modeling for WordPress, part 2: functional and organizational requirements

In my recent WordCamp talks on content strategy, I’ve talked about content modeling in WordPress: how to analyze a site’s content and break it up into new custom post types, fields, and taxonomies. I’ve gotten a lot of questions about it, so I’m going to spend six or seven long posts describing how to do this, with examples and diagrams from some of my recent projects.

In her article for A List Apart, Rachel Lovinger breaks down the elements of content modeling:

A content model documents all the different types of content you will have for a given project. It contains detailed definitions of each content type’s elements and their relationships to each other.

If you haven’t read the whole article, I recommend it. Lovinger mentions that every content management system has a basic philosophy on storing content. In WordPress, the basic building block of content is a post. Even pages are just posts with some different attributes (template, parent, order). You can create additional post types and choose whether they should behave like posts or pages. In addition to the post types, WordPress gives us taxonomies (ways of grouping posts) and fields (attributes).

Let’s start with the smallest things we can add to a site: custom fields. A custom field is just an attribute, a new facet of an existing post. It’s one new thing about the content, not the whole of the content. If you’re blogging about ebook sales, for instance, the price of today’s discounted ebook might go into a separate field. Breaking this information out of the body of the post (in this case, the description of the book) into a distinct field offers a couple of benefits. For starters, it lets you display the information in a consistent format without the post author having to remember style guide rules (“the price is always shown between the title and description, in bold, with a dollar sign and two decimal points”). The author just enters the information into its own field; the template and stylesheet do the work of presenting it consistently across all the posts. Using a separate field also lets you sort these posts by price — something you can’t do easily if the price is just the second bold paragraph in a big blob of text. I’ll talk more about this in the next post, on functional and organizational requirements.

Look through your posts. Do any of them share a consistent format? Have your content authors have ever asked you to prepopulate the post editor with a starter template? Consider whether the goal might be accomplished by breaking up the content into several distinct fields. What might those fields be? Almost anything: a simple text input, a second rich text editor like the main post body, a numerical or monetary input, a date/time picker, a color picker, a file upload… see the CMB Class documentation for a list. I’ll talk more about how to actually build these fields later in the series; that class is just one of several options.

This is sometimes called structured blogging, and there are plugins in various industries to add structure to your blog posts (recipes, reviews, etc.), but if your site doesn’t fall neatly into one of those existing industries, you’ll need to build the structure yourself.

Next, let’s talk about grouping posts. WordPress comes with categories and tags, but it’s easy to add more taxonomies. A taxonomy is simply a new set of categories or tags.

Take a look at the things you’ve marked to become separate fields. Are any of them lists of things, where it’d be nice for the user to be able to check a box from a list of presets? Is that list something that’s common to all the posts? A taxonomy might make sense here.

Furthermore, look closely at your existing categories and tags. Do you have several kinds of things lumped together in one big pool? Think back to our book blogging site. Let’s say we’re looking at a review of Unspoken, a young adult novel by Sarah Rees Brennan. (One of the best books I’ve read this year!) It’s quite common to see lists of categories and tags like this:

Categories: Brennan Sarah Rees, fantasy, Grade: A, urban fantasy, young adult
Tags: detective, gothic

Here we have three kinds of things being categorized: the author’s name (mangled to preserve alphabetical listings), the genres (plus a subgenre that’s common enough to warrant a category rather than a tag), and the review grade. When you look through this site’s category list, you get a bewildering soup of authors, genres, and letter grades. If you’re looking for the letter grades alone, you’d have to comb through all the authors’ names that fall before “grade” alphabetically!

What this site should do is separate these things into custom taxonomies. If we use the main categories to describe the kinds of blog posts this site contains (reviews, administrivia, contests and giveaways), we can separate the rest into three custom taxonomies: Authors, Grades, and Genres. It might look something like this:

Categories: review
Grade: A
Genres: fantasy, urban fantasy
Author: Brennan Sarah Rees
Tags: detective, gothic

We’re still mangling the author’s name (I’ll talk more about this in a moment), but otherwise, this is a much more readable list. Plus, our archive pages will now make a lot more sense. We could perhaps simplify this if the site doesn’t do a lot of posts that aren’t reviews, and use the main categories for the genres. When deciding how to apply taxonomies, it helps to look at not only what kinds of posts you write, but how many of each you have. If this site has only two administrative posts in four years’ worth of weekly reviews, we can probably use  categories for genres. If, however, it’s a busy site with not just reviews but also guest blog posts from authors, weekly contests and giveaways, and an occasional trivia game, then we need to use categories to describe each of these things, and we should move genres to its own taxonomy.

Later in this series, I’ll show you how to create custom taxonomies and display them in your posts.

When extra fields and new ways of grouping posts just isn’t enough to distinguish them, you need whole new content types. A new post type is appropriate when you have two (or more) kinds of content that are utterly different things. The whole of one is different from the whole of the other. On our book review blog, a review isn’t all that different from an administrative blog post. The blog is the purpose of the whole site, and the two kinds of posts can be distinguished using categories. Instead, consider a clothing manufacturer’s website: the product catalog and the company blog are wholly different things. While a blog post and a product page have similar structures — each have title and body fields — they aren’t the same and would never be listed together. On such a website, adding a product post type would make sense. You could then extend the product post type with additional custom fields (price, size, color) and a taxonomy for the type of clothing (shoes, shirts, trousers).

What if you have two different kinds of content, but they need to be linked? You don’t have to try to force one of them to be a taxonomy; you can create connections between post types using a plugin like Posts2Posts. I’ll talk about this in the next post, on functional and organizational requirements.

If you want to skip ahead and start building stuff, grab my new book, WordPress for Web Developers. The final chapter walks you through building custom post types, taxonomies, and fields for a university’s course catalog.