Critical plugins for the main Commons site should be loaded programatically
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.
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.
'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
Updated by Boone Gorges over 7 years ago
- Status changed from Assigned to Resolved
Thanks, Ray. The filter is a good idea. In https://github.com/cuny-academic-commons/cac/commit/6aacba59953049c695b9bfb323a97942ca132fdb I added a filter that forces critical main-site plugins and critical network plugins to be active.