A shop selling garden furniture ran on WordPress with WooCommerce, and its owner had switched on automatic updates for plugins. That is usually a good default: most compromised sites are running software with a known, already fixed flaw, and updates close the gap before anyone has to think about it.
One weekday afternoon, a payment-related plugin released a new version that required a newer PHP version than the server was using. The update installed itself at 14:05, during the busiest hour of the day. By 14:06 the shop was a white page.
What the owner saw
Not an error message. A blank white page, on every address, including the product pages and the basket. Then a customer rang to ask whether the shop was closing down, and a second message arrived through the social media account.
The owner tried the admin login at /wp-admin/ and got the same blank page. That was the cruel part. The usual advice for a misbehaving plugin is to log in and deactivate it, and the admin area was down along with everything else, since WordPress loads active plugins on every request, admin or not.
A blank page happens when PHP hits a fatal error and the setting that displays errors to visitors is off. That is the normal and correct production default, because messages can reveal file paths and other details. The side effect is that a fatal error looks like nothing at all. WordPress has a recovery mode that can email a special login link when it detects a fatal error, but the email went to an address nobody read.
Why a plugin update can need a newer PHP
Plugin authors eventually drop support for old PHP versions, so that they can use newer language features and stop testing against releases that are out of support. The plugin's header usually says what it needs:
Requires at least: 6.2
Requires PHP: 8.1WordPress checks that line for plugins from its official directory and will warn or refuse to install on an incompatible server. In practice there are gaps. A premium plugin installed from a zip file, or one updated by its own licensing system, may skip the check, or may check and still fail halfway through. In this case the new code used syntax that an older PHP cannot even parse, so the plugin file failed at load time with a parse error rather than a tidy message.
The way out, step by step
With no admin access, the route is through the files. Most hosts give a file manager in the control panel and SFTP access; either will do.
- Connect and open
wp-content/plugins/. - Find the folder of the plugin that updated at that time. The modified date on the folder shows it, and so does the plugin's name.
- Rename the folder, for example from
pay-gatewaytopay-gateway.off. - Reload the shop. WordPress notices that the plugin file is missing and deactivates it automatically.
- Log in, confirm that the shop works, and put the folder name back only after the cause is fixed.
Renaming took about ten minutes, most of which was finding the right folder and remembering the host login. If the shell is available, the same thing is one line:
cd ~/public_html/wp-content/plugins
mv pay-gateway pay-gateway.offThe shop came back immediately. Total downtime was about 50 minutes, during which a few dozen orders were lost, along with a certain amount of goodwill.
Wrong turns and the rest of the afternoon
Before renaming anything, the owner spent twenty minutes on the wrong theory: that the host had a problem. The host's status page was clean. A support agent asked for the error log, found the fatal error in it and named the plugin within a minute or two, which is where the file manager route came from.
Once the shop was up, the real fix took longer. The server was running PHP 7.4 and the plugin needed 8.1. Raising the PHP version in the control panel is easy, but it changes the whole site, so the owner first checked every other plugin and the theme for compatibility, ran a test order, and only then made the change and reapplied the plugin update. That was done in the evening, when traffic was lowest, and she stayed up to watch the orders and the log.
A short email to the customers who had hit the blank page, with a discount code, recovered some of the sales. Some customers had already bought elsewhere.
Is automatic updating the problem?
No, and turning it off is the wrong lesson. Unpatched plugins are among the most common ways sites get compromised. The real issue was how little protected the shop when an update went wrong: no staging copy, no known way in without admin access, no alert, and nobody watching at the time.
| Approach | Protects against | Cost |
|---|---|---|
| Auto-update everything | Known vulnerabilities | Occasional broken update |
| Auto-update minor, manual major | Most flaws, and big changes | A weekly check by a person |
| Staging first, then live | Both | Time and some setup |
| No updates | Surprises | Eventual compromise |
A middle path suits most small shops: leave minor and security releases automatic, make major releases of payment and checkout plugins manual, and try them on a copy first.
Quick answers
Will renaming the folder lose my plugin settings?
Almost always not. Settings live in the database, not the folder. Once you restore the name and reactivate, they are usually all there.
What if I cannot tell which plugin it is?
Rename the whole plugins folder to deactivate all of them at once, confirm the site loads, then restore it and reactivate one by one.
Can I roll back a plugin?
Yes, by uploading the previous version's files over the folder. Keep a copy of the old zip from your last backup.
Should payment plugins update automatically?
Many shop owners prefer to do those by hand after testing, since a failure there costs money directly.
The aftermath
The owner wrote down what had happened while it was fresh, and the timeline was uncomfortable to read. The update ran at 14:05. The first customer complaint came at 14:20. The owner learned of it at 14:35, when a friend rang. The file manager route was found at 14:50 and the shop was back at 14:55. Of those fifty minutes, thirty were spent not knowing, and that is the part that no change to the plugin would have fixed.
The plugin's author, contacted afterwards, confirmed that the new minimum PHP version was stated in the changelog and in the plugin header. The information was available; it had not been read, because an automatic update does not ask anyone to read it. The shop's settings were changed so that payment and checkout plugins now wait for approval, and a free uptime monitor now checks that the basket page contains the word "Checkout" every minute, texting the owner when it does not. The first real alert, three months later, was a false alarm caused by a short hosting blip. The owner was glad to receive it.
What would have caught it
- A staging copy where updates are tried first, with a test order before they reach the live shop.
- Reading the requirements line in the changelog before accepting a major update.
- Knowing in advance how to disable a plugin without admin access: rename its folder over SFTP.
- Scheduling updates for quiet hours, and having someone watching afterwards.
- An uptime check that looks for a word on the page, not just a response, plus an alert to a phone.
- A recovery email address that someone actually reads.