-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to manage many active plugins in Central Package Server Satispress setup? #151
Comments
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 I'm all ears if there's something that could be incorporated directly into SatisPress that would help with this. |
We are managing 630 or so plugins with SatisPress and keep all plugins except Envato Market deactivated. 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. If we have something figured out that makes sense to add it to Satispress we'll gladly provide pull request. |
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! |
What about a script in the crontab that cd's into the wordpress folder, runs |
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:
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. |
I think we need a new option in satispress for this to work:
Update process 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:
Trigger process 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. |
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. |
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... |
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
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. |
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! 🍻 |
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:
Any previous experience and/or thoughts around this would be very much appreciated.
The text was updated successfully, but these errors were encountered: