[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:  reopened
 Priority:  high                     |   Milestone:  4.3
Component:  Taxonomy                 |     Version:
 Severity:  blocker                  |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+---------------------------

Comment (by boonebgorges):

 Replying to [comment:37 Chouby]:
 > I tested 30261.6.diff and there is still a problem when upgrading from
 an older version (ex: 4.0):
 > {{{
 >       if ( $current_db_version < 30133 && ! defined( 'WP_INSTALLING' ) )
 {
 >               return $term_id;
 >       }
 > }}}
 > Since WP_INSTALLING is no more defined when splitting all terms, the
 test above is passed and thus terms are not splitted (and the
 '_split_terms' option is updated with wrong values).

 Thanks, Chouby - you are correct. We'll take the db_version check out
 altogether if we go this route.

 @dd32 - I think we probably agree that it's too late to pull out the
 `WP_INSTALLING` check in upgrade.php for 4.3.

 > The major thing that springs to mind here with the retrying, is that the
 back-compat option _split_terms will become invalid/only partially filled
 if the process dies part-way (It'll contain the last successful runs
 data).

 Yeah. There are a couple options here:

 1. Save '_split_terms' after each term is split. This makes _split_terms
 much more reliable - in case of crash, it'd be missing, at most, a single
 entry. But it slows down the routine by 3-4x. See
 https://core.trac.wordpress.org/ticket/30261?replyto=37#comment:6
 2. Run the routine in batches of, say, 10 terms. Either (a) fire off a
 loopback HTTP request, and at the end of that request, if more terms are
 detected, fire off another request, so it all happens in the background.
 This will not scale well in the case of network upgrades. Or (b) Keep it
 hooked to 'admin_init', so that all terms will be split only after a
 couple pageloads. (We can reduce or eliminate the cap check, to work
 around your concern about 'update_core'.) The big downside here is that
 there will be a period - usually short, but it'll vary - where some terms
 are split and others are not. IMO this is OK, since we're not doing
 anything in WP (yet) that assumes that all terms are split.
 3. Leave '_split_terms' the way it is. As you note, only a very small
 number of sites will be affected by failed migrations, and only a small
 fraction of those will ever need access to '_split_terms'.

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