Term meta is one of the most requested developer features for WordPress. When architecting a site’s data, most of us have likely had a desire for term meta to add additional text fields, term images, term ordering, or some other data not in the current schema.
WordPress 4.3 included the “third leg” of the taxonomy roadmap, which opened up the possibility for new taxonomy features in 4.4 and beyond, like term meta. Implementing term meta itself is not that technically challenging, but it includes a lot of work still, like communicating with developers that have implemented custom solutions.
Boone Gorges created a proposal for what term meta would look like, and what some of the to-do items are:
We plan to do an in-depth scan of all public plugins that conflict with the core implementation (function names, database table schema, etc) and to mount an outreach and documentation project to help affected plugin developers move to the core system. Our goal is zero fatal errors or lost data on WP installations.
That scan has already started and many of the public (on the WordPress repository) plugins that create term meta or custom term meta tables have been identified. The tracking is happening on a Google Doc and if you’re interested in contributing notify @boone in Post Status or WordPress Slack.
What’s the difference between a post and a term if both have meta?
This is one of the questions asked in the meeting about term meta. Some folks may be concerned that it would make terms too abstract and difficult to define what the difference between posts and terms are if terms have meta. So I wrote the following to help make that more clear, as there are still significant differences:
A term is a more limited data set than a post. An important distinction is that a term has nothing date related stored upon its creation/update. Also, there is no inherent connection to comments. Nor can terms have a status, like draft or pending. Less distinctive but still relevant differences are that terms don’t have any ping data, or an excerpt field (description is a LONGTEXT field in terms, like post content, and post excerpts are TEXT).
Moreover, I think it’s safe to say that generally a post is thought to be able to live on its own. Whereas it’s a reasonable expectation that a term should have some form of relation and attachment to a post object — in that the term belongs to a taxonomy that is registered on a post type. And practically, site owners would expect a term view in WordPress to also return connected posts by default; and in fact terms 404 if posts aren’t connected. Finally, a term exists in the admin as a sub-item to a post object and is not a top-level item.
So, if you are deciding whether to use a term or a post, consider the following:
- Can this data stand well on its own, or does it best fit when related to another data type?
- Is this data in any way date based, or have need for knowledge of the date it was created or modified?
- Would this data ever need to support comments?
- Does this data need to exist at the top level in the admin?
If the answers to any of these questions is yes, then it may be better served as a post/post type. If not, it may be well suited as a term.
The case for term meta
In my opinion, highlighting the difference between terms with term meta and posts is also what makes the most compelling case for it. They are indeed quite different still, and adding meta data for terms will open up what is possible for relating more complex content in WordPress.
However, term meta can also pose problems for scale if it’s abused. Just like post meta data can be a real burden for site performance, term meta will have similar potential.
Enabling developers it’s still a developer’s responsibility to make the right architecture choices. As Boone noted in the last meeting, “The job of core is to provide the tools so that developers can make their own decisions about architecture. But we want to encourage best practices.”
Term meta will be a popular feature
The introduction of term meta will answer a big developer demand if it goes into WordPress 4.4. Its implementation will hopefully prevent any breakage of current term meta, but it’s important for any of you that have implemented term meta previously (that’s probably almost all of you!) to keep a close eye on how this is all developing. And respond appropriately as feedback is requested, as outreach and communication is the key to this feature being successfully implemented.
