[wp-trac] [WordPress Trac] #34544: Attaching metadata to shared terms can result in data corruption

[WordPress Trac]

#34544: Attaching metadata to shared terms can result in data corruption
--------------------------+------------------
 Reporter:  boonebgorges  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  4.4
Component:  Taxonomy      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch


Comment:

 [attachment:34544.diff] is an initial patch addressing the issue.

 * I've gone with a `WP_Error`. It's annoying to add another return value
 type, but (a) these are new functions, so there are no compatibility
 concerns, and (b) returning `false` on error is pretty lousy behavior. In
 principle, I like @jorbin's idea of throwing catchable exceptions, but it
 should be part of a larger conversation about WP error reporting.
 * I'm reusing the 'finished_splitting_shared_terms' option introduced as a
 helper for the cron job in the 4.3 upgrade. New installations will always
 have it set to 1. Updates where all terms are split will have it set to 1.
 Updates where terms are not yet split, either because cron is broken or
 because cron has not had enough time to batch-split all terms, will have
 it set to 0. As a failsafe for cases where wp-cron isn't running for some
 reason, I added an extra check to the end of `_split_shared_term()`; after
 splitting a term, if we see that we've just split the final shared term,
 we set the flag to true. (Previously, we were only setting it to true
 during a cron callback.)

 I'd appreciate feedback from one of this ticket's illustrious followers on
 the approach.

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