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

Comment (by mboynes):

 > On balance, the case for autoload=no seems less persuasive to me

 Hard to argue with your breakdown! I'm in full agreement; re-enabled in
 [https://core.trac.wordpress.org/attachment/ticket/30335/30335.7.patch
 30335.7.patch].

 > there are legitimate instances where plugins would want to do what we're
 doing here to provide the same kind of backward compatibility

 Agreed; Updated this to `wp_get_split_term()` and removed the `@private`
 tag in
 [https://core.trac.wordpress.org/attachment/ticket/30335/30335.7.patch
 30335.7.patch].

 > I would say no [about firing `delete_term` for the old term id when a
 split term is deleted].

 I'm leaning in the same direction, so let's not do anything for now, and
 see if anyone comes along with a different opinion.

 > I'd even shy away from deleting the entry from the
 _split_terms_$taxonomy option, because then there'll be no record of what
 happened

 Great point, I left that alone too.

 Going back to menus, I looked into updating these but I'm a little
 hesitant. In order to identify which menu items need to be updated, we'll
 have to do a fairly ugly meta query. Using raw SQL to improve efficiency,
 we're still stuck with something like:

 {{{
 SELECT m1.post_id
 FROM wp_postmeta AS m1
         INNER JOIN wp_postmeta AS m2 ON m2.post_id=m1.post_id
         INNER JOIN wp_postmeta AS m3 ON m3.post_id=m1.post_id
 WHERE ( m1.meta_key = '_menu_item_type' AND m1.meta_value = 'taxonomy' )
         AND ( m2.meta_key = '_menu_item_object' AND m2.meta_value =
 'category' )
         AND ( m3.meta_key = '_menu_item_object_id' AND m3.meta_value = 123
 )
 }}}

 Once we've identified the post ID, we can use `update_post_meta()` to
 update each found value. I'll play around with this in a massive dataset
 and submit a patch if it seems like we won't have performance issues.

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