[wp-trac] [WordPress Trac] #5809: Updating a term in one taxonomy affects the term in every taxonomy

[WordPress Trac]

#5809: Updating a term in one taxonomy affects the term in every taxonomy
--------------------------+-----------------------------
 Reporter:  rmccue        |       Owner:  garyc40
     Type:  defect (bug)  |      Status:  reopened
 Priority:  high          |   Milestone:  Future Release
Component:  Taxonomy      |     Version:  2.3
 Severity:  major         |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:  has-patch early needs-unit-tests => has-patch


Comment:

 Now that #22023 is resolved, we can finally start moving forward with this
 ticket. [attachment:5809.patch] is my proposed patch for 4.1.

 A quick recap of the background will be helpful in explaining the patch.
 #22023 was a blocker for this ticket because splitting existing shared
 terms into separate terms requires duplicate slugs to appear in the
 `wp_terms` table. A tag and a category that share the term 'boone' (cool
 site, btw) will currently have default archive permalinks
 `example.com/category/boone` and `example.com/tag/boone`. If we want to
 split the tag and category into separate terms, they both have to have the
 slug 'boone'. That's why we need to remove the UNIQUE index before
 splitting existing shared terms.

 This is somewhat more complex than it seems, because updates to the
 database schema don't propagate immediately. On Multisite, the Network
 Upgrade script needs to be triggered manually, and on large networks like
 wordpress.com, the upgrade can take weeks. So we have to be delicate about
 how we go about splitting shared terms: either we wait until we can be
 reasonably certain that all sites will have performed the necessary schema
 change (say, 4.2), or we do some checks of the actual db_version before
 splitting, and act accordingly in either case.

 In [attachment:5809.patch], I've opted for the latter path. Once the
 schema change is applied to a given site, there's no reason IMO to wait on
 cleaning up this mess. As such, my patch does the following:

 * On `wp_update_term()`, if the schema change *has* been run, detect
 whether the tt_id shares its term_id with another tt_id. If so, split it
 off into its own term. If the schema change has *not* been run, do nothing
 - allow the shared term to stay shared. This solves the current ticket, at
 least for sites where the database schema change has taken place.
 * On `wp_insert_term()`, stop creating shared terms. This fixes #21950. If
 the schema change *has* been run, we allow a duplicate slug to be created.
 In other words: If you have a tag 'boone', you'll be allowed to create a
 new category called 'boone', which will create a new item in 'wp_terms'.
 If the schema has *not* been updated, we cannot allow a duplicate slug to
 be created; instead, we force a new slug in `wp_unique_term_slug()`. In
 other words: If you have a tag 'boone', a category called 'Boone' will get
 slug 'boone-2'.

 It's my view that we should not attempt forcibly splitting existing terms
 on upgrade until we can be reasonably sure that the 4.1 schema change has
 taken place. So, 4.2 seems like a reasonable goal for that. Then we can
 start talking about further steps in the taxonomy roadmap.

 * When

--
Ticket URL: <https://core.trac.wordpress.org/ticket/5809#comment:54>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform