An automatic plugin update took a site down in five minutes: the post-mortem and the safeguards
At 18:06 WordPress updated a plugin by itself; at 18:11 the site stopped loading. Nobody pressed anything. A minute-by-minute look at why an automatic update meant to protect a site took it down, and what to do so it does not happen to yours.
- What happened — The auto-update installed a plugin several generations newer than the one in place since 2022. The theme relied on code that had been removed — the home page died in five minutes.
- Why — Three causes converged: four years without updates, a theme from the same era, and a neighbouring plugin that lost its settings. An auto-update sees none of them.
- What to do — Security patches: automatically and fast. Major updates: by hand, on a copy of the site, with a backup. And do not keep four-year-old versions.
At 18:06 WordPress on a site we maintain updated a plugin by itself. At 18:11 the site stopped loading. Nobody pressed anything, nobody logged into the admin panel, there was no break-in and no hosting failure. The system simply did what it had been configured to do years earlier, and did it flawlessly.
This post-mortem is about why an automatic update meant to protect a site sometimes takes it down, and what to do so it does not happen to yours. No theory: everything below is the timeline of one evening and the morning after.
The timeline: five minutes from update to a dead site
18:06. WordPress runs the scheduled automatic update of the Elementor plugin — the page builder every page of the site is built with. The site was on version 3.6.5, released back in 2022. The update installs 4.3.5 straight away, skipping several years of changes.
18:11. The home page returns an error. Visitors see a blank screen instead of the site. The editor in the admin panel can neither open a page nor save one.
18:14. A message lands in the working group: «the page will not save». Nobody yet knows the whole site is down.
19:25. The site works. Between those two points lies an hour of investigation, and that is the interesting part.
Why it happened: three causes that converged
1. A plugin version from 2022
The auto-update had left this plugin alone for four years — and then it fired. Why that particular evening does not matter; what matters is that a jump from version 3.6 to 4.3 is not a «patch» but a change of generation. Over those years the developer removed part of the old code they considered obsolete. That is normal practice — but only for those who update regularly and notice the warnings along the way.
2. The site theme relied on that same old code
The theme was also from 2022 and had also never been updated. Eight of its blocks used functions that had disappeared in the new Elementor. The theme calls a function, the function is not there, PHP halts execution. To a visitor that looks like a blank page with an error.
3. A neighbouring plugin lost its settings
The site had another plugin installed that hides WordPress's standard addresses from bots and scanners. During the update it lost the address-rewriting rule for Elementor's files specifically. So even where the theme did not break, the editor could not load its own files: the server answered «not found».
An auto-update does not know that your theme is from 2022, that a plugin intercepting addresses sits next to it, or that nobody has updated this site in four years. It knows only one thing: there is a new version, and it should be installed.
How it was fixed
- Rolled the plugin back to 3.6.5 — the version that had been working that morning. The new one was not deleted but set aside: going back to it takes a minute, once the theme is ready.
- Restored the lost rule in the plugin that hides the addresses.
- Disabled automatic updates for Elementor specifically. Otherwise it would all have repeated overnight — WordPress does not remember that last time things got worse.
- Checked the home page and the inner pages — they load, no errors, the styling is in place.
And we told the owner honestly, separately: version 3.6.5 is four years old and should not be kept for long. Vulnerabilities turn up in old versions over time, and then not updating becomes the dangerous option. The newest version compatible with this theme is 3.25. But the theme is from 2022 too: sooner or later it will run into this again. The right path is to make a copy of the site and test the update there calmly, with no risk to the live one.
A second warning the next morning
At 9:49 a new message: «error 503» when saving a page. At first glance, a continuation of the night before. In fact a different story, and an instructive one too.
The server was not refusing requests. The PHP process itself was dying during the save, and the browser showed that as a 503. The page turned out to be very heavy: 226 blocks, 111 of them images. Meanwhile the PHP limits on the site were the bare hosting defaults: 128 MB of memory and 30 seconds per request. The page builder needs at least 256 MB and 300 seconds to work properly. The site had been running at the edge for years — and on the heaviest page that edge ran out.
We raised the limits and restarted PHP — it did not help. The log showed that memory and time had nothing to do with it: the process was dying on the save itself. The cause turned out to be one of the PHP acceleration settings, a known problem on that version. We switched it off and it worked.
The lesson here is simple: a failure rarely has a single cause. Yesterday's update had nothing to do with this one, but a site living on minimal limits for years will sooner or later break on something else.
What a site owner should do
- Find out what updates itself on your site. In the WordPress admin: «Plugins» → the «Automatic updates» column. The same for themes. If you do not know the answer, that is already the first problem.
- Split updates into «security» and «major». Small fixes inside a version (3.25.10 → 3.25.11) can stay automatic. A move between major versions (3 → 4) should be done by hand, and only after testing.
- Test major updates on a copy. Hosting providers usually offer a staging copy of the site at one click. Update there, check that nothing fell off, and only then update the live site.
- Make a copy before every update. Not «there is a backup on the hosting», but a copy you personally know how to restore from in ten minutes.
- Do not keep four-year-old versions. The longer you go without updating, the more painful the jump will be and the more vulnerabilities pile up. A scheduled monthly update is cheaper than one night without a site.
- Have somebody who will notice within five minutes. The site was down from 18:11 and the message arrived at 18:14 — and it was about the editor, not the site. Without monitoring, an owner learns about a dead site from a customer who could not place an order.
The paradox: not updating is dangerous too
It might seem the conclusion is «turn off automatic updates and sleep soundly». It is not. We recently wrote about the critical PHP vulnerabilities, where the only defence is precisely an update and delaying it is not an option. There, hesitating costs you a compromised server. Here, haste cost an evening without a site.
The difference is one thing: security updates should be installed fast and all of them, while functional ones should be deliberate and tested first. An automatic update does not see that difference. A person has to.
Not sure what updates itself on your site, or what will happen after the next update? Write to us — we will look at your site and tell you plainly where it is running at the edge.