Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#23069 closed defect (bug) (wontfix)

For plugins that create custom taxonomies, wp_delete_term does not work during plugin uninstall.

Reported by: sscovil's profile sscovil Owned by:
Milestone: Priority: normal
Severity: trivial Version: 3.5
Component: Taxonomy Keywords:
Focuses: Cc:

Description

I ran into this problem while writing a plugin uninstall class to clean up any options, custom post types, taxonomies & terms related to the plugin.

The problem is, if a plugin creates a custom taxonomy and the plugin user creates terms for that taxonomy, the plugin cannot delete those terms during uninstall.

How to reproduce:

  1. Create a plugin that creates a custom taxonomy.
  2. Create some terms for that taxonomy.
  3. In uninstall.php, try using wp_delete_term to remove those terms.

Because the plugin is already deactivated by the time uninstall.php fires, $wp_taxonomies no longer contains the custom taxonomy that the plugin created. Since wp_delete_term requires a valid taxonomy as its second parameter, it does not work.

The issue is also being discussed here: http://bit.ly/RUDYOv

Change History (11)

#1 @sscovil
12 years ago

It should also be noted that get_terms fails in uninstall.php for the same reason, which is relevant since you would need to use that function to loop through the terms.

#2 @sscovil
12 years ago

  • Cc sscovil@… added

#3 follow-up: @SergeyBiryukov
12 years ago

The workaround is probably to re-register the taxonomy in uninstall.php before calling wp_delete_term().

#4 in reply to: ↑ 3 @sscovil
12 years ago

Replying to SergeyBiryukov:

The workaround is probably to re-register the taxonomy in uninstall.php before calling wp_delete_term().

Yeah, that would work I suppose...but that puts the burden on plugin developers to take an extra step that WP itself should handle. My goal in creating this uninstall class was actually to simplify things for plugin developers.

I wonder if, before deactivation, WP could save $wp_taxonomies temporarily. Then, after deactivation, WP could compare the new $wp_taxonomies to the old and determine which taxonomies were registered by the plugin. Then, in the database, a relationship could be made between the taxonomy and the plugin so that, when uninstall.php is run, any terms associated with the plugin-specific taxonomy would automagically be removed.

Does this sound feasible? Any ideas why it might not work, or what undesirable side-effects could result? If not, I'd be happy to attempt writing a patch...

#5 follow-up: @dd32
12 years ago

I personally think that this should be left up to plugin authors, just as uninstalling is left up to the plugin authors.
A plugin can re-register / run any init handlers it needs upon uninstall to create the proper environment for it's uninstall handler.

Ultimately, a plugin could add all sorts of special filters to modify how Terms are handled, as well as Custom Post Types, potentially custom comment statuses, and post statuses.. the list of things just grows in size, for WordPress to keep track of every single item type IMHO would become much more of a burden.

#6 in reply to: ↑ 5 @sscovil
12 years ago

The key difference is in the way WordPress relates custom taxonomies to terms -- apposed to, say, the way it relates custom post types to posts.

If I want my plugin to remove all posts of a post type that my plugin created, I can do that without needing to re-register the post type first. If I want to remove all terms for a custom taxonomy that my plugin creates, this is not the case.

For that reason, I believe the onus should be on WordPress (and not each individual plugin developer) to find a solution.

Replying to dd32:

I personally think that this should be left up to plugin authors, just as uninstalling is left up to the plugin authors.
A plugin can re-register / run any init handlers it needs upon uninstall to create the proper environment for it's uninstall handler.

Ultimately, a plugin could add all sorts of special filters to modify how Terms are handled, as well as Custom Post Types, potentially custom comment statuses, and post statuses.. the list of things just grows in size, for WordPress to keep track of every single item type IMHO would become much more of a burden.

Last edited 12 years ago by sscovil (previous) (diff)

#7 @sscovil
12 years ago

In other words, I think there needs to be a relationship between taxonomy and term that is not dependent on a taxonomy currently being registered.

EDIT Or, rather, a function that does not require a currently-registered taxonomy as one of its parameters.

Last edited 12 years ago by sscovil (previous) (diff)

#8 @markoheijnen
12 years ago

Personally I don't think you should remove data on uninstall process. You don't know it a user is expecting it to be removed at all. Settings can make sense but for posts/terms it doesn't. On that note I do agree with dd32 on his answer.

#9 @sscovil
12 years ago

I agree that the user should be informed when deleting a plugin that this action will delete all associated data -- or perhaps be given an option during uninstall -- but the difference between deactivating a plugin and deleting it suggests that one will retain data and the other will remove it.

Regardless of where we each stand on the etiquette of data removal, I think we can all agree that we (plugin developers) should not have to re-register a custom taxonomy during uninstall just to delete its terms, amiright?

#10 @sscovil
12 years ago

  • Severity changed from normal to trivial

Anyhow, the workaround suggested by @SergeyBiryukov is easy enough to implement so I am marking this bug as trivial. If anyone wants to remove terms associated with their plugin's custom taxonomies, see the uninstall class I've written here: https://github.com/sscovil/wpPluginFramework

#11 @wonderboymusic
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.