Opened 3 years ago
Last modified 3 years ago
#53628 new enhancement
Maintenance Free Updates - Zero downtime
Reported by: | billybigpotatoes | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.8 |
Component: | Plugins | Keywords: | |
Focuses: | Cc: |
Description
I have been testing an approach to allow updates to be deployed to themes and plugins with Zero downtime (no maintenance page needed).
It seems that WP if fairly sympathetic to the approach and I am keen to see if there are any red flags - and also the opportunity to get the approach into core so the world can benefit from it if!
The approach is as follows:
- When a plugin update is available - install the plugin into a directory that is namespaced with the plugin name AND version (as per the meta) e.g. /wp-content/plugins/plugin-v1.3.2
At this point WP will see two instances of the plugin - but it treats them as unique and the initial plugin remains active
- Activate the plugin - via a database update - modify the wp_options row to set the new plugin to be active. It is critical that this is done as a database update - so that it is an atomic action - allowing WP to continue to process requests as the switch over takes place.
The old plugin can remain in place to support roll back and then deleted
Rollback is simply a question of restoring the active plugins options field back to the original settings
Pros / Cons
- I have tested this manually and WP seems happy - both locally and on hosted environments. As far as WP seems to be concerned it is seeing a new plugin.
- As the plugin directory is now namespaced - all assets in it e.g. css /js will also be cache busted ensuring all assets in your release are updated.
- WP does not currently have a plugin updated event - the activation of the new plugin will simply go live.
- A "pre flight" step could be run on plugin update to check the plugin is well formed and no PHP errors exist - ensuring that it is not possible to activate a faulty plugin
- We have also seen that with our automated plugin updater - it still works to deploy the new plugin as the location of the plugin deployed in a zip unpacks into a new directory.
We are looking to build a WP_CLI plugin to deal with the activation - it works with plugin active / plugin deactivate - but this is not atomic so there would be a period of time where the plugin would be missing so we are replacing it with a transaction.
I am very keen to get feedback on this approach - as we are going to start using it on our sites.
I assume this approach could also work with multisite deployments too