WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #30335, comment 17


Ignore:
Timestamp:
11/16/2014 06:26:39 AM (10 years ago)
Author:
mboynes
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #30335, comment 17

    initial v1  
    11I 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:
    22
    3 * 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.
    4 * 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.
     3* 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. (Update: added in [https://core.trac.wordpress.org/attachment/ticket/30335/30335.4.patch 30335.4.patch])
     4* 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. (Update: added in [https://core.trac.wordpress.org/attachment/ticket/30335/30335.4.patch 30335.4.patch])
    55* Should `_get_split_term()` be `@private`? Not that it's ''actually'' private, but why aren't plugins and themes welcome to use it?
    66
    … …  
    88
    991. 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?
    10 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.
     102. 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 we 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.
    11113. `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.
    12124. 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?