Recommended order of updates. Whether a site goes down depends on the order in which WordPress 7.1 and the AccelerateWP update arrive
If WordPress has not been upgraded to 7.1 yet: Update AccelerateWP first, then upgrade WordPress. Plugin versions before 1.1-46 are not compatible with WordPress 7.1 (see the trigger conditions in our first update); if the site is already running 1.1-46 when the core upgrade happens, the outage does not occur at all
Update the package on the server. Until cloudlinux-site-optimization-module-1.1-46 reaches the stable channel, use one of the two commands from our 12:57 UTC update (beta or rollout slot 21 bypass). Refresh the plugin on each WordPress site so the site actually runs 1.1-46. Updating the package alone does not do this (see our 18:22 UTC update); the per-site command from that update is safe to run on a healthy site and keeps the plugin settings. Only then upgrade WordPress core to 7.1
If WordPress is already on 7.1 and the site is down: update the package and run the per-site reinstall from our 18:22 UTC update. It works on a site that is already failing
Posted Aug 26, 2026 - 06:28 UTC
Update
In addition to updating the cloudlinux-site-optimization-module package, the hosting provider also needs to update the plugin on all WordPress sites.
Updating the package refreshes only the copy of the plugin on disk at /opt/cloudlinux-site-optimization-module/clsop.zip. It does not touch the copy inside wp-content/plugins/clsop on each site, and a site picks the new version up on its own only if its owner turned on plugin auto-updates, which is off by default.
To refresh one site, run this as the site's own system user (not root) from the site document root, with the PHP binary that site runs: /opt/clwpos/wp-cli-wrapped /opt/alt/php84/usr/bin/php /home/USER/public_html plugin install /opt/cloudlinux-site-optimization-module/clsop.zip --force --skip-plugins (Make sure to change the PHP binary and document root paths accordingly)
This works on a site that is already showing the error and on a healthy one. It keeps the plugin active and keeps its settings. If you applied the hand edit from our first update, this replaces that file with the fixed version, so there is nothing to redo.
Posted Aug 20, 2026 - 18:22 UTC
Monitoring
Fixed packages cloudlinux-site-optimization-module-1.1-46 are delivered to beta repository and rollout slot 21. The package can be updated with the following commands: yum update cloudlinux-site-optimization-module --enablerepo=cloudlinux-updates-testing or yum update cloudlinux-site-optimization-module --enablerepo=cloudlinux-rollout-21-bypass
Posted Aug 20, 2026 - 12:57 UTC
Identified
WordPress 7.1 changed how it builds the identifier for a hook callback. A callback registered as a closure now gets a numeric identifier, and PHP stores that as an integer array key. AccelerateWP passed the key to a string function, which is a fatal error under strict typing. The code runs on init, so both the front end and wp-admin go down.
Any AccelerateWP site on WordPress 7.1 where any installed plugin registers a closure on the deleted_post or transition_post_status hook. The Cloudflare plugin does not have to be installed, so a site with no Cloudflare plugin can be affected too. Sites on WordPress 6.9 or older are not affected.
A fix to be released in cloudlinux-site-optimization-module-1.1-46 today.
As a hotfix for your AccelerateWP-enabled WordPress instance, open the file wp-content/plugins/clsop/inc/ThirdParty/Plugins/CDN/Cloudflare.php and replace substr( $key, - strlen( $method ) )