WP Rocket revient sur l’incident qui a touché une partie de ses utilisateurs après WordPress 7.1

WP Rocket a publié le 26 août 2026 le post-mortem d’un incident survenu après la sortie de WordPress 7.1. Le point important est à formuler avec précision : WordPress 7.1 n’a pas provoqué une panne générale des sites WordPress. Le problème se situait dans WP Rocket et n’apparaissait que lorsqu’une combinaison précise de conditions était réunie.

Cette combinaison était spécifique, mais loin d’être marginale : selon WP Rocket, environ 27 % de ses sites étaient potentiellement exposés et environ 10 % ont effectivement été touchés. C’est ce qui explique l’ampleur de l’incident à l’échelle de sa base installée.

Ce qui s’est passé, simplement

WP Rocket embarque un petit module lié à Cloudflare. Dans une routine interne, ce module appelle la fonction PHP substr() sur un identifiant généré par WordPress pour certains callbacks.

Avant WordPress 7.1, cet identifiant était toujours renvoyé sous forme de chaîne dans les cas concernés par WP Rocket. Avec WordPress 7.1, il pouvait désormais être renvoyé sous forme d’entier dans certaines conditions.

Le post-mortem de WP Rocket attribue ensuite l’erreur fatale au typage de PHP 8. Ce point mérite toutefois une nuance technique : PHP fonctionne par défaut en mode coercitif, et peut convertir un entier en chaîne lorsqu’un paramètre attend une string. Le mode strict doit être activé explicitement avec declare(strict_types=1). Il est donc plus prudent de retenir le constat opérationnel — un entier apparaissait là où le code de WP Rocket supposait recevoir une chaîne, et cette incompatibilité déclenchait l’erreur fatale observée — sans réduire toute la chaîne causale à « PHP 8 refuse un entier dans substr() ».

Le bug ne concernait donc pas tous les sites mis à jour vers WordPress 7.1. Il fallait réunir plusieurs éléments :

• WordPress 7.1 ;
• PHP 8.x ;
• WP Rocket ;
• et au moins un autre plugin enregistrant certains callbacks d’une manière précise.

WP Rocket cite notamment Elementor Pro, Elementor Free avec l’option expérimentale e_atomic_elements active, et Redirection for Contact Form 7. L’éditeur précise que ces plugins ne sont pas fautifs : ils correspondaient simplement aux conditions qui révélaient le bug présent dans WP Rocket.

Pourquoi WordPress 7.1 apparaît dans l’histoire

WordPress 7.1 a modifié la manière dont certains identifiants de callbacks peuvent être construits. Ce changement a servi de déclencheur, car il a exposé une hypothèse fragile dans le code de WP Rocket : considérer que l’identifiant serait toujours une chaîne.

C’est une distinction importante. Une mise à jour d’une plateforme peut révéler un bug dans une extension sans que la plateforme elle-même soit « cassée » pour l’ensemble de ses utilisateurs.

Le 21 août, Weston Ruter, mainteneur de WordPress Core, a confirmé que ce changement de comportement pouvait être considéré comme une rupture de compatibilité côté Core. Un autre contributeur a ensuite ouvert le ticket Trac #65919 avec une correction proposée, annoncée comme destinée à WordPress 7.1.1.

Dans son post-mortem, WP Rocket assume néanmoins clairement sa part de responsabilité : son code reposait sur une hypothèse trop fragile et, surtout, le signal avait été remonté suffisamment tôt pour être traité avant la sortie stable.

Combien de sites ont été touchés ?

WP Rocket estime qu’environ 27 % de ses sites étaient à risque, sur la base des plugins connus pour déclencher le problème et des habitudes de mise à jour observées chez ses utilisateurs.

L’éditeur estime qu’environ 10 % de ses sites ont réellement été affectés.

Il s’agit donc d’un incident significatif pour WP Rocket. La combinaison était précise, mais elle s’est révélée suffisamment courante pour toucher une part importante de ses utilisateurs. L’échelle pertinente reste celle de la base installée de WP Rocket, et plus précisément des sites réunissant les conditions nécessaires pour déclencher l’erreur.

Pour les sites touchés, les conséquences pouvaient être sérieuses : perte du front-office et, dans certains cas, impossibilité d’accéder au tableau de bord WordPress.

Le premier signal datait du 6 juillet

Le point le plus embarrassant du post-mortem est chronologique.

Dès le 6 juillet, pendant la phase alpha de WordPress 7.1, un utilisateur de WP Rocket avait ouvert une issue GitHub décrivant le problème. Le rapport identifiait correctement le bug et suggérait même une correction proche de celle qui sera finalement livrée.

L’équipe QA a enquêté le jour même. Ses tests automatisés passaient et elle n’a pas réussi à reproduire le problème. Le ticket n’a ensuite été attribué à personne et a progressivement disparu du radar.

Dans les semaines suivantes, quelques clients ont remonté la même erreur fatale au support. Ces cas ont été résolus en revenant à une version stable de WordPress, mais le rapprochement avec l’issue GitHub initiale n’a pas été fait.

Le 15 juillet, lorsque la première bêta de WordPress 7.1 est sortie, les tests automatisés et manuels de WP Rocket ont de nouveau réussi. Le plugin a alors été déclaré compatible avec WordPress 7.1.

Pourquoi les tests de WP Rocket n’ont-ils rien vu ?

C’est ici que l’incident devient particulièrement instructif.

WP Rocket explique disposer d’environ une centaine de tests automatisés de bout en bout sur Apache et NGINX, exécutés contre les versions récentes de WordPress, y compris les bêta et release candidates.

La suite testait déjà un ensemble conséquent de produits tiers : Query Monitor, Imagify, Cloudflare, WPML, Divi, Avada, Astra, Flatsome, Storefront, Hello Elementor, Neve, Kadence, GeneratePress, Genesis Sample et OceanWP.

Le problème n’était donc pas simplement une absence de tests. Il venait plutôt de la manière dont cette matrice de compatibilité avait été constituée.

WP Rocket explique que cette liste s’est construite opportunément au fil des années, en ajoutant des tests après des travaux de compatibilité successifs. Elle n’avait pas été conçue à partir d’une cartographie systématique des plugins et thèmes les plus utilisés chez ses clients.

Elementor Pro, par exemple, n’y figurait pas. Or il faisait partie des plugins capables de déclencher le chemin de code fautif.

Autrement dit : les tests couvraient bien la nouvelle version de WordPress et de nombreux tiers connus, mais pas nécessairement les combinaisons les plus représentatives de la production réelle.

Le correctif est arrivé le 20 août

Les premiers tickets liés à la release candidate de WordPress 7.1 sont arrivés dans la nuit du 19 au 20 août.

À 00 h 35 CEST, WP Rocket disposait d’un correctif manuel. Celui-ci n’avait toutefois pas encore passé la validation QA habituelle. Plutôt que de publier largement un workaround non vérifié, l’équipe l’a donc envoyé uniquement aux clients qui avaient déjà un ticket support ouvert, avec l’indication qu’une mise à jour officielle arrivait.

WordPress 7.1 a ensuite été publié officiellement à 02 h 18 CEST. Une documentation de contournement a été mise en ligne à 04 h 08.

À 07 h 30, l’équipe plugin de WP Rocket a repris l’incident. Dans les quinze minutes, l’éditeur a communiqué publiquement via des notifications intégrées au produit, les réseaux sociaux, sa page de statut et des réponses sur les issues GitHub concernées, en renvoyant vers la documentation support et en annonçant l’arrivée d’un correctif.

Le correctif officiel, WP Rocket 3.23.2.2, a été publié à 10 h 11 CEST, après validation automatisée et tests manuels ciblés.

Le 21 août, WP Rocket a également envoyé un e-mail à tous ses clients actifs pour expliquer l’incident et recommander de mettre à jour WP Rocket avant de passer à WordPress 7.1.

Ce que WP Rocket dit vouloir changer

L’éditeur annonce plusieurs mesures concrètes.

D’abord, chaque issue GitHub devra désormais avoir un propriétaire clairement identifié. L’objectif est d’éviter qu’un signal non reproductible au premier essai sorte du circuit sans suivi.

Ensuite, WP Rocket veut reconstruire sa matrice de compatibilité en partant davantage des plugins et thèmes réellement utilisés par ses clients, plutôt que d’une liste héritée de travaux passés.

Enfin, l’éditeur prévoit de limiter le chargement de certains modules inutiles. Le module Cloudflare impliqué dans l’incident était exécuté même lorsque Cloudflare n’était pas utilisé. WP Rocket veut désormais conditionner ce chemin de code à la présence effective du plugin concerné.

WP Rocket indique également vouloir réduire le délai entre une escalade interne et une communication publique, couper davantage de chemins de code inutiles et accélérer la validation puis la publication d’un hotfix lorsqu’un incident est identifié.

Le vrai enseignement : tester des combinaisons, pas seulement des versions

Ce post-mortem illustre bien une difficulté propre aux écosystèmes extensibles comme WordPress : une incompatibilité ne dépend pas toujours d’un seul logiciel.

Ici, WordPress 7.1 a modifié un comportement interne ; WP Rocket contenait une hypothèse fragile sur le type d’une valeur ; et certains plugins tiers rendaient cette combinaison observable. Aucun de ces éléments, pris seul, ne raconte correctement l’incident.

Pour les éditeurs de plugins, la leçon est assez claire : valider une compatibilité avec une nouvelle version de WordPress ne consiste pas seulement à exécuter une suite de tests contre le Core. Il faut aussi tester les combinaisons les plus fréquentes chez les utilisateurs, conserver un suivi des anomalies non résolues et relier plus efficacement les signaux issus du support, de GitHub et de la QA.