WordPress 7.1 was released on August 19, 2026. Soon afterward, websites running WP Rocket began experiencing a fatal PHP error that could take the entire website offline, including the WordPress administration area.
WP Rocket released a fix the next day.
But the incident has become more than a story about one plugin needing an update. The problem had been publicly reported on GitHub to WP Rocket on July 6, while WordPress 7.1 was still in development. The report included reproduction steps and a proposed fix. WordPress then went through its beta and release-candidate cycle before 7.1 was released.
The incident also led to a public warning from the official WordPress X account about the WP Rocket compatibility problem, which itself drew backlash.
The entire episode provides a useful look at one of the biggest tradeoffs of the WordPress model: a website can depend on a collection of independently developed software components that all have to remain compatible with one another.
What Happened With WordPress 7.1 and WP Rocket?
After updating to WordPress 7.1, websites running WP Rocket encountered this PHP fatal error:
substr(): Argument #1 ($string) must be of type string, int given
The error occurred in WP Rocket’s Cloudflare-related code:
wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php
The problem involved a callback key that could be an integer rather than a string. WP Rocket’s code passed that value to PHP’s substr() function, which expects a string, resulting in a fatal TypeError.
This wasn’t simply a feature that stopped working.
On affected configurations, the fatal error occurred while WordPress was loading, which could make the front end, wp-admin, REST API, and other WordPress entry points inaccessible.
There was also an interesting detail about the Cloudflare reference.
One reported reproduction did not have the Cloudflare WordPress plugin installed. The problem was in WP Rocket’s own Cloudflare integration code.
So a website owner could update WordPress and suddenly find the entire site down with an error involving WP Rocket’s Cloudflare code, even without having installed a Cloudflare plugin.
It’s a good illustration of how complicated the relationships between WordPress components can become.
The Timeline: The Problem Was Reported Before WordPress 7.1 Was Released
The timeline is an important part of this story.
July 6: The Fatal Error Is Reported
On July 6, 2026, a WP Rocket GitHub issue reported the substr() TypeError against a development version of WordPress 7.1.
The issue identified the relevant WP Rocket code, explained the type mismatch, provided reproduction information, and proposed a fix. It was marked as a critical issue.
This was an alpha version of WordPress, so it is important not to treat an alpha bug report as proof that a final release is already broken.
But it meant the compatibility problem was known during the WordPress 7.1 development cycle.
July 15: WordPress 7.1 Beta 1
WordPress 7.1 Beta 1 was released on July 15, beginning the public beta-testing phase. WordPress specifically emphasized that testing was important for finding compatibility problems before the final release.
July 22: Beta 2
WordPress 7.1 Beta 2 was released on July 22, continuing the testing cycle ahead of the final release.
August 5: WordPress 7.1 Reaches Release Candidate 1
On August 5, WordPress 7.1 reached Release Candidate 1.
At this stage, WordPress specifically encouraged plugin and theme developers to conclude their testing and update their compatibility information for WordPress 7.1.
That makes the timing particularly notable: the compatibility issue had been publicly reported weeks before the release candidate stage.
August 19: WordPress 7.1 Is Released
WordPress 7.1 officially launched on August 19.
Within hours, affected WP Rocket installations began producing fatal errors on real-world websites.
What had been a development-time compatibility issue was now a production problem.
August 20: WP Rocket Releases the Fix
On August 20, WP Rocket released version 3.23.2.2.
Its changelog specifically identifies the fix as:
“Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations (#8596).”
WP Rocket’s own documentation also identifies 3.23.2.2 as the fix for the WordPress 7.1 fatal error.
So the immediate problem was resolved quickly once WordPress 7.1 was released.
But the timeline raises a bigger question.
How did a compatibility problem reported during the WordPress 7.1 development cycle make it into a production release and then take websites offline?
That’s where the story becomes more interesting than a simple plugin bug.
What Actually Changed?
The technical cause was related to a change in WordPress 7.1 involving hook callback IDs.
WordPress uses hooks extensively. Plugins and themes can register functions, closures, and object methods to run when particular WordPress actions occur.
WordPress 7.1 changed how certain object callback IDs were generated. Instead of using the older object hash behavior, WordPress 7.1 uses spl_object_id() in the relevant code path.
That produces a numeric identifier.
PHP can then treat a numeric string used as an array key as an integer.
WP Rocket’s code was expecting the callback key to be a string and passed it to substr().
Under the affected circumstances:
WordPress provided a numeric key → PHP treated it as an integer → WP Rocket passed it to substr() → PHP threw a fatal TypeError.
It’s a small technical assumption that produced a very large result: the website would stop working completely.
And the fact that another plugin or theme could be involved in creating the callback condition adds another layer to the problem.
This is not simply one isolated piece of code.
It is software interacting with other software.
Then the WordPress X Account Called Out the Problem
The technical problem became a larger controversy after the official WordPress X account publicly warned WP Rocket users about the compatibility issue.
The post generated backlash, with people questioning the way WordPress publicly addressed the plugin problem.
Matt Mullenweg also commented publicly:
This part of the story is worth including because it raises an uncomfortable question for the WordPress ecosystem:
When a core update and a third-party plugin don’t work together, who ultimately bears the risk?
The plugin developer has a responsibility to maintain compatibility.
WordPress has a responsibility to develop and communicate changes to its core software.
But the website owner is the one whose site can go down.
And from the website owner’s perspective, it may not matter which component is technically at fault.
They need their website to work.
This Is the Fundamental Tradeoff of the WordPress Model
The WordPress plugin model gives you an enormous amount of flexibility.
You can build a very simple website with WordPress.
Or you can keep adding functionality until the site has dozens of plugins performing different jobs.
That flexibility also means that the website’s functionality can be spread across many independently maintained products.
When WordPress core changes, plugin developers have to keep up.
When PHP changes, plugin developers may have to adjust their code.
When one plugin changes something, another plugin can potentially be affected.
And when several plugins interact, it may be difficult to know which combination will produce a problem until someone encounters it.
That’s the tradeoff.
You’re not just choosing the features. You’re choosing the maintenance architecture behind those features.
UltimateWB Takes a Different Approach
This is one of the fundamental differences between WordPress and UltimateWB.
With WordPress, many website functions are commonly added by installing separate third-party plugins.
With UltimateWB, many major website functions are built into the platform itself.
UltimateWB includes built-in functionality for e-commerce, forums, memberships, forms, SEO tools, sitemap generation, photo galleries, slideshows, listings, social networking features, multilingual websites, and more. Check out the full list on the UltimateWB Built-In Features page.
The significance isn’t simply that the features are there.
It’s that they are part of the same website-building platform.
You don’t need to assemble your site by finding a separate third-party plugin for every major function.
That means fewer independent components to coordinate and fewer third-party plugin compatibility issues to worry about.
It’s More Than a Question of Convenience
When someone compares website builders, it’s easy to compare feature lists:
Does it have e-commerce?
Does it have a forum?
Does it have memberships?
Does it have SEO tools?
But another question is just as important:
How are those features delivered?
Getting a feature by installing another independently maintained plugin isn’t the same thing as getting that functionality as part of the platform.
With the plugin approach, you’re adding another software dependency.
With an integrated platform, the functionality is developed as part of the larger system.
That doesn’t mean integrated software can never have bugs or require updates.
It means the responsibility for keeping the major components working together is much more centralized.
That’s a significant difference.
What the WP Rocket Incident Means for Website Owners
The immediate lesson for WP Rocket users is straightforward:
If you are running WordPress 7.1, make sure WP Rocket is updated to 3.23.2.2 or later, which contains the fix for the fatal TypeError.
If your website is already experiencing the fatal error and you cannot access wp-admin, you may need to deactivate WP Rocket through your hosting control panel, file manager, SFTP, or another method before updating it.
But the larger lesson goes beyond this particular WP Rocket problem.
The issue was reported during the WordPress 7.1 development cycle. WordPress then moved through its beta and release-candidate stages before 7.1 was released. After the final release, the compatibility problem could result in a fatal PHP error and take affected websites offline.
WP Rocket released a fix the next day.
The immediate problem was solved.
The underlying tradeoff, however, remains.
When a website is built by combining WordPress with a large collection of independently developed plugins, each plugin becomes another piece of software that has to remain compatible with WordPress and potentially with other plugins.
That means the number of plugins isn’t just a measure of how many features your website has.
It’s also a measure of how many software dependencies your website has.
This is one of the fundamental differences between the WordPress plugin model and an integrated website builder such as UltimateWB.
UltimateWB builds many major website functions directly into the platform rather than requiring website owners to assemble those functions through a long chain of third-party plugins.
That doesn’t mean integrated software never needs updates or can never have bugs. No software platform can make that promise.
It means that more of the responsibility for keeping the major components working together is handled within the same platform.
For website owners, that’s an important distinction to consider before choosing how to build a website.
You’re not just choosing the features you need. You’re choosing how those features – and the dependencies behind them – will be maintained.
Looking for a website builder that helps you avoid plugin headaches? Learn more about UltimateWB! We also offer web design packages if you would like your website designed and built for you.
Got a techy/website question? Whether it’s about UltimateWB or another website builder, web hosting, or other aspects of websites, just send in your question in the “Ask David!” form. We will email you when the answer is posted on the UltimateWB “Ask David!” section.