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 | 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:
- Create a plugin that creates a custom taxonomy.
- Create some terms for that taxonomy.
- 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)
#3
follow-up:
↓ 4
@
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
@
12 years ago
Replying to SergeyBiryukov:
The workaround is probably to re-register the taxonomy in
uninstall.php
before callingwp_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:
↓ 6
@
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
@
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.
#7
@
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.
#8
@
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
@
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
@
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
It should also be noted that
get_terms
fails inuninstall.php
for the same reason, which is relevant since you would need to use that function to loop through the terms.