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

Comment (by mboynes):

 I think this is a great start and should catch the vast majority of
 situations where this might be a problem, thanks @boonebgorges! Here are
 my thoughts after playing around with this:

 * I would propose tweaking this to store the old term ids in multiple
 options, one per taxonomy. Within each option, store an array of
 `old_tem_id => new_term_id`. This makes the lookups even faster and
 prevents having to loop over each tt_id (let's say you had a very generic
 term which exists in 10 taxonomies, you might then have to lookup 9 terms
 before you get the right one). I'm going to add a patch which does this.
 * This is currently going to autoload the option. Do we want it to? I
 would say no, and I'm going to include a patch which modifies that
 behavior.
 * Should `_get_split_term()` be `@private`? Not that it's ''actually''
 private, but why aren't plugins and themes welcome to use it?

 I gave some more thought on other things we have to consider:

 1. Nav menus. Term IDs for menu items linking to terms get stored in post
 meta. This update will fix the display of terms (since it uses
 `get_terms()` on display), but when a term is deleted, it won't remove
 menu items referencing the old term ID (more on this below). Should we try
 to update menu items when terms get split?
 2. The above deletion happens through the `'delete_term'` hook, so I dug a
 little deeper and it looks like `'_wp_delete_tax_menu_item'` is the only
 core function hooked into that action. When a term is deleted, should
 check if there's an old term ID linked to it and fire `'delete_term'` for
 that term ID too? This would involve faking the 4th param
 (`$deleted_term`), since the old term ID won't have a term object. Then,
 of course, we should remove the `old_tem_id => new_term_id` reference in
 the options table.
 3. `default_category`, `default_post_format`, `default_link_category`: I
 think these should just get updated when a term splits if the old term id
 is a default.
 4. This was mentioned in the ticket, but should we add a check to
 `wp_dropdown_categories()` to see if the 'selected' arg is an old term?

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