In WordPress 4.3, we eliminated shared taxonomy terms once and for all. 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_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
$taxonomy as required arguments. (The decision was made long ago to keep the truly-unique
term_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. In this post, I’ll outline some of these tasks, and point to areas where interested folks can contribute.
API simplification and other work on taxonomy internals
Once each row in the
wp_terms table corresponds to a single row in
wp_term_taxonomy, there’s no point in having two separate tables (and all the JOINs that two tables require). In 2013, @nacin sketched how this might be done, through a combination of
$wpdb tricks and a MySQL view. Here, we need someone to write a patch, and we also need to start a discussion about graceful failures for situations where there are still shared terms in the DB, as well as MySQL version compatibility (view functionality was phased in over the 5.0 series). The tracking ticket for simplification of the taxonomy database schema is #30262.
With a single term table, we can begin to rewrite our internal SQL queries to remove costly table joins. This kind of refactoring is probably at least one version (and a hundred unit tests) away. In the meantime, we can begin the process of simplifying the API interfaces. For example, functions that accept term IDs, like
get_term() no longer need to require an explicit taxonomy parameter.
Having a unique identifiers for terms means this is also a good time to move toward
WP_Term; see #14162. This class can start off being a fairly simple model that takes care of things like basic cache management and data integrity – see
WP_Post – but over time, I envision moving business logic to the
WP_Term, introducing convenience methods for chaining, and so on.
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. Many of them use unprefixed function names like
update_term_meta(), and many of them use a database table called
wp_termmeta. We should do a survey of publicly available plugins to get a sense of usage statistics and schema compatibility. We’ll need to organize outreach to developers of known plugins, so that they can add off-switches to their tools before termmeta appears in core. And we may decide to borrow code from one or more of the existing GPL-licensed tools, ideally with the participation of the original author.
Let’s share this journey
Many hands make light work. We need code, but more importantly, we need folks who are nuts about strategy and outreach and backward compatibility.
There’ll be a meeting for all Taxonomy Heroes, on September 3 2015 20:00 UTC, in the #core channel on Slack. If you’re interested in helping out with any of these taxonomy projects, drop a comment below or come to the meeting. We’ll get a team or two together, and make a plan for 4.4 and beyond.