[wp-trac] [WordPress Trac] #27188: deactivated_plugin behaves improperly

WordPress Trac noreply at wordpress.org
Thu Mar 27 01:49:14 UTC 2014


#27188: deactivated_plugin behaves improperly
--------------------------+-----------------------------
 Reporter:  wpsmith       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Plugins       |     Version:  2.9
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------------
Changes (by nacin):

 * milestone:  3.9 => Future Release


Comment:

 This function works in a loop. The option is not actually updated until
 the end, while each plugin gets its hooks fired in turn. The patches
 attached won't work as they move deactivated_plugin to after the
 update_option() calls — from inside the loop to outside of it.

 I agree, conceptually, that the option should be updated *before*
 deactivated_plugin. To do that, we'd need to call update_option() inside
 the loop, which means more database calls (at least when we're bulk
 deactivating). I don't see that as a terrible thing, but it's not
 something I'd like to just do (especially since we hadn't caught it before
 now that this change would be a problem).

 activate_plugin() does *not* work in a loop. activate_plugins() calls
 activate_plugin() which handles both the hooks and the option calls.
 activated_plugin properly fires at the right time.

 I don't really care if we introduce a deactivate_plugin() function to
 mimic activate_plugin(), but I'm otherwise fine with these changes if done
 properly.

 In the process, I noticed some docs were wrong, so I'm fixing those as
 well.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27188#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list