Bug #4799


Critical plugins for the main Commons site should be loaded programatically

Added by Boone Gorges over 7 years ago. Updated over 7 years ago.

Priority name:
Category name:
WordPress Plugins
Target version:
Start date:
Due date:
% Done:


Estimated time:
Deployment actions:


During a recent Commons upgrade, I wrote a script that accidentally deactivated a bunch of stuff on the main Commons site. This was an extreme example of something going wrong, but it points toward a more general problem that it's possible to deactivate critical functionality on the main site, through the wp-admin/plugins.php interface.

We should load our critical libraries in such a way that they cannot be deactivated. The most straightforward way to do this is in an mu-plugin, which bootstraps each relevant plugin directly. (We could then add these plugins manually to the 'active_plugins' array, so that they show up in the plugins.php list, though this is not strictly necessary.)

Ray, have you done this before? Anything to watch out for? Loading from mu-plugins will mean that items are loaded in a somewhat different order than they currently are - by muplugins_loaded rather than plugins_loaded - though this could be mitigated by putting everything inside of a 'plugins_loaded' callback in the mu-plugin.

Actions #1

Updated by Raymond Hoh over 7 years ago

I would feel safer filtering the 'active_plugins' option since that is the main way WP loads plugins.

Even using 'plugins_loaded' is a little tricky because that changes how some plugins are loaded. For example, by default, BuddyPress loads its singleton immediately instead of on a hook like 'plugins_loaded'.

Actions #2

Updated by Boone Gorges over 7 years ago

  • Status changed from Assigned to Resolved

Thanks, Ray. The filter is a good idea. In I added a filter that forces critical main-site plugins and critical network plugins to be active.


Also available in: Atom PDF