In a recent series, we talked all about how we could work with metadata for several of the major classes in WordPress.
This included:
Throughout the series, we talked a bit about how WordPress 4.4 introduced the idea of term metadata. I didn’t want to present the concept within the context of that series because it was dependent on understanding something that often gives beginners a little bit of trouble.
That’s what this series aims to address.
About WordPress, Taxonomies, and Terms
In WordPress, the concepts of taxonomies and terms go together. I’ll elaborate more on this in just a moment. But to properly work with term metadata, I believe it’s important to understand taxonomies, terms, and their relationships. Otherwise, how else can we have an end-to-end understanding of what we’re doing when working with them at a programmatic level?
In this two-article follow-up series, we’re going to be taking a look at taxonomies, what they are, the role they play in WordPress, and their relationship to terms. Then we’re going to turn our attention to terms and how to work with the new term metadata API.
If you’ve not yet read the previous series, I recommend doing so as it will lay some groundwork for how the API we’re going to explore works. If, however, you opt not to do so, that’s okay. This series should cover everything you need to know.
What Are Taxonomies?
As defined in the Codex:
In WordPress, a “taxonomy” is a grouping mechanism for some posts (or links or custom post types).
Admittedly, it’s not a word that you often hear and, sometimes, others will get confused when talking about taxonomies and terms. That is, they’ll use an example phrase as an example of a taxonomy but what they are doing, in that case, is using a term. I’ll touch on that in just a little bit.
Simply put, think of taxonomies as ways to group things together. Out of the box, WordPress ships with two taxonomies: categories and tags. We’ll talk about each of these in more detail momentarily.
Now, there’s a caveat, at least when it comes to WordPress: taxonomies can be hierarchical or non-hierarchical. Perhaps the most common example of the above idea is as follows:
- When you create a category in WordPress, you have the ability to create it as a top-level category or as a sub-category of a pre-existing category. For example, an eagle may be a subcategory of birds.
- When you create a tag in WordPress, you create a single word or phrase with which you want to stamp (or, more literally, tag) your post. There’s no notion of child tags or parent tags.
And that’s the difference between hierarchical and non-hierarchical taxonomies. It’s easy, isn’t it? Those that support children, like categories, are hierarchical; those that don’t support children, like tags, are non-hierarchical.
With the work that we’re going to do in this series, this doesn’t particularly play a role other than helping us to gain a deeper understanding of what this language means in the context of our development efforts.
But when we begin programmatically creating these entities and adding metadata to them, there shouldn’t be any confusion as to what we’re doing.
What Are Terms?
We’ve defined taxonomy, but what about terms? From the Codex:
In WordPress, a term is a classification, group or subset of a Taxonomy, where the latter can be a Category, Tag or Custom Taxonomy. By default, terms have a title, a slug and a description. Hierarchical taxonomies like categories can define a parent term.
Given what we’ve discussed thus far, this is exactly what we should expect. That is, terms are associated with taxonomies. Terms, however, have several notable aspects to them that we should be aware of, especially if we’re going to be creating them or working with them programmatically.
That is, terms are composed of:
- a slug
- a title
- a description
Remember that if we’re working with a hierarchical taxonomy, like a category, then the term may optionally include a parent term.
To be clear, this doesn’t mean that a taxonomy doesn’t have a set of information related to it. For example, a taxonomy requires a name, a post type to which it’s associated, and a number of arguments that are outside the scope of this article. We’ll see more about this in the next article, though.
How Are They Related?
The relationship between taxonomies and terms is somewhat symbiotic, meaning that one can’t exist without the other. This is especially true as it relates to hierarchical taxonomies.
First, for those who are interested, the WordPress Codex provides a diagram explaining the relationship:
For example, you may have a Category taxonomy, but you have to have at least one term associated with it. This is why WordPress ships with a default Uncategorized term.
On the other hand, it’s possible to create a Tag taxonomy, but not have any tags that exist within the database.
But, as developers, can we take this a step further? That is, although all of these can be created programmatically, users have the ability to create and add them, as well. At least, if the user interface exposes an option for them to do that.
Case in point: When you look at the WordPress user interface, we all have the ability to create categories and tags.
If, however, you’re a programmer, and you want to hardwire certain taxonomies and terms into the database, then you have the ability to do that and to prevent users from adding and removing them from the user interface.
What About Term Metadata?
We’ve laid out the definitions of taxonomies and terms as well as the differences between them, but one question remains: Why do we need term metadata? Or, perhaps alternatively, what’s the point of term metadata?
That’s a good question, and it’s probably part and parcel of why this feature wasn’t introduced until WordPress 4.4. Interestingly enough, the ticket for this feature was first introduced over six years ago. The primary rationale for the ticket (straight from Trac itself) states:
At this moment there is no dedicated way to store additional data for taxonomy. Plugin developers have to develop their own method for storing this data, e.g. by storing them encoded in description field or using set_option(). It will be good to add new functions for this, e.g. add_taxonomy_data()/get_taxonomy_data().
If you’re an experienced WordPress developer, then this makes perfect sense. But not all of us are up to that level yet, so we aren’t sure of what advantages this buys us.
Like all of the other APIs, it allows us to store information about any given term that exists within the database. This could be anything related to the time at which the term was created, who created the term, or how many posts are tagged with a given term, or it allows us to associate an image with a term.
Because it supports a level of arbitrary information, the possibilities are extremely wide as to what we can do with this information. And starting in the next article, we’re going to see exactly that.
Conclusion
At this point, you should have everything you need to know to work with taxonomies and terms. Sure, you’ll likely have to read through the Codex a few times as you’re working on a plugin, theme, or custom solution for a client, but that’s not abnormal even for an experienced developer.
In the next article, we’ll take a look at how to work with term metadata. Specifically, we’ll look at example code, wire it up to one of the default themes in WordPress, and monitor the database as we make changes.
In the meantime, if you’re interested in WordPress, software development, or the intersection of the two, then remember to take a look at my profile page that includes links to all of the courses and tutorials I’ve published on Envato Tuts+.
Secondly, don’t hesitate to follow me on Twitter at @tommcfarlin, where I often talk about and share resources related to WordPress, or follow my blog where I write daily about the work I’m doing with WordPress or topics that are tangentially related to it.
Finally, if you’re looking for other utilities to help you build out your growing set of tools for WordPress or for code to study and become more well-versed in WordPress, don’t forget to see what we have available in Envato Market.
Until then, please don’t hesitate to leave questions or comments below, and I’ll do what I can to respond to each one of them.