I have a ritual for updating WordPress sites: staging first, backup second, update third, then I click through the site like a paranoid visitor before I call it done. Boring, slow — and it has saved me more times than I can count.
So when WordPress 7.1 shipped on August 19, 2026, at WordCamp US, and WP Rocket sites started white-screening within hours, my first reaction was sympathy. My second was a cold feeling in my stomach: the crash needed a third plugin to trigger it, and one of the plugins named was Elementor Pro — the plugin I use on nearly every site I build.
WP Rocket has since published its full post-mortem, and this week the WordPress community is still arguing about what it means. Here is what happened, and the practical lesson I took from it.
What actually happened on release day
WordPress 7.1 went live on August 19. Within hours, hosts started seeing PHP fatal errors on sites running WP Rocket. The sites did not degrade gracefully — they went white, and in some cases the admin area went down too.
The error signature was specific:
``
PHP Fatal error: Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given
It pointed at line 562 of WP Rocket's file — misleadingly named, since the bug had nothing to do with Cloudflare.
The cause: WordPress 7.1 changed how hook callback IDs are generated, so some became integers instead of strings. WP Rocket's code walked the $wp_filter['deleted_post'] registry and passed each key to substr(), which only accepts strings. Under PHP 8 with declare(strict_types=1), PHP refuses to quietly convert the integer — it throws a TypeError, and a TypeError in code that runs on every request is a dead site.
The fix was one line: cast the key to a string. WP Rocket shipped it as version 3.23.2.2 on August 20, a day after sites started falling over. Their status page records the incident opening at 05:44 UTC, the hotfix out at 08:14, and the incident closed at 10:15. Fast — once it started.
The part that should worry you: it needed a third plugin
This is the detail I keep coming back to, because it explains why nobody caught it — and why your own testing might not catch the next one either.
A clean WordPress 7.1 install with WP Rocket did not crash. The fatal only happened when a third plugin put integer keys onto the deleted_post hook. Elementor Pro did that. So did CF7 Redirection, and a couple of others. The moment one of those plugins was active alongside WP Rocket, the next request blew up.
That is why the bug sailed through testing. WP Rocket says it tested against 7.1 pre-release builds, and core's own tests passed. Everybody tested the combination they could see; the one that broke sites was a three-way interaction that only exists on real, lived-in websites.
Anchor Hosting published its own fleet numbers: 124 of 332 production WP Rocket sites went down — a 37 percent hit rate from a bug invisible in a default install. WP Rocket's own post-mortem puts it lower, around 27 percent of sites at risk and roughly 10 percent actually hit. Either way, this was not an edge case. It was a production-matrix bug, the kind that only shows up when software meets the messy reality of how people actually build sites.
If you build with Elementor, that should land personally: your stack is exactly the stack that broke. You did nothing wrong — you just had the popular combination.
The report that sat unread for six weeks
Here is the part that genuinely bothers me, and the reason this incident is still being talked about months later.
The bug was reported publicly on WP Rocket's GitHub repository on July 6, 2026, while WordPress 7.1 was still in beta. It was an unusually good report: it named the file and the line, explained that filter-registry keys can be integers because PHP casts numeric keys, and gave reproduction steps and a fix. The kind of report a maintainer dreams of receiving.
It was reviewed the same day it was filed — and then never assigned to an owner. It sat unactioned for six weeks while the beta became WordPress 7.1. Sites fell over on release day, and the 3.23.2.2 changelog credits that same July issue number as the thing it fixed.
WP Rocket has not been evasive about this. In the post-mortem published on August 26, VP of Engineering Mathieu Lamiot said the company's automated tests had grown "opportunistically, over years" rather than from a deliberate map of the plugins users actually run alongside WP Rocket. The test suite is now being rebuilt around the plugins and themes most commonly used with the product, and the company is running a post-mortem on how the July 6 report was triaged. To its credit, it owned the miss instead of blaming core, users, or hosts.
But there is a second half, and it belongs to WordPress core. The underlying change — hook callback IDs flipping from strings to integers — was itself a breaking change, which WP Engine-sponsored core committer Weston Ruter confirmed on August 21. It is tracked as core ticket 65919, with a fix slated for 7.1.1. Core changed a long-standing assumption, a plugin relied on it, and nobody's tests covered the seam between them.
Then the drama started, and it matters more than it looks
On August 21, Matt Mullenweg posted on his personal account: "Did your rocket explode? Get a Jetpack." The next day, the official WordPress account quoted WP Rocket's "don't update to 7.1" advisory, said the problem was not a 7.1 bug, and told people to consider dropping WP Rocket.
This matters practically: when the person controlling the official WordPress account uses a compatibility incident to sell a competing product, plugin companies get more defensive, hosts get quieter, and users get caught in the middle, unsure whether the advice is technical guidance or marketing.
The Repository's issue this week put it bluntly: the fallout became a story about hosts as much as the plugin. Its argument is that no web host tested the next WordPress core against real plugin stacks before it shipped — and if one had, somebody would have filed this bug before release day. Anchor Hosting's author patched the plugin, got every customer back online, and then asked why no other host caught it first. Not the big hosts. Not the small ones. None of them.
Nobody was probing core updates against live plugin stacks. The safety net we all assume exists — that somebody, somewhere, tests the new WordPress against the plugins everyone actually uses — did not exist for this release. Your site is your own safety net. Act like it.
What I am doing differently now
I am not telling you to drop WP Rocket — I still think it is a good plugin, and its post-mortem is more honest than most companies manage. But the incident exposed four habits worth changing, and I have changed all four.
First, I never update core and plugins in the same session anymore. I update core, check the site, then update plugins separately. When two things change at once and the site breaks, you have no idea which one did it.
Second, my staging site now mirrors my plugin stack, not a clean install. A staging site with three plugins proves nothing about a production site with thirty. The WP Rocket bug only existed in the combination, so my testing has to happen in the combination too.
Third, I check the fatal error log after every update. The WP Rocket error was loud and specific — substr(), Cloudflare.php, line 562. Reading your PHP error log takes you from "my site is down and I have no idea why" to "I know exactly which file" in about thirty seconds.
Fourth, I wait 48 hours on major core releases for client sites. A security release like WordPress 7.1.4 is different — that one I install quickly. But a major version can wait two days while the early reports come in. The WP Rocket hotfix landed within a day; waiting 48 hours would have meant skipping the incident entirely.
The fix, and the one loose end
If you were affected and never finished cleaning up: update WP Rocket to 3.23.2.2 or later — the permanent fix. Skip the manual code edits that circulated on August 19 and 20; a hand-edited plugin file gets overwritten on the next update anyway. A separate customer notice on August 28 recommends 3.23.3.3 and precautionary replacement of Cloudflare or Sucuri API keys configured in WP Rocket. There were no reports of exposure, so it is a precaution, not a confirmed breach — but rotate the keys if you use those integrations.
The remaining loose end is core's side: ticket 65919, with the fix planned for WordPress 7.1.1. Until that ships, the underlying type inconsistency is still in core, and any other plugin making the same assumption is one bad combination away from the same crash. That is a reason to keep the four habits above, not a reason to panic.
Conclusion
I like WP Rocket's post-mortem because it says the quiet part out loud: its tests grew opportunistically, the bug report sat without an owner for six weeks, and roughly one in ten of its sites went down because of it. Honest accountings are how an ecosystem gets better.
But the bigger lesson is not about WP Rocket. It is that the WordPress ecosystem's safety net is thinner than most of us assumed. Core changed a type. A plugin assumed the old type. The report naming the exact problem sat unread. No host tested the combination. And the plugin that exposed the crash for so many sites was Elementor Pro — the tool half of us build with every single day.
So test your real stack, not a clean install. Update one thing at a time. Read your error log. And give a major release 48 hours before you put it on a client site. It is the advice that keeps your site online while everyone else reads a post-mortem about why theirs went down.
FAQ
Was the WP Rocket crash a WordPress 7.1 bug or a WP Rocket bug?
Both. WordPress 7.1 changed hook callback IDs from strings to integers, and WP Rocket's code assumed the keys would always be strings. Core's fix is slated for 7.1.1 (ticket 65919); WP Rocket fixed its side in 3.23.2.2.
Did Elementor cause the crash?
No. Elementor Pro put integer keys on the deleted_post hook, which exposed the bug — but the bug itself was in WP Rocket's code and in core's type change. Elementor was doing nothing wrong; the fatal needed the combination.
Which WP Rocket version fixes the fatal error?
Version 3.23.2.2, released on August 20, 2026. A later notice from August 28 recommends 3.23.3.3, plus rotating Cloudflare or Sucuri API keys as a precaution. Update through the normal licensed path.
How do I know if my site was affected?
Check your PHP error log for Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given pointing at WP Rocket's Cloudflare.php` around line 562. A white screen right after updating to WordPress 7.1 with WP Rocket active points to this incident.Should I still use WP Rocket?
I would. The post-mortem was unusually honest, the fix shipped within a day, and the company is rebuilding its test suite around the plugins people actually run. It is a reason to test updates properly, not to abandon a good caching plugin.
What should I do before the next major WordPress update?
Test on staging with your full plugin stack active, update core and plugins separately, back up first, and wait about 48 hours after a major release. Read the PHP error log after every update.
