A plugin update broke a client's WordPress site. What to do in the next 15 minutes

The next 15 minutes

1. Check what the visitor sees. Open the site in a private window. A white screen or "critical error" page means PHP is failing. A broken layout means CSS or a builder is the problem. They have different fixes.
2. If you cannot reach wp-admin, turn the plugin off from outside. Over SFTP or your host's file manager, rename the plugin's folder in wp-content/plugins (add -off to the name). WordPress deactivates a plugin it cannot find. With WP-CLI it is wp plugin deactivate plugin-name.
3. Roll back that one plugin, not the whole site. Install the previous version. With WP-CLI: wp plugin install plugin-name --version=1.2.3 --force. A full backup restore also works, but on a store or a busy site it throws away every order and form entry since the backup was taken.
4. Read the error log. Your host's PHP error log names the file and line that failed. That one line usually tells you whether it is the plugin, a conflict with another plugin, or an old PHP version.
5. Clear every cache (page cache, object cache, CDN, and the builder's own CSS cache) and look again in a private window before you tell the client it is fixed.

Why it happened

It is almost always one of four things: two plugins that no longer agree, a plugin that now needs a newer PHP than the server runs, a theme or builder that overrides a template the plugin changed, or a database change that ran halfway. None of them shows up until the update runs against this site's real content. That is why "it worked on my other sites" does not help.

The routine that stops it happening again

1. Update on a staging copy first. A recent copy of the live site, on the same host, with the same PHP.
2. Take screenshots before and after. The home page, the key landing pages and one of each template, on desktop and on a phone. Compare them. Do not trust your memory of what the page looked like.
3. Test what screenshots cannot see. Submit the contact form and confirm the email arrives. On a store, add to cart and reach checkout.
4. Update one thing at a time when the site matters. If something breaks you know which update did it.
5. Publish, then check the live site the same way. Live is not staging. Caches, CDNs and real traffic behave differently.
6. Keep the way back ready. Know the previous version number and have a backup point from before you started.

Should you update WordPress or the plugins first?

Usually plugins and themes first, then WordPress core. Plugin authors release compatibility updates ahead of a core release, so updating core first can leave you running old plugins against new core. For a major core release, wait a few days and read the plugin changelogs first.

Should you turn on automatic updates?

For security patches on small brochure sites, yes. For a store, a membership site or anything a client's revenue runs through, automatic updates without a check afterwards are how you find out about a problem from the client. Automatic is fine when something is also checking the result and can reverse it.

Where SquareJuice fits

SquareJuice runs this same routine as software: the change is made on the site's staging copy, before and after screenshots are compared, you approve it, it is published, the live site is checked, and it is reversed automatically if a check fails. Today it does this for the content changes clients ask for. Plugin updates through the same loop are in build.

Questions