[wp-trac] [WordPress Trac] #30261: Split all existing shared taxonomy terms on WP upgrade

[WordPress Trac]

#30261: Split all existing shared taxonomy terms on WP upgrade
-------------------------------------+---------------------------
 Reporter:  boonebgorges             |       Owner:  boonebgorges
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  4.3
Component:  Taxonomy                 |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+---------------------------
Changes (by boonebgorges):

 * keywords:  needs-patch => has-patch needs-testing


Comment:

 [attachment:30261.diff] is a first attempt at an upgrade routine. The
 logic is pretty straightforward, but here are a few implementation notes
 for anyone looking at it:

 1. I've put it into a separate function
 `_upgrade_430_split_all_shared_terms()` for easier testing.
 2. I wrote a wp-cli command to facilitate testing
 https://gist.github.com/boonebgorges/2beb1379569c3bd85803
 3. My main concern was performance:
     - The `HAVING...GROUP BY` query allows us to pull up only those terms
 that are shared.
     - I've changed `_split_shared_term()` so that it will accept
 term/term_taxonomy objects rather than just IDs. This saves some database
 queries.
     - In my profiling, the process of recording the '_split_terms' option
 accounted for 70-80% of the total execution time. So I've added a
 `$record` toggle, and put the recording logic into the upgrade routine.
 The only potential problem is that plugins may expect '_split_terms' to be
 up-to-date when hooking to 'split_shared_term', which won't be the case
 during the upgrade routine. Not a dealbreaker, but something that should
 be documented.

 With these modifications, I think it's running reasonably fast. On a local
 installation with ~15000 terms, of which about 1000 are shared between two
 or more taxonomies, the upgrade runs in 6-8 seconds. I assume that the
 vast majority of WP installations will have far fewer shared terms than
 this, and those that have much more probably already have failsafes in
 place to ensure that upgrade routines don't time out. It would be great to
 have feedback on this point from people who manage the infrastructure for
 very large WP installations.

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