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

WordPress Trac noreply at wordpress.org
Thu Aug 13 19:16:42 UTC 2015


#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):

 I talked privately with Chouby about what he's experiencing. It's a race
 that occurs when the database upgrade is run at the same time that a wp-
 cron is in progress. Something like this:

 1. wp-cron.php is hit, and wp_version_check is fired. (wp_version_check
 was the culprit in Chouby's case, but it could happen with any event, and
 it'll be liklier with events that require external requests and so take a
 second or two to complete)
 2. While the cron job is running, the db upgrade is fired in a separate
 process.
 3. The db upgrade schedules 'wp_split_shared_term_batch' and saves the
 cron array.
 4. The cron job finishes, and performs cleanup on the `$crons` array
 (rescheduling events, etc). This overwrites the cron array from step 3
 with the previous value of `$crons` (with events re- and unscheduled as
 appropriate).

 In Chouby's case, this was happening regularly because he was testing with
 a database import. The database was old enough that the wp_version_check
 event was due to run on the first pageload after import. Chouby's first or
 second pageload was, in fact, the database upgrade, causing the race. This
 situation is much less likely to occur in the wild, but it's still
 possible.

 It's possible that this is a margin of error that we're OK with. If not,
 one strategy for mitigating it would be to have a persistent function,
 maybe hooked to 'admin_init', which would include a check like:

 {{{
 if ( `get_option( 'shared_terms_have_been_split_once_and_for_all' ) && !
 wp_next_scheduled( 'wp_batch_split_terms' ) ) {
     wp_schedule_single_event( 'wp_batch_split_terms', time() +
 MINUTE_IN_SECONDS );
 }
 }}}

 This, in turn, would be subject to various race conditions, but
 `wp_batch_split_terms()` contains a lock that should prevent problems, and
 in any case, the function bails when there's nothing to do.

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


More information about the wp-trac mailing list