[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