[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:                |     Focuses:
--------------------------+--------------------

Comment (by boonebgorges):

 Regarding potential solutions. Thinking about the possible reasons why
 someone would store a `term_id` like this, the most obvious is that they
 want a simple way to pull up the term at a later date, likely using
 `get_term()` (see #1 above). In this case, we can take advantage of the
 fact that (a) all of our core functions that pull term from the DB either
 run through `term_taxonomy_id`, in which case this issue will be
 irrelevant since splitting doesn't change this value, or they go through
 `get_term()`, and (b) when passing a `term_id` to `get_term()`, you must
 also provide a taxonomy name. So here's the idea:

 * When splitting terms, save information about the split somewhere (say,
 in an option '_split_terms', which is an array of
 [old_term_id,new_term_id,taxonomy] triplets)
 * In `get_term()` (and `WP_Tax_Query::transform_query()`, and maybe when
 using the 'include'/'exclude' params of `get_terms()`), do some logic to
 detect queries for the old term id (maybe only as a fallback if the proper
 query fails), and do a lookup against the cached split terms data.

 I think this would cover a large percentage of the potential fallout from
 split terms. I'll follow up with a patch.

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