Before and after a risky update: what WP Safer protects, and what it does not

This is the honest version of "is it safe to click update". WP Safer has three separate safety nets around an update, they cover different things, and one of them is the one you have to set up yourself.

WP Safer does not snapshot the site before an update

There is no automatic full backup taken the moment before a plugin, theme or core update. If you want a restore point from immediately before a change, take one yourself — it takes two clicks and a few minutes.

The reason we do not do it silently is cost and honesty: a full copy of a site's files and database before every plugin update on every site would multiply your stored backups many times over, and most updates do not need it. A weekly schedule plus a manual backup before the changes you consider risky is the setup we recommend.

What does happen automatically, for plugin updates

Before the connector plugin touches a plugin's files, it zips that plugin's own folder into wp-content/uploads/wpsafer-plugin-backups/ on the site. Then it installs the new version and, before calling it a success, loads the plugin once to see whether it prints a fatal-looking error.

If the install fails, or that load produces an error, the copy is unpacked back into place and the answer you get in the panel says so: "The updated plugin printed a fatal-looking error when loaded; the previous version was restored automatically." After a successful update the copy is deleted a few minutes later, so it does not sit in your uploads folder.

Two things this is not:

• It is not a site backup. It contains one plugin's directory. The database is not part of it, and neither is anything the new version wrote there before it failed.
• It cannot catch everything. A plugin whose new version is broken badly enough to kill the PHP request outright — a parse error, a call to something that does not exist — ends the request before any of this can run. That case is caught later, by the check after the update.

Theme and WordPress core updates go through WordPress's own upgrader and do not get this extra copy.

What happens after the update

On the paid plans, a few minutes after an update WP Safer ran from the queue, the site is read again — the home page and one inner page. If that reading says the site is broken, WP Safer reinstalls the previous version from the official wordpress.org package, tells you, and pauses automatic updates for the site.

The rollback is at file level: the database is not touched. WordPress core is only put back inside the same release series, because core moves its database schema forward on feature releases and does not support moving it back.

Full details, including the three possible outcomes of that check and why "could not measure" is not "broken", are in When an update breaks a site.

One boundary worth knowing: the check, the change record and the automatic rollback apply to updates WP Safer ran from the queue — Update all, Update core and automatic updates. A single Update to … click runs immediately and is not followed by the check, which is another reason to use it for the updates you are watching, and the queue for the rest.

Putting one plugin back by hand

When a site has gone down and WP Safer recorded a plugin update shortly before it, the incident on the site's Uptime tab lists that change with a Roll back button next to it. It reinstalls the version the plugin had before, from wordpress.org, after a confirmation.

The button is disabled with the reason written next to it when there is nothing to go back to — for example when wordpress.org no longer publishes a package for that version, when the update did not actually change the version, or when it has already been rolled back. A Restore the last backup button sits under the same list while the incident is still open; that one replaces the database as well, so it goes through the normal restore dialog.

A sensible routine

1. Keep a backup schedule on every site you care about, and check the Backup column on the Sites page now and then — a red No backup there is the real risk.
2. Before a major version jump (a page builder, WooCommerce, a theme framework), take a manual full backup of that site.
3. Let automatic updates handle the routine security releases, and keep the handful of plugins you do not trust locked.
4. After a big update, open the site. No automated check replaces looking at the page.