At about 8:00 Thursday morning, the first client text came in.
Their website was down.
Not slow. Not displaying something weird on an iPhone. Down-down.
The kind of message that has you reaching for coffee with one hand and opening ManageWP with the other.
We logged in, started looking around, and pretty quickly realized we had a bigger problem. More sites were dropping offline. ManageWP was showing disconnected websites. And as we started comparing them, one thing kept showing up.
WP Rocket.
WP Rocket is the performance and caching plugin we use on a large percentage of the WordPress websites we manage. It’s reliable, we’ve used it for years, and we know it well.
Which is why, when something goes wrong with it, we notice.
Especially when it happens to almost 60 websites at once.
WordPress 7.1 had been released the day before, and automatic updates were beginning to roll through websites overnight.
On the affected sites, we kept finding the same fatal PHP error pointing back to WP Rocket. More specifically, the error was coming from WP Rocket’s Cloudflare integration code.
That sent us down a short-lived Cloudflare rabbit hole.
Except some of the broken websites weren’t using Cloudflare.
Different hosts. Different configurations. Some behind Cloudflare, some not.
Same error.
The common denominator was WordPress 7.1 and an older version of WP Rocket.
WP Rocket confirmed the compatibility problem and released version 3.23.2.2 to fix it. Their WordPress 7.1 fatal-error advisory documents the issue, and you can find the fix in the WP Rocket changelog.
If PHP fatal errors are your preferred reading material with your morning coffee, have at it.
We had websites to fix.
The immediate fix was pretty straightforward.
The problem was that on some sites, WP Rocket wasn’t just breaking the front end. It was taking down wp-admin, too.
So we couldn’t simply log into WordPress and deactivate the plugin.
We had to go around WordPress.
For the affected sites, we logged into the hosting account, opened File Manager, went to /wp-content/plugins/, and renamed the wp-rocket folder.
That forced WordPress to deactivate the plugin without requiring access to the dashboard.
And just like that, the site came back.
Once we could get into wp-admin again, we deleted the old version of WP Rocket, installed the corrected version, activated it, and checked the site.
Fortunately, WP Rocket stores its settings in the WordPress database, so replacing the plugin didn’t mean rebuilding the configuration from scratch.
One down.
Then another.
And another.
By about 8:30, we could tell the first client their website was fixed.
Unfortunately, our Thursday morning was just getting started.
About 80 percent of the affected websites are hosted on our own managed servers, which made things considerably easier.
We could work through WHM, jump into each account, get to File Manager, disable WP Rocket, restore access, install the fixed version, and move on.
The other 20 percent were scattered across individual hosting companies.
That meant separate control panels. Separate passwords. Two-factor authentication. Finding out who had the code. Finding out where someone put the code. Finding out that the person who used to get the code hasn’t worked there since 2023.
You know. The glamorous side of web design.
But the repair itself remained consistent:
We have a simple rule with maintenance: if we’re already inside a website fixing something, we don’t ignore the other warning lights on the dashboard.
That doesn’t mean clicking “update everything” and hoping for the best.
We confirm there’s a good backup. If there isn’t, we make one. Then we take care of whatever can safely be handled and leave the website in better shape than we found it.
Fixing the broken websites was only half the job.
We also had websites that hadn’t updated to WordPress 7.1 yet.
Those were next.
By then, WP Rocket had released the corrected version. So instead of waiting for another round of WordPress automatic updates to knock more sites offline, we used ManageWP to identify websites still running the vulnerable WP Rocket version and update them first.
That changed the morning from purely reactive to preventative.
Some websites needed to be repaired.
The rest needed to be kept from breaking in the first place.
Both are website maintenance.
Most website maintenance is wonderfully boring.
Backups happen. Plugins get updated. WordPress gets updated. Security scans run. We check things. We fix little problems before they become big ones.
And most of the time, our clients never hear about any of it.
That’s kind of the point.
Then you get a Thursday morning like this one.
WordPress itself wasn’t broken. WordPress 7.1 exposed a compatibility problem in an older version of a widely used plugin. WP Rocket found the issue, got a fix out quickly, and published instructions for recovering affected websites.
This stuff happens.
WordPress websites are made up of a lot of moving pieces: WordPress core, themes, plugins, PHP, hosting environments, caching systems, CDNs, security tools and third-party services.
Usually, everybody gets along.
Occasionally, somebody flips the breakfast table.
What matters then is how quickly you can figure out who did it and put everything back together.
There’s another lesson from that morning that has nothing to do with PHP.
Know where your website lives.
Know where your domain is registered. Know who hosts the site. Know who controls your DNS. Know how to get into WordPress.
And most importantly, make sure somebody has access to all of it.
Because when WordPress is working, nearly everything can be handled from inside the dashboard.
When WordPress itself becomes inaccessible, those other credentials become your way back in.
For a business website, someone should have current access to:
You may never personally need to open File Manager and rename a plugin folder before you’ve finished your first cup of coffee.
We sincerely hope you don’t.
But somebody should be able to.
By lunchtime, most of the affected sites were back online. The corrected version of WP Rocket was installed, and we were already working through the remaining managed sites to update them before they could encounter the same problem.
And our clients went back to running their businesses.
That’s really what website maintenance is supposed to do.
It’s not a promise that nothing will ever break. Anyone who manages WordPress websites long enough knows better than to make that promise.
It’s backups. Monitoring. Updates. Access. Experience. And having someone paying attention when 60 websites suddenly decide they don’t want to participate in Thursday anymore.
Most days, website maintenance isn’t particularly exciting.
That’s exactly how we like it.
But on the mornings when something does go wrong, having someone who knows your website—and knows what to do next—makes all the difference.
If you’re not sure who’s keeping an eye on your WordPress site, we should probably talk.
A Practical Guide to Budgeting for SEO, Google Ads, Websites & Lead Generation Estimated reading…
Building a Digital Home for a Working Railroad in Northern Arizona At Cider House, we’ve…
If you run a small business in Western Massachusetts, your WordPress site is not just…
When a pipe bursts in Forest Park at 10:30 p.m., nobody sits down to savor…
Matching Site Scope to the Size of Your Business Not every small business in Western…
We launched Hurricane Tax Prep! Some businesses expand because of market opportunity. Others expand because…