Recovery
What happens when an update breaks the plugin, when the platform is not there, and what a person has to do.
Two things that can go wrong
- The plugin cannot load. A plugin update — including the worker's own — leaves the site failing on load, and the worker's normal way of answering the platform never gets a chance to run.
- The platform is not there. A round that put the site into maintenance mode cannot take it back out because the platform, or the connection to the site, is gone.
The worker is built so that neither strands the site.
When the plugin cannot load
The worker ships with recovery files beside its main file that work without loading the plugin — or any plugin at all. Through them the platform can put the previous worker version back from its rollback copy, undo what an update round changed, and lift maintenance mode, on a site whose plugin layer is broken. Since 2.1.3 a small loader installed alongside the plugin lets the platform restore the worker even when the plugin's own files are damaged; it acts only for the platform the site is paired with, and only when that platform asks.
The recovery files are part of the product
A security scanner or a cleanup that flags "unused PHP files in the plugin root" and removes them takes the site's recovery with it. Leave them in place.
What recovery cannot do is bring back a plugin directory that has been deleted entirely, because the recovery files went with it. Such a site runs unmanaged, which is safe, and the platform reports it as unreachable; uploading the current zip brings it back.
Maintenance mode lifts itself
An update round puts the site into maintenance mode, and the platform is what takes it back out. So the worker's own maintenance flag carries an expiry — never more than four hours — after which the site comes back on its own, whatever happened to the round. Before worker 2.1.8 a site whose round never finished stayed dark until a person noticed; the platform now refuses to start a round on a worker older than that.
The worker's own rollback
A self-update keeps the previous version outside the plugin folder, three copies deep, and rolls back on any failure it detects itself. The platform checks the installed version afterwards by asking the site, and orders a rollback when the answer is wrong.
What the platform does for a site it cannot reach
Nothing to the site. It records the cause, writes an instruction for a person where one is needed, keeps asking on a schedule that widens with each failure — and when the site is reachable again, marks it recovered and brings its worker up to the current release. Hosting compatibility covers the firewall case; Troubleshooting lists the states.
What a person has to do
- A broken plugin the platform could not repair, or a site the platform cannot reach: upload the current zip over it through Plugins → Add New → Upload Plugin. The site reports the version on its next contact.
- A plugin directory that is gone: install the plugin again and paste the workspace token — Installation.
- A maintenance page that outlives four hours is not the worker's. Look at the host and at other plugins.