[wp-trac] [WordPress Trac] #13786: Problems with the current register_uninstall_hook implementation
WordPress Trac
wp-trac at lists.automattic.com
Tue Jun 8 17:22:15 UTC 2010
#13786: Problems with the current register_uninstall_hook implementation
--------------------------+-------------------------------------------------
Reporter: x3r0ss | Owner: westi
Type: defect (bug) | Status: new
Priority: normal | Milestone: Unassigned
Component: Plugins | Version: 3.0
Severity: normal | Keywords: hooks, plugins
--------------------------+-------------------------------------------------
Comment(by nacin):
The option is keyed with the file name, with the value being the callback,
so while it will fetch from the DB and attempt to update the option on
deactivate-reactivate, it won't actually do anything in terms of
duplicating the hook. In fact update_option() should return false since
the arrays would match, so it wouldn't even run the update query.
It's not the issue of that I don't want the entire file loaded. We already
do that if the plugin is uninstallable to actually trigger the hook. It's
also not the plugins that use uninstall.php specifically to prevent
issues. (If the plugin is running unsafe things in global scope, then
chances are the plugin author isn't at the point where he is using an
uninstall hook to clean up his data. The venn diagram circles probably
don't overlap.)
The issue would be plugins that aren't uninstall-aware, and are now
suddenly getting included to check if it can be uninstalled, instead of
checking for registered callbacks. That's a change in behavior and I'm
honestly not sure how many plugins it would break, but when in doubt, I
usually assume issues would arise.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/13786#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list