[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         |   Keywords:
  Focuses:                |
--------------------------+-------------------
 See #5809.

 When a shared term is split into two separate terms, one of the terms will
 have a new term_id. This will cause problems for anyone who has previously
 stored a term_id, and is using it to look up that term post-split.

 An example. Say you have a term with `term_id=5` and `slug=foo`. In
 `wp_term_taxonomy`, you have two rows that look like this:

 {{{
 term_id   term_taxonomy_id    taxonomy
 ---------------------------------------
   5               8            post_tag
   5               9            category
 }}}

 Now, say you run the category 'foo' through `wp_update_term()`. It will be
 recognized as a shared term, and will be split into a new row in
 `wp_terms` (say, `term_id=10`).

 If you are running a plugin or other customization that has previously
 stored the term_id 5 to refer to the *category* 'foo', future lookups will
 not work. Examples:

 1. `get_term( 5, 'category' )` will return null.
 2. Building a `Walker_CategoryDropdown` and passing `selected=5` will
 break the pre-selection.
 3. People who are making direct SELECT (or, god forbid, UPDATE) queries
 using the `term_id` will find their queries failing.
 4. And maybe other stuff.

 Note that, as far as I can find, none of these things are happening in
 core.

 I'll follow up with some next steps.

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