The Docker Manager is great for keeping everything up-to-date, but it’s awfully slow when you have more than one thing that needs upgrading, not to mention that you need to restart the web server once for each plugin.
I’d like to propose a new button called Upgrade All that would go through and upgrade everything in one quick run, similar to what a ./launcher bootstrap app does.
Add another advantage: You aren’t going to have incompatible plugins that invoke unintended behavior, such as making the upgrade page impossible to reach or delete your database.
May I suggest a in front of each Plugin, which is checked by default?
And then just an upgrade button.
Then the default action would be upgrade all, but you could easily upgrade a subset if you wanted to.
This is more flexible and would allow you to upgrade 3 of 5 plugins without restarting more than once.
Something I would love to be able to do is upgrade the core and all plugins at one time with a single click from the Upgrade screen. Unless I’m missing something, I currently need to go through each one individually and that can take a significant amount of time. I like being able to do them individually if I need, but mostly I want to update everything when I do this.
I would propose a simple (in UI, not implementation ) “Upgrade All” button on the Upgrade screen.
So much quicker to just update everything in one shot with ./launcher rebuild app I don’t use the admin update interface at all because of this exact issue.
Ye, you’re right. But in some cases it’s nice to limit the access to the server - and just provide access to the Docker Manager. But for sure, you’re right (-:
I often use the update via GUI to reduce the offline time of the site.
The only problem I see in an Update all button is when you need to do the update of the docker_manager first. In this case all the buttons to upgrade the plugins are grey and unclickable because you must upgrade the docker_manager first and then rebuild the site via SSH.
In this particular case the Update all button should disappear or in any case not be clickable until the rebuild.
I agree an Update all feature would be a much better approach for end users and those who know nothing about command line options. I do agree running it from the command line does take the site down for longer than if updated through the admin panel.
The client code I’m having trouble visualizing how to refactor. I suppose a MultiRepo object constructed by the Upgrade All handler that combines together the paths/versions and presents the same interface as a Repo object? It feels like that is going to run into duck-typing problems.