Updating WordPress, plugins and themes without breaking the site

There is a fear of the Update button that is entirely rational. Everyone has clicked it and watched the site go white, or the layout collapse, or the checkout stop working. So updates get postponed, the site falls behind, and the holes that updates would have closed stay open. The answer is not to update less. It is to make updates safe, which turns out to be a matter of routine.

The one setup that changes everything

A staging copy. An exact copy of the site at a private address, where updates run first. If something breaks there, nothing happened to the live site and you have learned what breaks before it matters. Most decent hosts create one with a button. If yours does not, a plugin can, or a developer can set one up in an hour.

Once staging exists, the fear goes, because the worst case is “it broke on the copy”.

The routine

1. Backup first. Even with staging. A fresh backup of the live site, stored off the server.
2. Read what is waiting. The updates page lists everything. Anything marked as a security release goes first. Read the changelog for major version jumps of big plugins, especially the shop, the form, the page builder and anything that touches the database.
3. Update staging. Core, then plugins, then theme. All of them, not a selection, because the combination is what matters.
4. Click through staging. Home, a service page, a post, the contact form, the login, the checkout if there is one, on a phone as well as a desktop. Five minutes. Look at the browser console for errors if you know how.
5. Check the error log. Warnings there predict what will break in the next version.
6. Update live the same way, at a quiet hour. Then click through again.
7. Note what changed. If something is odd next week, that note is where the investigation starts.

An hour a month for a typical site. Longer the first time if the site is far behind.

When something breaks

• White screen. Check your email for the recovery link WordPress sends when a plugin or theme fails; it lets you in with the broken thing disabled. Or rename the offending plugin’s folder over SFTP to disable it.
• Layout broken. Usually the theme or the page builder. Clear every cache first, including the browser’s. Then roll that one plugin back a version.
• A feature stopped working. Roll back that plugin, and check whether the author has already released a fix.
• Everything wrong. Restore the backup from step one. That is what it is for.

Automatic updates, honestly

Turn them on for minor WordPress releases, which are the security ones. Consider them for small plugins from reliable authors. Do not turn them on for the page builder, the shop, or anything whose failure would take the site down, unless you have staging that updates first and something that tells you when live breaks. An automatic update at three in the morning to a plugin with a bug is how sites are down until nine.

PHP versions

Updating PHP is an update too, and the one most often ignored. It follows the same routine, on staging first, and it is the update that most often surfaces old code that needs replacing. We wrote it up separately because it deserves its own hour.

Why this is the heart of maintenance

Almost every hack we clean used a hole that an update had already closed. The routine above is the difference between a site that is patched within the month and one that is running last year’s holes. It is the core of every care plan we run, and it is the one hour a month that prevents the most expensive problems a site can have.