[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