How to manage many active plugins in Central Package Server Satispress setup?

[j-falk]

We are using Satispress as a Central Package Server on a dedicated WordPress install and Digital Ocean droplet. It is working great, but now with approximately 130 plugins and a couple of themes we are recognizing that performance is taking a hit, primarily because in our experience we need to have most premium plugins also activated for having updates working as it should due to licensing.

This makes especially the WordPress admin very slow, cluttered with all plugins own notices, settings pages and also sometimes give compatibility issues between certain plugins.

I’ve tried to search around for how others have solved this, but haven’t found too much info.

When discussed internally we have thought about 2 possible approaches:

1. Keep all plugins deactivated by default but have a WP CLI script that runs daily that activates all plugins, check for plugin updates, updates all plugins and then deactivates all plugins.
2. Keep all plugins activated by default but enable a similar admin mode like the “Troubleshooting mode” that the plugin “Health Check & Troubleshooting” (https://wordpress.org/plugins/health-check/) has that filters the active plugins (https://github.com/WordPress/health-check/blob/4f8919c596a46dec3659decb3b7c202671a91a55/src/php/assets/mu-plugin/health-check-troubleshooting-mode.php#L62).

Any previous experience and/or thoughts around this would be very much appreciated.

[bradyvercher]

I don't use SatisPress with a ton of plugins, so haven't run into the performance or plugin conflict issues myself.

Personally, I would probably write an mu-plugin to disable plugins while using the dashboard. As long as wp_cron() is being spawned by visits to the site, I believe updates should continue to work, but some custom updaters may only run during admin requests. There is a bit of discussion in #75 and #117 that might provide some more ideas.

I'm all ears if there's something that could be incorporated directly into SatisPress that would help with this.

[koengabriels]

We are managing 630 or so plugins with SatisPress and keep all plugins except Envato Market deactivated.
On our local development setups we have default settings so WP shows us if the project we are working on has updates available.
Each day one of our developers is also responsible for doing maintenance which means every day a lot of sites get checked for updates as well.
When that happens, the developer that spots this will install the update on our satispress site.

That does mean we might not always have the latest version for each plugin available immediately on satispress but we have experienced quite a lot of plugins that use really bad version strings so they break Satispress so after each "batch" of plugin updates we immediately test if the packages.json works.

Currently we manually change these bad version strings to a string that makes sense versioning wise and which doesn't crash Satispress.
This however is becoming unmanageable so we are looking into finding a solution for this as well as speeding things up.

If we have something figured out that makes sense to add it to Satispress we'll gladly provide pull request.
This is still a big if atm because our clients are keeping us quite busy :)

[patrick-leb]

We're starting to have the same problem here as well, with about ~150 plugins. Just to run this wordpress install takes more juice than many smaller clients.

The killer is having to keep plugins activated indeed.

I like your idea @j-falk to basically have a daily cron that activates and updates, but I think some paid plugins require a visit on the admin page to check on their own servers.

So here too, are looking for a solution!

[sangemaru]

What about a script in the crontab that cd's into the wordpress folder, runs wp plugin activate --all && wp plugin update --all && wp plugin deactivate --all --skip-plugins=satispress?

[j-falk]

As a quick update we have moved forward a bit at least in the thought process around this.

We have defined 2 problems that we need to tackle:

• Conflicting plugins. There are sometimes plugins that conflict with each other and could give a fatal error or similar if they are activated at the same time. This means that having all plugins activated at the same time often won't work. This also means that my second option "Keep all plugins activated by default but enable a similar admin mode like the “Troubleshooting mode”..." won't work.
• Dependent plugins. Some plugins are dependent on others which often means that the dependent plugin needs to also be activated for the plugin and its update should work as it should. This could eg be a plugin that depends on WooCommerce (and will deactivate unless WooCommerce is active) and add-on plugins, eg Admin Columns Pro - Advanced Custom Fields is dependent on Admin Columns Pro. This then means that my first option "Keep all plugins deactivated by default but have a WP CLI script that runs daily that activates all plugins..." also won't work.

Based on this we have instead thought about that if we somehow could define is a plugin is dependent on another plugin, we could then have a script that loops through each and every plugin, activate the plugin (and dependent plugins if there are any), update and deactivate. This would then solve both of the mentioned problems.

Any thoughts on this would be very much appreciated.

[Levdbas]

I think we need a new option in satispress for this to work:

• Define sets op plugins that will be activated/deactivated all at once.

Update process
So there needs to be a new updater process that will collect an array of all plugins managed in satispress and collect the plugin sets that are related to eachother. All plugins in sets will be removed from the first array with all plugins managed by satispress.

This will leave us with an array of individual operating plugins and plugin sets. A process described by @sangemaru could then loop over this array and will do the following stepts:

• Activate plugin/plugin set by using activate_plugin();
• Start update process by looking for updates by running wp_update_plugins() and then updating then use Plugin_Upgrader::upgrade method to update the plugins one by one.
• Inform Satispress itself of new versions? Not sure if this is needed.
• Deactivate the plugin/set once the update process is completed.

Trigger process
I suggest having a big 'ol button to manually trigger this process and add this as a script to the crontab.

This is all hypothetical but I would like to reopen the discussion a bit since I am on the brink of maximum plugins as well on my Digital Ocean droplet.

[timnolte]

The performance issue, and requirement that plugins be activated, has also been a concern of ours. I've also been approached about changing the way we manage premium plugins using SatisPress and moving to some other package management solution, though I've pointed out that I don't think there is a reasonable alternative to SatisPress given how plugin updates need to occur. One issue that I'm seeing is that while many of our active plugins are getting updates some are never being updated, which I suspect has to do with the method in which the plugins actually check/manage their plugin updates.

[thefrosty]

We are in the same boat, and just added some plugins that are "expensive" and heavy on the server. I would suggest to everyone that they take a look at this article on Kinsta and look into plugins that could manage disabling plugins on select pages except the updates/plugins page(s) etc...

• Plugin Organizer
• Plugin Load Filter

[bradyvercher]

An alternative approach to get around the performance issue could be installing SatisPress on the production sites and have it send updates to a central package server (Amazon S3, remote server, some other package management solution, etc). The storage layer has been abstracted, so it should be possible to write a storage adapter to handle that.

That might not work if the production sites disable update requests altogether.

The central package server would also need to generate the packages.json manifest -- unless it was also running an instance of SatisPress.

One issue that I'm seeing is that while many of our active plugins are getting updates some are never being updated, which I suspect has to do with the method in which the plugins actually check/manage their plugin updates.

There are some plugins that bypass the WordPress "update API" and implement their own routine in order to lock down the process, so SatisPress doesn't capture those updates. It might be possible to write an adapter, so that's worth looking into to save some time.

[dr5hn]

In my situation, I addressed the performance issues of the CMS by incorporating a small code snippet as an mu-plugin. This approach was chosen because I didn't require the full functionality of the plugin; my sole objective was to utilize SatisPress for the management of those plugins, nothing more.

mu-plugins/plugin-filter.php

<?php
/*
  Plugin Name: SatisPress MU Plugin Filter
  Description: This plugin disables all plugins except the ones listed in the array below. This is useful for keeping plugins active in the admin area that are required for the site to function properly.
  Version: 0.1
*/

add_filter('option_active_plugins', 'conditionally_enable_plugins_in_admin');

function conditionally_enable_plugins_in_admin($plugins)
{
    // $request_uri = $_SERVER['REQUEST_URI'];
    // $is_plugins_page = strpos($request_uri, 'plugins.php');

    if (is_admin()) {
        $plugins = [
            'satispress/satispress.php',
            // ...
        ];
    }

    return $plugins;
}

Hope this helps! 🍻