Introduction: the morning a routine update took sites down
I have updated WordPress sites hundreds of times, and most of those updates are gloriously boring. You click update, the progress bar finishes, the site loads, and you move on with your day. August 20, 2026 was not one of those days. WordPress 7.1 went out, and within hours, sites running WP Rocket started going down with a fatal error. Some owners lost their front end entirely, and their visitors saw nothing but a white screen and a 500 error.
I run Elementor sites for clients, so this one hit close to home. When I read WP Rocket's post-mortem, published on August 26 by their VP of Engineering, Mathieu Lamiot, I found something rarer than a bug report: an honest account of what broke, why nobody caught it, and what changes now. The Repository revisited the story in its Issue #317 this week, and it is still worth sitting with: the same ingredients — a major core release, a popular caching plugin, PHP 8, and Elementor Pro — sit on millions of sites right now.
What happened on August 20
WordPress 7.1 was released on August 19, 2026, and officially out in the early hours of August 20. Almost immediately, support tickets started coming in. Sites running WP Rocket were returning fatal errors, and the error message pointed at a PHP function most site owners had never heard of: substr().
WP Rocket moved fast: they shipped 3.23.2.2 the same day and emailed every active customer, recommending they update WP Rocket before updating to WordPress 7.1. But by then, the damage was done for a meaningful slice of their user base, and the post-mortem they published six days later is unusually candid about whose fault it was. "This was our fault, because we didn't take action on time," Lamiot wrote. You do not often see a plugin company say that in public.
What actually broke: a string that became an integer
Here is the technical core of the story, explained the way I would explain it to a client. WP Rocket includes a small module that talks to Cloudflare. That module is active whether or not you actually use Cloudflare, which matters, because it means the bug could bite sites that had never touched a Cloudflare setting in their lives.
As part of its cleanup routine, that module calls a PHP function called substr() on the ID WordPress generates for callbacks on two specific hooks. Before WordPress 7.1, that ID was always a string, and substr() was perfectly happy. But WordPress 7.1 changed how those callback IDs are built, and under specific conditions the ID can now come back as an integer instead of a string. PHP 8 enforces strict typing, so passing an integer into substr() where a string is expected does not quietly continue. It throws a fatal error, and a fatal error in the wrong place takes the whole front end down with it.
The fix, when it came, was almost comically small: a cast, substr( (string) $key, ... ). One line. A single type cast separated a normal update day from an outage.
Why Elementor Pro was in the blast radius
A clean WordPress 7.1 site with WP Rocket did not crash. The fatal error needed a third ingredient: another plugin registering callbacks on those hooks in a specific way. WP Rocket went through the 200 most used plugins on WordPress.org, user reports, and public GitHub activity to identify exactly which ones triggered it, and the list reads like a tour of the average Elementor site.
Elementor Pro triggers the issue as soon as the user has a valid license and the plugin is activated. Elementor Free triggers it too, if the experimental e_atomic_elements setting is active. Redirection for Contact Form 7 triggers it as soon as the plugin is activated. WP Rocket estimated that around 27 percent of its sites were at risk and roughly 10 percent were actually impacted. One host, Anchor Hosting, reported 124 of its 332 production WP Rocket sites went down, a 37 percent hit rate. Every fatal error was the same line, the same file, the same cause. The post-mortem also confirmed something that should make every plugin developer pause: Elementor Pro, despite its massive install base and its role as one of the plugins that triggered the crash, was not on WP Rocket's compatibility testing list. Their automated tests had grown, in Lamiot's words, "opportunistically, over years," rather than from a deliberate map of the plugins users actually run.
The part that stings: the bug was reported six weeks early
Here is the detail that turns this from an unlucky accident into a cautionary tale. The bug was first reported to WP Rocket on July 6, while WordPress 7.1 was still in development. A user testing against the WordPress 7.1 alpha opened a GitHub issue, and the report even suggested a fix. It was reviewed the same day it was filed, and then it was never assigned to an owner. After QA could not reproduce the issue in automated tests, the report dropped out of view. Six weeks later, it shipped to production.
I have seen this exact failure mode inside agencies and product teams, and it is never about laziness. It is about a report that does not reproduce in the test environment, because the test environment is a clean install and the bug only appears with a real site's plugin stack. A clean WordPress 7.1 site with WP Rocket did not crash, so QA's tests passed, and the report quietly died. The lesson is not that WP Rocket's engineers were careless. It is that a test suite built around a default install cannot catch bugs that only exist in the combinations real users run.
What the fix looks like, and where things stand now
The immediate fix was WP Rocket 3.23.2.2, shipped on August 20 and validated through automated tests and targeted manual testing. The underlying core change is being addressed in WordPress itself, with a fix ticketed for WordPress 7.1.1 — core maintainer Weston Ruter confirmed the core change was itself a breaking one on August 21. Since then, the 7.1 branch has moved on: WordPress 7.1.4 shipped on October 30 as a security release, and the current branch is the one your sites should be running today.
If your site runs WP Rocket and Elementor Pro together, the practical question is simple: are you on WP Rocket 3.23.2.2 or newer, and are you on a current WordPress 7.1.x release? If the answer to either question is no, stop reading and go and check.
My safe-update checklist for Elementor sites
I have changed how I handle major WordPress updates since this incident. This is the checklist I now follow on every client site — it takes about twenty minutes, and it is cheaper than a morning of downtime.
First, take a full backup before you touch anything, and confirm you can actually restore it. A backup you have never restored is a hope, not a safety net. I test restores on staging at least once per project, because the day you discover a backup is corrupt should never be the day your site is down.
Second, update the plugins before you update core. WP Rocket told its customers exactly this: update WP Rocket first, then move to WordPress 7.1. Plugin authors ship compatibility fixes ahead of major core releases, and those fixes only help if they are installed before core changes underneath them. I update in this order now: backup, then plugins, then theme, then core, checking the front end after each step.
Third, never run a major core update on a live site first. Clone the site to staging with the real plugin stack — Elementor Pro, WP Rocket, the contact form plugin, all of it — and run the update there. The WP Rocket bug only appeared with the real stack present, and staging that mirrors production is the only way to catch that class of problem.
Fourth, check your PHP version and your error logs. This bug lived at the intersection of PHP 8 strict typing and a core change, and PHP 8 is now the standard. After any update, I check the PHP error log within the first hour, because a fatal error often shows up there before a client calls you about it.
Fifth, turn off automatic major updates and update on your own schedule. Automatic updates are fine for minor security releases, but a major version like 7.1 deserves a human in the loop, a backup, and a staging test. I schedule major updates for a quiet morning, never on a Friday afternoon and never right before a launch or a campaign.
Sixth, watch the news for the first forty-eight hours after a major release. Problems like this one surface within hours on the support forums, in newsletters like The Repository and WP Weekly, and on the plugin authors' own blogs. A two-day wait on a major release costs nothing and buys you everyone else's bug reports for free.
Conclusion: one line of code, and a better process
The WordPress 7.1 outage was caused by a one-line type error, reported six weeks before release, missed because it only appeared in the plugin combinations real sites actually run, and fixed with a single cast to string. Roughly one in ten WP Rocket sites was hit, and more than one in three on at least one host. Nobody involved was careless in the way people usually mean that word. The tests passed. The report was reviewed. The release went out on schedule. And sites still went down.
That is why I keep this story pinned to my own workflow instead of filing it under old news. The fix for the bug was one line, but the fix for the process is a checklist: back up, update plugins first, test on staging with the real stack, check the logs, and never let a major release update itself. I like both of these products, but liking your tools is not a testing strategy. Run the update on staging first, and the next one-line bug will be someone else's outage, not yours.
Frequently Asked Questions
What caused the WordPress 7.1 outage?
WordPress 7.1 changed how hook callback IDs are built, so an ID that was always a string could now come back as an integer. WP Rocket's Cloudflare module passed that ID into PHP's substr() function, and under PHP 8's strict typing that throws a fatal error, taking the site's front end down.
Which plugins triggered the fatal error?
The crash needed WordPress 7.1, PHP 8, WP Rocket, and at least one other plugin registering callbacks in a specific way. WP Rocket confirmed Elementor Pro with an active license, Elementor Free with the experimental e_atomic_elements setting enabled, and Redirection for Contact Form 7 as triggers.
How many sites were affected?
WP Rocket estimated around 27 percent of its sites were at risk and roughly 10 percent were actually impacted. One host, Anchor Hosting, reported 124 of its 332 production WP Rocket sites went down, a 37 percent hit rate.
Was the bug known before WordPress 7.1 was released?
Yes. A user reported it on GitHub on July 6, while WordPress 7.1 was still in development, and the report suggested a fix. It was reviewed the same day but never assigned to an owner, and QA could not reproduce it in automated tests because a clean install without the triggering plugins did not crash.
What is the fix, and am I safe now?
WP Rocket shipped the fix as version 3.23.2.2 on August 20, 2026, and the core change has a fix ticketed for WordPress 7.1.1. Run WP Rocket 3.23.2.2 or newer on a current WordPress 7.1.x release and you are protected against this specific issue.
Should I still update WordPress promptly, or wait after major releases?
Install minor security releases promptly, but give major releases a short pause. Back up first, update plugins before core, test the update on a staging copy with your real plugin stack, and check the error logs afterwards. A two-day wait on a major release costs nothing and lets the community surface problems first.
