Skip to content

Blog · August 20, 2026

Fatal Error After WordPress 7.1: How to Fix the WP Rocket Crash

WordPress 7.1 is crashing websites running WP Rocket with a fatal error. Root cause, the quick fix (update to 3.23.2.2), and how to get back into your admin.

Fatal Error After WordPress 7.1: How to Fix the WP Rocket Crash

Fatal Error After Updating to WordPress 7.1: WP Rocket Is Currently Taking Thousands of Websites Down

Since August 19, 2026, I've been receiving a striking number of emergency calls with the same symptoms: after updating to WordPress 7.1, the website only shows a white screen or the message "There has been a critical error on this website" — and the admin area is unreachable as well. In almost every case, the trigger is the same: an incompatibility between WordPress 7.1 and the caching plugin WP Rocket. The good news: the bug is known, the vendor has already responded, and your website can be back online within minutes. Here's how, step by step.

What happened?

If you install WordPress 7.1 while WP Rocket is active, you will typically find this line in your server logs (or in the error email WordPress sends out):

Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given in …/wp-content/plugins/wp-rocket/…/Cloudflare.php:562

The error occurs in WP Rocket's Cloudflare add-on — regardless of whether you actually use Cloudflare, because the affected file is executed whenever the plugin loads. WP Media, the company behind WP Rocket, confirmed the issue the same day in their official knowledge base; on GitHub it is tracked as issue #8596.

The root cause in a nutshell

Technically, it's a classic of the PHP 8 era: in one place, WordPress 7.1 now returns array keys as integers where WP Rocket had always expected strings. The affected function passes the key straight to substr() — and since PHP 8, that no longer produces a warning but a fatal TypeError. The result: the entire site aborts on load, front end and back end alike.

The quick fix: update WP Rocket to version 3.23.2.2

WP Media has already shipped a hotfix with WP Rocket 3.23.2.2 (see the changelog). If you can still reach your WordPress admin, this takes two minutes:

  1. Log in to your WordPress admin area.
  2. Go to Dashboard → Updates (or Plugins → Installed Plugins).
  3. Update WP Rocket to 3.23.2.2 or newer.
  4. Clear the cache once afterwards (WP Rocket → "Clear cache").

Locked out? How to get back into WordPress

For many affected sites, /wp-admin is unreachable too. In that case, three routes lead back in:

  • Recovery mode: On critical errors, WordPress automatically sends an email to the admin address ("Your site is experiencing a technical issue"). The link inside opens the admin area in recovery mode — where you can update or deactivate WP Rocket.
  • Via (S)FTP or your host's file manager: Temporarily rename the folder wp-content/plugins/wp-rocket (e.g. to wp-rocket_off). That deactivates the plugin and brings the site straight back up. Then install the update in the admin area and restore the folder name or reactivate the plugin.
  • Via WP-CLI (if you have SSH access): wp plugin update wp-rocket — done.

If you can't update right away: the official workarounds

For cases where a plugin update isn't immediately possible, WP Media lists two interim solutions in their knowledge base:

  • Helper file as a must-use plugin: WP Media provides a small helper file (wp-rocket-cloudflare-intkey-fix.php) that you upload via SFTP or file manager into wp-content/mu-plugins/. It catches the error immediately and can simply be deleted again once you've updated to the fixed version.
  • Manual code edit: If you're comfortable with PHP, you can add an is_string() check to the key handling in the affected file. I only recommend this to experienced users — and strictly as a stopgap, since the change will be overwritten by the next plugin update anyway.

And if all else fails: leave WP Rocket deactivated for now. Your website will run without a caching plugin — slower, but stable — until the update is in place.

How to avoid outages like this in the future

This incident shows once again why I never install core updates — especially major releases like 7.0 or 7.1 — on a live site untested. Three rules that have proven themselves with my clients:

  • Updates go to staging first: Every new WordPress version is tested on a copy of the website first. Bugs like this one surface there before real visitors ever see them.
  • Don't install major releases on day one: Waiting a few days costs nothing — plugin vendors typically ship compatibility fixes within the first days.
  • Backups and monitoring: A current backup plus uptime monitoring turn an outage of days into one of minutes.

That is exactly the core of my WordPress support service: I test every update on a staging copy of your site first and only push it live once theme and plugins have proven to keep up.

Conclusion

The fatal error after the WordPress 7.1 update is annoying but harmless and quickly fixed: update WP Rocket to 3.23.2.2 — via recovery mode or FTP if necessary — and your site is back. Your content and data are never at risk at any point.

Is your website showing the critical error right now and you'd rather not touch it yourself? Get in touch with me — I'm available on short notice and usually get affected sites back online the same day.