In this series, we're taking a look at what WordPress taxonomies are, their definition, when to use them, and how to incorporate them into our themes. To make sure we're covering this in as much detail as possible, we're approaching this from the perspective of a beginner.

As mentioned in the first post in the series, this series isn't aimed only at beginners. Perhaps you're an intermediate WordPress developer who is looking to begin branching out into new APIs and implementing new features into your work and taxonomies fit the bill for exactly that.

Whatever the case, we're doing what we can to make sure that you're armed with as much information as possible when it comes to incorporating custom taxonomies into your WordPress projects.

Why vs. When

Before we look at an actual implementation of how to incorporate taxonomies, we need to talk about some of the challenges that come with incorporating taxonomies into our work.

Specifically, should taxonomies be included as part of a theme or in a plugin? This question is really more of a question of "why should we include taxonomies this way?" and "when should we include taxonomies this way?"

And to answer that, it's important to distinguish between the two options that we have and how data is stored.

How The Data Is Stored

First, let's discuss how taxonomies are stored internally within WordPress. Taxonomies consist of two components: A taxonomy and a term.

1. A taxonomy represents how information is grouped together.
2. A term represents the type of data that belongs to that taxonomy.

For example, when thinking of Post Formats, the taxonomy is Post Format and the terms are Standard, Video, Image, Link, and so on. Similarly, another taxonomy may be Photography and the terms may be Film and Digital.

In the most basic case, the default WordPress taxonomy and term pairing is Category and Uncategorized that's provided with every installation.

Now, from here, it's important to understand how this data is managed in the WordPress database. There are three database tables each of which play a role in the relationship between taxonomies and their associated terms.

Assuming that you're working with the default installation (that is, the table prefix is wp_), then you'll have the following tables each with the corresponding responsibilities:

1. wp_terms represents the terms that belong to various taxonomies. This means that if you have a Photography taxonomy with two terms being Film and Digital and you have a taxonomy called Type with Color and Black and White being terms, then Film, Digital, and Color will all reside within the wp_terms table.
   
2. wp_term_taxonomy is a database table that's responsible for storing the description of the terms stored in the wp_terms table. Say, for example, you have a Color term and the term is described as "Photographs that are developed in vibrant colors." Then this description would reside in the wp_term_taxonomy table.
3. The wp_term_relationships is arguably the one that has the largest learning curve for new developers. This table maintains the connection between what taxonomies are related to which post types. For example, given a default installation, this table will store the relationship between the category term and each post to which it is associated.

Now that we have an understanding as to how data is stored, we can discuss when taxonomies make sense within the context of themes and within the context of plugins.

Themes or Plugins?

Generally speaking, a good rule of thumb is to note that WordPress themes should be for presentation of data and plugins should be for functionality. That is, themes provide the format for how the data looks, and plugins extend core functionality of WordPress.

There is also the notion of extensions which are like theme-specific plugins and plugin-specific plugins, but that's beyond the scope of this article. For now, let's keep the discussion at the level of themes and plugins.

Let's say that you are working on a theme and you want to introduce a custom taxonomy into the theme. In keeping consistent with our examples used throughout the series, let's say that you want to create a portfolio theme and you want to introduce a Photography taxonomy. After all, the theme is going to allow users to showcase their work.

Then, let's say that you want to work on the same theme in a year or so but you want to perform a major upgrade. Perhaps you want to generalize the taxonomies so that people don't have to use it just for photography. Instead, they can use it for short poems or writings, drawings, and so on. 

The problem is that you now have the Photography taxonomy hardcoded into the theme such that everyone who uses it and installs it gets that particular taxonomy regardless of if they want to showcase photography or not.

Sure, it's completely possible to rebuild the theme from the ground up and abstract the taxonomy function into something more general, but what happens for the users who want to upgrade? Do they lose the data that they've spent months or years working with? How is their data going to be organized? Are they stuck with the current version of the theme with which they're working?

Obviously, there's a lot to consider whenever you're working on a theme like this. But that's where the importance of segmenting presentation and functionality comes into play.

It's completely possible to build a theme designed to showcase work in a portfolio style without actually having to hardcode any type of taxonomy into the theme. Instead, build the functionality into a plugin and then install the plugin alongside the theme with which you're building. You then get the advantages of the portfolio presentation without having users locked into using your theme for however long and potentially losing their data when upgrading to a new theme.

A Word About Compatibility

For many of the reasons listed above, it's easy to see why implementing custom taxonomies within the context of plugins makes sense.

This is not to say that it should never be done in themes. After all, there are niche themes that target a very specific audience and that seek to provide an all-in-one solution for their customers. That's fine, but if you're looking to introduce this type of functionality with the widest possible appeal, then building the functionality into a plugin makes a lot of sense.

Not only do you get the benefit of giving users the ability to port their data from theme to theme without losing the categorization of their data, but you also give them the benefit of being able to maintain independence between the presentation of their data and the storage of their data.

And if you're a theme developer, you can still work to create themes that are designed specifically around the plugin. Perhaps you'd want to offer a theme for photographers, one for writers, and one for artists. With this strategy, you're able to still aim to capture a certain type of the market all the while making your plugin compatible with the variations of your work freeing you up to work on different themes and giving your customers the ability to move between themes all while still using your products.

Up Next

Since we've reviewed how WordPress manages taxonomies within the database, and we've looked at some reasons as to why themes and plugins should work in conjunction with one another to offer specific features, we're going to be looking at how we can create our own plugin that implements custom taxonomy functionality that we've been using as example data throughout this series.

In the meantime, feel free to leave any comments, questions, or general feedback in the comment field below.