Auto updates on self hosted sites have one major disadvantage, they happen as and when an update becomes available, not when it suits the site owner. This has a couple of unwanted side effects:
– the volume of checking can significantly slow down a site (hence the popularity of plugins that disable auto-updates), especially because requests do not happen asynchronously
– updates can happen right in the middle of a logged-in session (I myself had it happen in the middle of an Elementor page design session).
– backups are not 100% reliable as recovery mechanism.
The problem is, of course, that updates are critical to maintain security, so what about putting the site owner in charge? I know, shocking concept to let the actual owner decide what happens on their site (gasp :), but what about making CLI tools available that allow site owners to set up cron jobs to enable/trigger/disable auto-updates? They know their site load, so they cab run this during low volume. It would also enable them to run a backup before such an update session, creating a rollback ability in case an update is less than perfect or generates a site conflict.
This does imply that there is a mechanism in place that triggers updates as soon as the ability is enabled. I’m also not sure if it would be possible to choose such an update process to sequentially walk through site plugins to reduce load impact, but that also suggests an alternative approach: updates (and associated polling/traffic/slowdowns/UI impacts) are disabled until a run is triggered which updates each element (WP, themes, plugins) once, then ends updates until the next trigger – for high end sites, this would be close to perfection.
It is but a suggestion, but given that I see “Disable auto-updates” plugins be very popular it appears I’m not the only one who finds the current process helpful, but in need of some finetuning by giving site owners control over the timing.
- The topic ‘Ability to control/schedule the update process (CLI) required’ is closed to new replies.