[wp-trac] [WordPress Trac] #30335: Splitting shared terms on term update breaks backward compatibility when using an old term_id

[WordPress Trac]

#30335: Splitting shared terms on term update breaks backward compatibility when
using an old term_id
--------------------------+--------------------
 Reporter:  boonebgorges  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  4.1
Component:  Taxonomy      |     Version:  trunk
 Severity:  major         |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------
Changes (by boonebgorges):

 * keywords:  needs-patch => has-patch


Comment:

 mboynes - This is fantastic. Thanks for your continued work on it.

 For anyone arriving late to the conversation, here's a summary of what
 [attachment:30335.8.patch] does. When splitting a term, we save (in an
 option `'_split_terms_$taxonomy'`) an array of split term IDs
 (`old_term_id => new_term_id`). Then, in the following places, we detect
 the presence of pre-split term_ids and do a silent old/new term_id
 swapout:

 * Calling `get_term()` with an old term_id
 * Calling `get_terms()` when using one or more of the parameters that
 accept term_ids (include, exclude, parent, etc)
 * Using `WP_Tax_Query` with `field=id`
 * Calling `wp_dropdown_categories()` with 'selected' (which expects a
 term_id)

 Furthermore, at the moment of term splitting (the 'split_shared_term'
 action), we swap out old term ids for new in the following places where WP
 stores term_ids in the DB:

 * 'default_category', 'default_link_category', 'default_email_category'
 (wp_options)
 * Nav menu items that go to taxonomy archives (wp_postmeta)

 We feel confident that this will provide backward compatibility for a
 large percentage of cases where old term_ids have been cached, and are
 looking for feedback.

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