WordPress.org

Make WordPress Core

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


Ignore:
Timestamp:
11/16/2014 06:47:39 PM (4 years ago)
Author:
mboynes
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #30335, comment 17

    v1 v2  
    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. (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])
     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
     
    10102. 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.
    12 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?
     124. 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? '''(Update: added in [https://core.trac.wordpress.org/attachment/ticket/30335/30335.5.patch 30335.5.patch])'''