WordPress 7.1 Broke WP Rocket. Here Is the Fix If Your Site Is Down

WordPress 7.1 went out on August 19, 2026, and within hours, sites running WP Rocket for caching started going down with a fatal error. If you use WP Rocket and you have not touched WordPress core since then, I would read this before you do anything else, not after.

What actually happened

The crash comes from WP Rocket's Cloudflare compatibility module, specifically a line that passes a value into PHP's substr() function expecting a string. WordPress 7.1 changed something upstream that could cause an integer to reach that same line instead. PHP 8 enforces strict typing, so instead of quietly working anyway the way older PHP might have, it throws a fatal TypeError and takes the whole request down with it. That includes your homepage, your wp-admin dashboard, and your REST API, all at once.

Here is the detail that catches people off guard. You do not need to actually use Cloudflare, or even have a Cloudflare plugin installed, to be affected. WP Rocket's Cloudflare compatibility code runs on every request regardless, so this can hit a site that has never touched Cloudflare in any way.

Who is actually at risk

Three things need to be true at once for this to bite you. You are running WordPress 7.1. Your WP Rocket version is 3.23.2.1 or earlier, which covers most installs going back to roughly version 3.16. And you have some plugin or theme hooking a closure onto either the deleted_post action at priority 10, or transition_post_status at the highest possible priority. Elementor Pro is one commonly cited example that triggers this combination, but it is not the only plugin capable of doing so.

Being fully updated on release day did not protect anyone here, since the bug was already present in the WP Rocket version most people were running at the time.

The fix

Update WP Rocket to version 3.23.2.2 or later. WP Media shipped this the day after the outage, and the changelog entry for it reads plainly, "Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations."

The catch: if your site is already down, you cannot just click update

This is the part that matters most if you are dealing with this right now instead of reading ahead of time. A site stuck in this fatal error state cannot load wp-admin at all, which means the normal "update plugin" button is not reachable. You need FTP or SSH access instead.

Connect to your server and rename the WP Rocket plugin folder, so WordPress stops trying to load it.

mv wp-content/plugins/wp-rocket wp-content/plugins/wp-rocket-off

That alone should bring your site back up, since WordPress treats a renamed plugin folder as effectively deactivated. Once you can reach wp-admin again, rename the folder back to its original name, then update WP Rocket normally through the dashboard, or by re-uploading a current copy of the plugin directly.

Why WP Rocket's own tests missed this

I think the honest part of this story is more useful than the bug itself. WP Rocket published a post-mortem admitting their automated compatibility suite tests against a fixed list of plugins and themes, and that list, in their own VP of Engineering's words, grew "opportunistically, over years" rather than from a deliberate map of what their users actually run. Elementor Pro, despite an enormous install base, was not on that list. WP Rocket estimates roughly 10 percent of its user base was actually impacted.

There is a second detail worth knowing if you maintain any plugin or theme of your own, even a small one for client work. The bug had already been reported on WP Rocket's GitHub repository on July 6, six weeks before the WordPress 7.1 release, with a working one-line fix included in the report. It sat there unreviewed until after real sites started going down. A quiet bug report with a working fix attached is exactly the kind of thing worth checking before a major WordPress release, not scrambling to find after one.

FAQ

Do I need to have Elementor Pro installed to be at risk?
No. Elementor Pro is one confirmed trigger, but the underlying cause is any plugin or theme hooking those specific actions at those specific priorities, so other plugins can cause the same crash.

Is this actually a Cloudflare problem?
No, and I want to be clear about that, since the error message references Cloudflare.php. This is WP Rocket's own internal compatibility code, not an actual Cloudflare service issue. Your Cloudflare account, if you have one, is not involved at all.

Should I hold off updating to WordPress 7.1 until I check WP Rocket?
If you have not upgraded yet, update WP Rocket to 3.23.2.2 or later first, then move to WordPress 7.1. That order avoids the problem entirely instead of needing to recover from it.

What if I do not have FTP or SSH access to my server?
Check whether your hosting provider offers a file manager through their control panel, which can usually rename a plugin folder the same way FTP can. If neither option is available, you would need to contact your host directly for help restoring access.

Does this affect every WP Rocket site running WordPress 7.1?
No, only sites meeting all three conditions above at once. A site on an already-updated WP Rocket version, or one without a plugin hooking those specific actions, would not hit this particular crash.

Bottom line

If you run WP Rocket, update to 3.23.2.2 or later before you touch WordPress 7.1, not after. If your site is already down, the fix is a plugin folder rename over FTP, not a dashboard click you cannot reach. And if you maintain your own plugin or theme, a six-week-old bug report with a working fix attached is worth reviewing before your next major compatibility test, not after users start filing tickets.

Sources: WP Rocket Knowledge Base, Fatal error on WordPress 7.1; WP Rocket, The WordPress 7.1 Outage: What Went Wrong, and What Changes Now. Verified against WP Rocket's own documentation and post-mortem on August 30, 2026.