The site was fine last night. This morning checkout is dead or the contact form is a white screen, and nobody touched anything. Except something did: plugin updates land at strange hours, because auto-update runs whenever WordPress gets around to it. The job now is to confirm that is what happened, put the site back, and only then worry about why.
Confirm it was an update before you fix anything
The evidence is in the error log, and it is usually blunt. In one incident we handled this summer, a checkout plugin updated itself at 6:59 on a Wednesday morning and checkout broke with it. In another, a forms plugin updated in the background while nobody was working on the site, and the first fatal error hit the log within seconds of the new version landing. When an update is the cause, the log almost always says so plainly: a burst of identical errors starting the moment the update ran, naming a file inside the plugin that changed.
One warning from the August incident: don’t trust file dates. The plugin folder’s timestamp pointed at a completely different time than the actual break, because later activity had touched the files again. The error log gave the real timeline, and so did the plugin’s own records, since WordPress keeps note of which version a plugin upgraded from.
Roll back before you debug
Here is the useful fact hiding inside the disaster: the old version was running fine seconds before the update. You don’t need to understand the bug to get the site back, you need a version that worked. In the August case the update had locked the owners out of their own WordPress admin, and the whole fix was rolling the plugin back to the last release that fit the WordPress version the site actually runs, then switching that plugin’s auto-updates off until the rest of the site catches up.
The debugging happens afterwards, on a staging copy, which is how we run every WordPress site we maintain: reproduce the break where no customer can see it, isolate the cause, and decide whether the answer is waiting for a fixed release, patching around it, or replacing the plugin.
The two ways updates break sites
Nearly every update breakage we see is one of two shapes. The first is a fault in the update itself: the plugin maker ships a bug. That was the July incident. The vendor’s new version carried a fault in their own code, and we reported it to them. Two releases later it still wasn’t fixed, so we wrote a small guard that repairs the fault automatically and steps aside if a real fix ever ships.
The second shape is a version mismatch: the new plugin assumes a newer WordPress than the site runs. The August fatal was exactly this, an updated plugin calling on a function the site’s older WordPress core simply didn’t have. The new version even declared it needed a newer WordPress; the plugin’s own background updater installed it anyway. Neither the plugin nor the site was broken on its own. The combination was.
There is a third, quieter failure worth knowing about: an update can undo repairs. Besides its bug, the July update also wiped a manual fix we had put in place the week before. That is why our guard re-applies its repair after every update instead of assuming the fix will stick.
Keep updating anyway
The tempting conclusion is to stop updating, and it’s the wrong one. Out-of-date plugins are among the most common ways WordPress sites get hacked, and a hacked site is a far worse week than a broken checkout. What works is supervised updating: a current backup before anything runs, staging where it matters, a known path back to the previous version, and someone who reads the log when a site misbehaves. That is the arrangement behind the WordPress maintenance and care we run, and it also helps to hear about a break from a monitor instead of a customer.