WP Rocket incompatibility with WordPress 7.1: update WP Rocket first

The short version

WordPress 7.1 and older WP Rocket releases can be a bad combination. On affected sites, a normal request can reach WP Rocket's Cloudflare compatibility code and stop on this error:

TypeError: substr(): Argument #1 ($string) must be of type string, int given
wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562

That is not a warning tucked away in a log while the site carries on. It is a fatal error. Depending on where it fires, visitors can see the WordPress critical error screen and you can lose access to wp-admin.

WP Rocket released version 3.23.2.2 on 20 August and confirmed publicly that the fix is live. Treat that as the minimum version before you even consider the WordPress 7.1 update. If the fixed build is not available in your WP Rocket account or WordPress updater yet, wait. WordPress 7.1 can wait too.

What causes the WP Rocket incompatibility

The crash sits in WP Rocket's Cloudflare integration code, but this is the slightly confusing bit: you do not need the separate Cloudflare plugin installed for it to happen. The original report reproduced the error without it.

In plain English, WP Rocket looks through a list of WordPress callbacks and checks the end of each callback ID with PHP's substr() function. The code expects every ID to be text. Under the conditions reported with WordPress 7.1, one of those IDs can arrive as an integer instead. PHP 8 refuses to treat that integer as a string automatically, so it throws a TypeError and stops the request.

The actual code correction is tiny: cast the value to a string before passing it to substr(). The impact is not tiny. A single missing type cast can turn a routine core update into a dead site.

This fatal bug was reported more than a month before release

This was not discovered for the first time after thousands of people clicked Update. The public WP Rocket bug report was opened on 6 July 2026. It included the fatal error, the file and line number, reproduction steps, and the one-line type cast needed to prevent it. WP Rocket's own repository labelled it critical.

For context, WordPress 7.1 Beta 1 did not arrive until 15 July. The first release candidate followed on 5 August, with the final release scheduled for 19 August. The issue was therefore known before the public beta cycle even began and more than six weeks before the final release.

That is the uncomfortable part. Pre-release versions exist so plugin authors can catch exactly this sort of breakage. Here, somebody else had already caught it, documented it, and supplied the shape of the fix. Letting a critical compatibility bug reach release day anyway is hard to defend.

Who should not update to WordPress 7.1

If your site has WP Rocket active and the installed version is older than 3.23.2.2, do not update WordPress to 7.1. That includes sites where Cloudflare is not installed and sites where WP Rocket's Cloudflare add-on is not something you remember configuring.

You may see another site with the same versions update cleanly. That does not prove yours will. The fatal depends on the callbacks registered by the site's particular mix of plugins and theme. Two outwardly similar sites can behave differently.

Our advice is simple:

1. Stay on your current WordPress release for now.
2. Take a fresh, restorable backup of files and the database.
3. Update WP Rocket to 3.23.2.2 or later before WordPress itself.
4. Clone the site to staging and update the staging copy to WordPress 7.1.
5. Check the front end, wp-admin, publishing, cache clearing, forms, checkout, and scheduled jobs.
6. Only update production after those checks pass.

If you do not have a safe place to test, our guide explains how to create a WordPress staging site. Our safe plugin update checklist covers the same backup, test, verify routine for everyday updates.

Is Elementor affected too?

We have not found evidence of a separate Elementor fatal error caused by WordPress 7.1 in this incident. That distinction matters. An Elementor site running an affected WP Rocket version can still go down, but the fatal stack trace points to WP Rocket, not Elementor.

The WP Rocket fix and regression test describe the trigger as a plugin, theme, or custom code registering a Closure or invokable object on eitherdeleted_post or transition_post_status. They do not name Elementor. Elementor does use post lifecycle hooks, but that fact alone is not enough to reproduce the crash. The specific callback shape matters, and we have not found a reproducible report that ties Elementor to it.

So the honest answer is: Elementor is not confirmed as the cause, and we would not deactivate it on a guess. If your Elementor site shows the exact Cloudflare.php and substr() error above, update or disable WP Rocket first. If the stack trace names Elementor or Elementor Pro instead, treat that as a different compatibility problem and investigate it separately.

Already updated and staring at a critical error?

Do not keep refreshing and hoping the cache sorts itself out. If the error containswp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php and substr(), disable WP Rocket first so WordPress can load again.

1. Open your hosting file manager, SFTP, or SSH and go to wp-content/plugins.
2. Rename the wp-rocket directory to wp-rocket-disabled. WordPress will no longer be able to load that copy of the plugin.
3. Reload the site and wp-admin. Take a backup before making the next change.
4. Download WP Rocket 3.23.2.2 or later from your legitimate WP Rocket account and replace the old plugin copy. Do not download a premium plugin ZIP from an unofficial mirror.
5. Reactivate WP Rocket, clear its cache, and check both logged-in and logged-out pages.

If you are not comfortable working in the plugins directory, stop after the backup and ask your host or a developer to handle it. The longer walkthrough for regaining access is in deactivating a WordPress plugin without wp-admin. If the error is different, use the broader WordPress critical error guide instead of assuming WP Rocket is the cause.

Do not edit the WP Rocket file as the first fix

Yes, the public report shows a one-line change. No, that does not make editing a live premium plugin the best first move for most site owners. A typo can trade one fatal error for another, and the next plugin update can overwrite the manual edit without warning.

Recover access by disabling the broken plugin copy, then install the vendor's fixed release. A manual patch can be a short emergency bridge for a developer who understands the code and has a backup. It should not become the permanent version running your site.

What this says about WordPress update day

The lesson is not “never update WordPress.” Staying on an old core version forever creates its own security and compatibility problems. The lesson is that release day is a poor time to discover whether a commercial plugin tested the same combination you run in production.

A backup gives you a way back. Staging shows you the break before customers do. Monitoring tells you if the live site stops answering after the change. Those are separate jobs, and you want all three. BugShield's managed backups, uptime monitoring, and managed WordPress updates are built around that reality.

For today, the action is much simpler: if WP Rocket is active, do not update to WordPress 7.1 until WP Rocket 3.23.2.2 or later is installed and the combination has passed on staging. Being one day late to a feature release is better than being first to a fatal error.