WordPress 7.1 exposed a WP Rocket bug in some Cloudflare configurations. The related log points to Cloudflare.php and a substr TypeError because a value expected to be a string arrived as an integer. WP Rocket states that version 3.23.2.2 fixes the problem. A site can lose both the public frontend and wp-admin, so the first goal is to regain control without deleting evidence or changing several systems at once. After recovery, the update still needs a short compatibility test because stale page cache, opcode cache, CDN cache, or a renamed plugin folder can make an already fixed site look broken.
Use this when a WordPress 7.1 update is followed by a critical error, white screen, inaccessible wp-admin, or a PHP log mentioning WP Rocket Cloudflare.php and substr().
Quick answer
If wp-admin works, deactivate WP Rocket, update it to 3.23.2.2 or newer, clear all cache layers, reactivate it, and test the public site. If wp-admin is unavailable, rename the wp-rocket plugin directory by SFTP or the hosting file manager, regain access, restore the official folder name, install the current package, and then reactivate. Preserve the original PHP error and plugin version before changing files. Do not leave a hand-edited vendor file as the permanent fix when the official release is available.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Backend available | Deactivate in Plugins | Update completes before reactivation |
| Backend unavailable | Rename plugin folder | wp-admin access returns |
| Cloudflare enabled | Purge and public request | No Cloudflare.php TypeError |
| Rollback | Known package and backup | Site can recover without data loss |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Preserve the error and availability map | Capture the exact PHP fatal line, WordPress version, WP Rocket version, plugin directory name, Cloudflare add-on state, and time the failure began. | WP Rocket reports version 3.23.2.2 or newer and the official plugin directory name. |
| Deactivate WP Rocket through the safest available path | Confirm whether the frontend, wp-admin, WP-CLI, hosting file manager, SFTP, and recovery email each remain available before selecting the least disruptive recovery path. | Frontend, wp-admin, login, and critical forms or checkout load without a new fatal error. |
| Restore the official folder name and update to 3.23.2.2 or newer | Deactivate WP Rocket without deleting its directory, verify that wp-admin and a public uncached URL recover, then install version 3.23.2.2 or newer from the licensed package. | Cloudflare purge and cache headers behave as expected after reactivation. |
| Clear origin, opcode, CDN, and browser cache | Clear WP Rocket, origin page cache, PHP opcode cache when available, Cloudflare cache, and browser cache in a controlled order so an old fatal response is not mistaken for a current failure. | PHP logs remain free of the Cloudflare.php substr TypeError through the watch window. |
What to check first
- Capture the exact PHP fatal line, WordPress version, WP Rocket version, plugin directory name, Cloudflare add-on state, and time the failure began.
- Confirm whether the frontend, wp-admin, WP-CLI, hosting file manager, SFTP, and recovery email each remain available before selecting the least disruptive recovery path.
- Deactivate WP Rocket without deleting its directory, verify that wp-admin and a public uncached URL recover, then install version 3.23.2.2 or newer from the licensed package.
- Clear WP Rocket, origin page cache, PHP opcode cache when available, Cloudflare cache, and browser cache in a controlled order so an old fatal response is not mistaken for a current failure.
- Reactivate WP Rocket and test homepage, admin, login, checkout or lead form, mobile menu, cache headers, PHP logs, and one Cloudflare purge.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because cache purges, retries, scheduled actions, and deployments can change the evidence between tests.
- Test the public browser path and the server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, stored record, logs, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
error=Uncaught TypeError: substr(): Argument #1 ($string) must be of type string
file=wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php
wordpress=7.1
wp_rocket_before=3.23.2.1
wp_rocket_after=3.23.2.2
cloudflare=enabled
result=frontend+wp-admin+purge-pass
Why this usually happens
- A Cloudflare integration value has a type that the affected WP Rocket build did not safely cast before calling substr().
- WordPress 7.1 changes the execution path enough to expose the latent type mismatch in affected configurations.
- A cached fatal response or stale opcode can survive after the plugin package itself has been updated.
- A renamed plugin directory can prevent the normal update notification and recovery path from finding WP Rocket.
Decision rule
Do not reactivate the affected build merely because wp-admin recovered. The release gate is the official fixed version plus a clean public request, clean PHP log, working Cloudflare purge, and a passing lead or checkout canary.
Production verification checklist
- WP Rocket reports version 3.23.2.2 or newer and the official plugin directory name.
- Frontend, wp-admin, login, and critical forms or checkout load without a new fatal error.
- Cloudflare purge and cache headers behave as expected after reactivation.
- PHP logs remain free of the Cloudflare.php substr TypeError through the watch window.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Preserve the error and availability map
- Deactivate WP Rocket through the safest available path
- Restore the official folder name and update to 3.23.2.2 or newer
- Clear origin, opcode, CDN, and browser cache
- Reactivate and run the production canary matrix
Mistakes to avoid
- Changing production code, cache settings, form fields, webhook endpoints, or firewall rules before preserving the exact failure, current versions, and rollback point.
- Treating one successful page load or dashboard status as proof while browser behavior, PHP logs, scheduled jobs, delivery records, and downstream data remain unchecked.
- Testing a different role, device, locale, form, URL, order state, cache state, or plugin combination than the workflow that users actually reach.
- Leaving helper plugins, debug logging, copied secrets, broad exclusions, temporary endpoints, or test notifications active after the verification window.
Questions teams ask during testing
Can I run this directly on production?
Begin with read-only checks and preserve evidence. Use staging for changes that affect PHP, cache generation, form submission, payment, email, or customer state. When production is necessary, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Match the exact plugin and WordPress versions, URL, role, device, locale, cache state, and integration path. Repeat the same fixture before and after the change, then compare stored evidence rather than relying on memory.
What evidence should I keep?
Keep UTC time, versions, affected URL or record ID, expected result, actual result, relevant log lines, configuration snapshot, change made, rollback point, and final verification. Remove credentials, payment details, and personal data.
When should I bring in a specialist?
Escalate when the site is unavailable, checkout or lead capture is affected, a security boundary is unclear, several systems disagree, or the next step could destroy evidence. A concise incident packet makes outside help much faster.
What to tell the client or owner
Give the owner a short evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected and actual result, key logs, the change made, rollback point, final result, owner, and next review date. Redact credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP recover the WordPress 7.1 and WP Rocket fatal error.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references