WP Rocket has published a post-mortem explaining how the fatal error that crashed sites after WordPress 7.1 launched last week made it into a stable release, and how many sites it actually hit.

What happened

WP Rocket VP of Engineering Mathieu Lamiot wrote that the company now estimates about 27% of WP Rocket sites were at risk from the bug, and roughly 10% were actually impacted with fatal errors.

The root cause traces back to WP Rocket’s Cloudflare module, which ran on every request regardless of whether a site used Cloudflare. That module called a PHP function on WordPress hook callback IDs, expecting a text string. WordPress 7.1 changed how those IDs are generated, and sometimes returned a number instead. Under PHP 8’s strict typing rules, that mismatch crashed the site instead of just logging a warning, but only on sites also running specific plugins like Elementor Pro, Elementor Free, or Redirection for Contact Form 7.

The more uncomfortable finding is the timeline. Someone filed a GitHub bug report on July 6, six weeks before WordPress 7.1 shipped, and even included a suggested one-line fix. WP Rocket’s team reviewed it the same day but never assigned it to an owner. Automated tests couldn’t reproduce the issue, so the report dropped out of view. A couple of support tickets later hit the same fatal error but weren’t connected back to the original report.

The post-mortem also confirms the underlying WordPress 7.1 change was itself a breaking change for plugins that relied on the old ID format. WP Engine core committer Weston Ruter confirmed that on August 21, and a Trac ticket now has a proposed fix targeted for WordPress 7.1.1.

“This cost real time and real trust, and both matter to us,” Lamiot wrote. “We’re truly sorry for the outage, for the stress, and for the fact that it didn’t have to happen this way.”

What WP Rocket is changing

Lamiot said every GitHub report will now be assigned an owner instead of sitting in a queue. The team is rebuilding its compatibility test suite around the plugins and themes its users actually run, rather than the ad hoc list it grew over the years. And the Cloudflare module that caused the crash will now be gated so it only loads on sites that actually use Cloudflare.

What to do

If you update WP Rocket to version 3.23.2.2 or later, as covered in our original report, you’re already protected from this specific bug. Keep an eye out for WordPress 7.1.1, which is expected to fix the underlying core issue that caused the type mismatch in the first place.

End of article