| 1 | | Closed #21639 as a duplicate |
| | 1 | Now that #22023 is resolved, we can finally start moving forward with this ticket. [attachment:5809.patch] is my proposed patch for 4.1. |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | 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. |
| | 6 | |
| | 7 | 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: |
| | 8 | |
| | 9 | * 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. |
| | 10 | * 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'. |
| | 11 | |
| | 12 | It's my view that we should not attempt forcibly splitting existing terms on WP version 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. |