Eliminating shared taxonomy terms in WordPress 4.3
Work on the taxonomy roadmap, started in earnest during the 4.1 dev cycle, continues to chug along for WordPress 4.3. We’ve been focusing on the elimination of shared terms: terms in different taxonomies that share the same term_id
and thus the same row in the wp_terms
database table. In 4.1, we stopped creating shared terms. In 4.2, we began splitting existing taxonomy terms when those terms were updated.
In 4.3, we’ll take the final step. When a WordPress site upgrades to 4.3, all existing shared terms will be split.
Toward that end, I’d like to make (a) a final warning to plugin authors, and (b) a plea for help from taxonomy mavens and those who maintain very large and complex WordPress installations.
Plugin authors: Dress rehearsal is nearly over
Since 4.2, saving a shared term (via any interface that uses wp_update_term()
) causes that term to be split. It’s fairly rare to update a taxonomy term, which has made 4.2 a sort of trial run for authors to ensure that their plugins are ready for the transition. A quick scan of the plugin repo shows that a few dozen authors have taken advantage of this opportunity. I dub these developers Heroes of WordPress and grant them 🌟🌟 many gold stars 🌟🌟. Many authors, however, have neglected to make the necessary updates.
All WP developers should take note that the upgrade to 4.3 is likely to surface many more odd bugs related to shared terms than 4.2 did. Plugin authors are strongly encouraged to review the 4.2 term splitting field guide to understand the potential repercussions for their public plugins as well as their custom client work, and to review techniques for ensuring a smooth transition.
Get involved
The 4.3 ticket for splitting taxonomy terms on WP upgrade, #30261, is sorely in need of developer feedback. The process of splitting shared terms en masse is potentially resource-intensive, especially on sites with very large numbers of terms (and especially with very large numbers of shared terms). The latest patch on the ticket has some optimizations so that sites with many hundreds of shared terms can be migrated in just a few seconds. If you maintain a site with a large number of (shared) taxonomy terms, or if you maintain a WordPress network with a very large number of sites (especially if you have a custom routine for rolling out database updates), your review and testing of the upgrade routine would be much appreciated.
Booyah
The fun stuff on the taxonomy roadmap – like termmeta – depends on the complete elimination of shared terms. Let’s get the hard stuff done in 4.3, so that we can make all of your taxonomy dreams come true in the next couple releases.
brianvan 8:31 pm on June 9, 2015 Permalink | Log in to Reply
Great work here. Sounds like the team has been thorough in addressing any major issues that come out of this. Looking forward to the future stuff on the taxonomy roadmap!
J.D. Grimes 7:12 pm on July 3, 2015 Permalink | Log in to Reply
@boonebgorges, is there a plan for, e.g., #20536?
Boone Gorges 6:07 pm on July 4, 2015 Permalink | Log in to Reply
I don’t think a plan has been spelled out in detail. But yes: in the medium term, say two or three major releases from now, I’d like to start simplifying the taxonomy internals by doing things like #20536. At the beginning of 4.4, maybe we can start brainstorming about what can be done.
Mayeenul Islam 10:03 am on August 19, 2015 Permalink | Log in to Reply
Just to understand the insight, pardon me, does that mean that, every `term_id` will be unique, regardless of taxonomy?
ancawonka 6:00 pm on August 19, 2015 Permalink | Log in to Reply
That seems to be the case. This has a lot of implications for sites using themes or plugins that ask for a term_id (for widgets, shortcodes, theme options, etc). Make sure you check pages where this is relevant.
mwendell 5:57 am on September 2, 2015 Permalink | Log in to Reply
If every term is unique within each taxonomy, why are we still using a terms table AND a terms_taxonomy table? I thought the point of the latter was to enable a single term to exist across multiple taxonomies.
Boone Gorges 1:30 pm on September 2, 2015 Permalink | Log in to Reply
> I thought the point of the latter was to enable a single term to exist across multiple taxonomies.
You’re correct. But we can’t just remove one of the tables. (a) The tables have different columns, so they have to be combined somehow. (b) People making reference to the tables in their own SQL – either via `$wpdb->term_taxonomy` or using the table name directly – will have their queries broken if a table is just ripped out. (c) Tables can’t be combined until terms have been made unique across all installations, or data will be lost; we need to allow some time for this to happen after the release of 4.3, since database upgrade routines are not always run immediately.
If you want to follow along with the next steps in the process, check out https://make.wordpress.org/core/2015/08/27/taxonomy-roadmap-for-4-4-and-beyond/ and especially https://core.trac.wordpress.org/ticket/30262