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

WordPress Trac noreply at wordpress.org
Fri Aug 14 13:53:38 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):

 Replying to [comment:74 ocean90]:
 > [attachment:30261.18.diff]: Should we populate
 `finished_splitting_shared_terms` for new installs to avoid one schedule?
 >
 > Edit: Just noticed that the patch is wrong. Needs to be 0 first and
 changed in upgrade_430().

 Yes. As you note, it doesn't help us to avoid a schedule, but it does help
 to avoid database queries in the absence of a 'notoptions' cache. This was
 in an earlier version of the patch, but got lost in translation.

 Replying to [comment:73 Chouby]:
 >  In 30261.17.diff​, I propose to remove the call to
 wp_suspend_cache_invalidation() as I noticed
 > during my tests that it introduces a conflict with Polylang. That's
 would not a big deal for
 > Polylang users as it just leaves unused DB entries (so nothing visible
 to the user), but I have
 > no idea of what kind of other conflict it could introduce in other
 plugins using the
 > split_shared_term hook.
 >
 > I guess that this call was introduced for performances reasons. Now that
 the split is done by
 > batches of 20 terms, it may be less important to save time than avoiding
 potential conflicts.

 Yes, it was introduced for performance reasons, and yes, it's less
 relevant now that it's done in batches. (Rebuilding taxonomy hierarchies
 can be very resource-intensive in certain cases.) Before removing the
 invalidation suspension, can you give a few more details about how
 Polylang is being affected? I want to make sure we're not papering over a
 larger bug.

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


More information about the wp-trac mailing list