WordPress 7.1 s’installe automatiquement sur des millions de sites. Sur certains, l’opération se termine par un écran blanc : plus de site public, plus de tableau de bord, aucune explication à l’écran. Si ça vient de vous arriver, WP Rocket 3.23.2.1 est un suspect sérieux. C’est arrivé sur l’un de nos sites et nous avons remonté la cause jusqu’au code.
Le correctif officiel existe : WP Rocket 3.23.2.2, sortie le 20 août 2026. Le problème, c’est qu’un site tombé ne vous laisse pas accéder à l’écran des extensions pour l’installer. Voici la marche à suivre, puis ce qui s’est réellement passé.
Ce qui s’est passé
WordPress 7.1 a changé la façon d’étiqueter les fonctions accrochées à ses hooks. Jusqu’à la 7.0, une fonction anonyme (une closure) recevait une étiquette texte produite par spl_object_hash(). Depuis la 7.1, c’est spl_object_id(), plus rapide, qui s’en charge : l’étiquette devient un simple nombre. Le changement est documenté noir sur blanc dans le code de WordPress, fichier wp-includes/plugin.php.
WP Rocket, de son côté, embarque une classe de compatibilité avec l’extension officielle Cloudflare, chargée de retirer certains callbacks pour éviter que les deux extensions ne vident le cache deux fois de suite. Pour les repérer, elle passe chaque étiquette à substr(), qui attend du texte. Elle reçoit désormais un nombre. Et comme le fichier concerné est en declare(strict_types=1), PHP refuse la conversion automatique, lève une TypeError et s’arrête. L’ironie est complète : c’est un garde-fou de qualité qui transforme un avertissement anodin en erreur fatale.
Le code fautif est accroché au hook init, déclenché à chaque requête sans condition préalable. L’erreur survient donc avant tout affichage, écran de connexion compris. D’où l’impossibilité de désactiver l’extension depuis le tableau de bord.
Êtes-vous concerné ?
Trois conditions doivent être réunies :
- votre site tourne en WordPress 7.1 ou plus récent ;
- WP Rocket est actif en version 3.23.2.1 ou antérieure, autrement dit vous n’avez pas encore installé la 3.23.2.2 ;
- une autre extension de votre site accroche une fonction anonyme sur
deleted_postoutransition_post_status.
La troisième condition explique pourquoi tous les sites ne tombent pas. Elle est invisible depuis l’interface et dépend des extensions installées : deux sites avec les mêmes versions de WordPress et de WP Rocket peuvent réagir différemment. Ne concluez donc pas trop vite que vous êtes à l’abri parce que le voisin va bien.
Austin Ginder, d’Anchor Hosting, a publié le décompte de son parc : sur 332 sites en production équipés de WP Rocket, 124 sont tombés, soit 37 %. Ses tests donnent des repères concrets. Une installation propre avec WP Rocket seul ne plante pas. Ajoutez Elementor Pro ou Contact Form 7 Redirection, et la requête suivante fait tomber le site. À noter aussi : le module Cloudflare de WP Rocket s’exécute à chaque requête, que vous utilisiez Cloudflare ou non.
Si votre hébergeur ou votre outil de surveillance vous envoie un rapport d’erreur, vous y trouverez une ligne de ce genre :
Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given
in /wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562Le chemin contient wp-rocket : c’est votre confirmation. Si vous n’avez rien reçu, ajoutez temporairement define( 'WP_DEBUG', true );, define( 'WP_DEBUG_LOG', true ); et define( 'WP_DEBUG_DISPLAY', false ); dans votre wp-config.php, puis lisez wp-content/debug.log. Le false garde l’erreur hors de l’écran de vos visiteurs. Repassez tout à false ensuite.
Étape 1 : remettre le site en ligne
L’objectif immédiat n’est pas de corriger, c’est de rouvrir la boutique. En FTP ou via le gestionnaire de fichiers de votre hébergeur, allez dans wp-content/plugins/ et renommez le dossier wp-rocket en wp-rocket-off. WordPress ne trouve plus l’extension et la désactive de lui-même : votre site revient immédiatement, sans cache donc plus lent, mais en ligne. Renommez, ne supprimez pas : vos réglages sont en base de données.
Avec un accès SSH :
wp plugin deactivate wp-rocket --skip-pluginsL’option --skip-plugins n’est pas facultative : sans elle, WP-CLI charge toutes les extensions, rencontre la même erreur fatale et s’arrête avant d’avoir rien fait. Réflexe à garder quand une extension empêche WordPress de démarrer.
Étape 2 : mettre à jour vers la 3.23.2.2
Une fois le tableau de bord récupéré, la vraie réponse est la mise à jour. Un piège vous attend : comme vous avez renommé le dossier, WordPress ne reconnaît plus l’extension et la mise à jour n’apparaît pas dans votre liste. Renommez donc wp-rocket-off en wp-rocket avant de forcer une vérification des mises à jour, WP Rocket étant toujours désactivé à ce stade.
Si la mise à jour refuse de se montrer, l’éditeur publie une extension d’assistance prévue exactement pour ce cas, avec la procédure pas à pas, dans sa documentation dédiée à ce bug. Vérifiez que vous êtes bien en 3.23.2.2, puis réactivez.
Et si vous n’êtes pas encore passé en WordPress 7.1, l’ordre a son importance : mettez WP Rocket à jour d’abord, la mise à jour de WordPress ensuite. C’est la consigne donnée par l’éditeur lui-même.
Si vous ne pouvez pas mettre à jour tout de suite
Licence expirée, gel des déploiements, parc de sites à traiter en série : il existe des raisons légitimes de ne pas mettre à jour dans la minute. Dans ce cas, la méthode que nous recommandons ne touche pas au code de WP Rocket, donc elle ne sera pas écrasée. Créez le fichier wp-content/mu-plugins/fix-rocket-cf-wp71.php (créez le dossier mu-plugins s’il n’existe pas) :
<?php
// wp-content/mu-plugins/fix-rocket-cf-wp71.php
add_action( 'init', function () {
global $wp_filter;
if ( ! isset( $wp_filter['init'] ) ) {
return;
}
foreach ( $wp_filter['init']->callbacks as $prio => $callbacks ) {
foreach ( $callbacks as $key => $cb ) {
if ( is_array( $cb['function'] )
&& isset( $cb['function'][0] )
&& $cb['function'][0] instanceof \WP_Rocket\ThirdParty\Plugins\CDN\Cloudflare
) {
unset( $wp_filter['init']->callbacks[ $prio ][ $key ] );
}
}
}
}, 1 );Le dossier mu-plugins (pour must-use) contient des fichiers que WordPress charge automatiquement, avant les extensions classiques, et qui ne peuvent pas être désactivés depuis l’interface. C’est l’endroit idoine pour ce genre de rustine. Ce code retire le morceau de WP Rocket qui plante, juste avant qu’il ne s’exécute.
La contrepartie : vous perdez la fonction que ce code assurait, à savoir éviter que WP Rocket et l’extension officielle Cloudflare ne vident le cache deux fois de suite. Concrètement, quelques purges de cache Cloudflare redondantes. Indolore sur la plupart des sites ; si vous publiez beaucoup, surveillez votre quota d’appels à l’API Cloudflare.
L’autre méthode : corriger le fichier
Dans wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php, aux alentours de la ligne 562, il suffit d’ajouter un (string) :
// Avant
if ( substr( $key, - strlen( $method ) ) !== $method ) {
// Après
if ( substr( (string) $key, - strlen( $method ) ) !== $method ) {C’est plus court, mais la modification sautera dès que vous installerez la 3.23.2.2, ce qui n’est pas grave puisque celle-ci contient le correctif officiel. Choisissez une méthode, pas les deux, elles font le même travail. Et pensez à retirer votre rustine une fois la mise à jour passée.
Vérifiez vos autres sites
Ne vous contentez pas de constater qu’ils répondent : un site peut tenir tant que personne ne supprime ou ne dépublie un contenu. Le test qui compte, sur une copie et pas en production : dépubliez un article, supprimez-le, videz la corbeille.
Un correctif qui attendait depuis 45 jours
Le bug n’a pas été découvert le jour où les sites sont tombés. Il a été signalé sur le dépôt public de WP Rocket le 6 juillet 2026, pendant la phase alpha de WordPress 7.1. Le ticket 8596 décrit la cause exacte, les conditions de reproduction, et propose la ligne de correctif, celle-là même qui a fini par être appliquée.
La version 3.23.2.1, sortie le 11 août, ne l’embarquait pas. La correction est arrivée avec la 3.23.2.2 le 20 août, 45 jours après le signalement. Entre les deux, WordPress 7.1 est sorti et des sites sont tombés en production.
La réaction de l’écosystème a été vive, et WP Rocket n’a pas cherché à minimiser : l’éditeur a reconnu le problème publiquement et annoncé un post-mortem sur la façon dont le ticket du 6 juillet a été trié. Interrogé sur ses tests contre les versions préliminaires de WordPress 7.1, il indique en avoir mené, sans encore savoir pourquoi ils n’ont rien détecté.
L’incident a aussi provoqué une réponse côté WordPress : le contributeur Adam Silverstein a ouvert un ticket Trac proposant de tester automatiquement les 100 extensions les plus installées du répertoire officiel contre les versions non publiées de WordPress, pour attraper ce type d’erreur fatale avant la production. Le ticket est planifié pour WordPress 7.2. Il ne couvrirait pas ce cas précis, WP Rocket étant une extension payante hors répertoire, mais le même genre de panne peut surgir dans n’importe quelle extension gratuite à plusieurs millions d’installations.
La vraie leçon
De votre côté, cet incident vient d’une mise à jour majeure installée automatiquement, sans passage préalable sur une copie du site. Par défaut, WordPress installe seul les mineures (7.1.1, 7.1.2), des correctifs à faible risque. Les majeures (7.0 vers 7.1) peuvent modifier des mécanismes internes, et c’est exactement ce qui s’est passé ici. Pour n’automatiser que les mineures, ajoutez dans votre wp-config.php :
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Vous continuez à recevoir les correctifs de sécurité, mais vous décidez du moment pour les changements majeurs. Et pour ceux-là, la marche à suivre ne change pas : une copie du site, la mise à jour testée dessus, puis le vrai site. Plus une sauvegarde dont vous avez déjà vérifié qu’elle se restaure, parce qu’une sauvegarde jamais testée n’est pas une sauvegarde.
Testé sur WordPress 7.1 avec WP Rocket 3.23.2.1. Corrigé dans la 3.23.2.2, publiée le 20 août 2026. Le changement d’étiquetage des callbacks est visible dans la documentation de _wp_filter_build_unique_id(). Les chiffres du parc d’Anchor Hosting, les réactions de l’écosystème et la réponse de WP Rocket sont rapportés par The Repository.