Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#53628 new enhancement

Maintenance Free Updates - Zero downtime

Reported by: billybigpotatoes's profile 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.

Change History (4)

#1 @billybigpotatoes
3 years ago

  • Keywords dev-feedback reporter-feedback removed

I assume this approach could also work with multisite deployments too

#2 @billybigpotatoes
3 years ago

FYI We have now been running this process for several months and it is working well for us. Keen to discuss how to move this forward to more people can benefit

This ticket was mentioned in Slack in #cli by billybigpotatoes. View the logs.


3 years ago

#4 @SergeyBiryukov
3 years ago

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Just noting that some related work is being done in #51857, feel free to join the discussion there if you'd like. The latest activity for that ticket is on PR #2225.

Note: See TracTickets for help on using tickets.