The term gates are open

WordPress 4.3 completed the three-release process of eliminated shared terms, and it marked an important step to allow future term feature development and API simplification. Today, Boone Gorges expertly and simply (two things that are hard to combine) explained how that is so and what is now possible.

This means that, by the time WordPress 4.4 is released, just about every WordPress installation will have the same number of rows in the wp_terms and wp_term_taxonomy database tables.

Why does this matter? When terms in different taxonomies could share the same term_id, terms could only be uniquely identified by a ID-taxonomy pair. This is why every nearly function in our taxonomy API has $term_id and $taxonomy as required arguments. (The decision was made long ago to keep the truly-uniqueterm_taxonomy_id internal for most purposes.) The lack of unique IDs for terms made our API interfaces and internals complicated, and it made it cumbersome to add new features like term metadata.

Now that term IDs are unique, we can begin the projects of unraveling the now-unneeded complications of the taxonomy API and adding new features that take advantage of the simplified data model.

A few big potential changes Boone outlines are as follows:

• The ability to remove an entire table from the WordPress database (which is very uncommon to be able to do with backward compatibility).
• Simplify many SQL queries by reducing the number of joins required (due to the removed table).
• Simplify functions that previously required an ID and a taxonomy name to just an ID (because post-term-split the ID itself is unique).
• An opportunity to introduce a WP_Term object.
• Implement term meta.

Regarding term meta, Boone described why it’s now a good time, and what challenges the task would face:

There’s been lots of clamoring for taxonomy term metadata #10142. Unique term IDs make it viable, since WP’s*_metadata() functions assume object IDs as identifiers.

The technical implementation is not complex. We need wrappers for the CRUD functions, ‘meta_query’ support in get_terms(), an update routine to create the database table, metadata pre-caching (‘update_term_meta_cache’) when fetching terms, and maybe a few other small items.

The larger challenge is to build a core solution that minimizes conflict with third-party tools. Developers have wanted termmeta for a long time, so there are many public plugins and private libraries that provide it.

This means that now is a great time to get involved if you are a good communicator but don’t feel ready to contribute code to WordPress. Because term meta needs evangelists working with the many term-influencing plugin authors.

There are 11 pages of plugins on .org with the tag ‘Taxonomy‘ and 3 pages worth tagged ‘Terms‘. If you’re willing and able to help, there is a meeting next Thursday in core Slack, and this is a great way to get your feet wet in core WordPress. Check out Boone’s post for more good links and how to get involved.