Après une mise à jour mineure de WordPress sur le site de la Maison Verrière, un fabricant de vérandas, une partie du catalogue de réalisations affichait soudainement l’avertissement « Ce bloc contient des données inattendues » sur des articles publiés depuis plus de deux ans, jamais retouchés depuis. Le bloc en cause, une galerie de photos de chantier personnalisée, n’avait reçu aucune mise à jour de code de notre côté. Le premier réflexe, accuser une régression dans notre propre plugin, s’est révélé faux.
Symptôme : une invalidation en masse sans cause apparente côté bloc
Environ cent quatre-vingts articles ont basculé en avertissement de validation le même jour, tous partageant un point commun : leur contenu contenait des légendes de photo avec des apostrophes typographiques et des esperluettes, saisies plusieurs années auparavant. Le bloc lui-même n’avait pas changé de version ni de schéma d’attributs.
Diagnostic : comment fonctionne la validation de bloc
Il faut rappeler le mécanisme : à l’ouverture d’un article, l’éditeur recalcule le rendu HTML attendu du bloc à partir de ses attributs actuels, via sa fonction save, puis compare ce résultat au contenu HTML réellement stocké dans post_content. Si les deux ne correspondent pas trait pour trait (aux normalisations d’espaces près), l’éditeur considère le bloc invalide et propose une récupération.
Ce mécanisme protège contre la corruption silencieuse de contenu, mais il est par nature très sensible à tout changement, même minime, dans la façon dont le HTML est échappé ou normalisé entre le moment de l’enregistrement initial et celui de la relecture.
La cause réelle : un changement d’échappement dans le parser core
La mise à jour de WordPress en cause avait ajusté finement la façon dont certains caractères spéciaux dans les attributs HTML issus de RichText sont échappés lors de la sérialisation. Un changement de comportement du parser sous-jacent (la bibliothèque @wordpress/blocks et ses fonctions de sérialisation) suffit à ce que le HTML recalculé par save diffère, au niveau du caractère, du HTML enregistré des années plus tôt avec une version antérieure de cette même bibliothèque.
// Ancien contenu enregistré (extrait) :
<figcaption>Chantier de l’atelier Dupré</figcaption>
// Rendu recalculé par la version actuelle du bloc :
<figcaption>Chantier de l’atelier Dupré</figcaption>La différence tient à l’encodage de l’accent : une entité HTML dans un cas, le caractère UTF-8 direct dans l’autre. Strictement équivalents à l’affichage, ils diffèrent au caractère près, ce qui suffit à déclencher l’avertissement de validation.
Correctif : ne pas modifier le bloc, ajuster la stratégie de comparaison
Puisque le bloc lui-même n’est pas en cause, la correction ne passe pas par une entrée deprecated classique (qui gère un changement de structure, pas un changement de normalisation de caractères), mais par une fonction isEligible plus tolérante sur une entrée de déprécation existante, ou par une resauvegarde en masse du contenu concerné une fois la cause identifiée :
- Confirmer d’abord, via une comparaison manuelle du contenu brut en base et du rendu recalculé, que la différence est purement une variation d’encodage de caractères et non une perte réelle de donnée.
- Ne jamais accepter la récupération automatique proposée par l’éditeur sans avoir vérifié ce point, au risque de resauvegarder un contenu appauvri sans s’en rendre compte.
- Documenter l’incident dans le changelog du site pour que la prochaine invalidation en masse soit diagnostiquée plus vite.
Ce que ce cas ne couvre pas
La fonctionnalité « Attempt Block Recovery » elle-même, le bouton proposé par l’éditeur pour tenter une récupération automatique, ne fait pas l’objet de cet article : elle est déjà documentée en tant que fonctionnalité. Ce cas se concentre sur le diagnostic en amont, avant même de cliquer sur ce bouton.
Un bloc invalidé en masse du jour au lendemain n’est presque jamais un problème de bloc : c’est presque toujours un problème de comparaison.
En résumé
Sur les cent quatre-vingts articles concernés, aucune donnée n’avait réellement été perdue : la différence tenait entièrement à une normalisation de caractères entre deux versions de la bibliothèque de sérialisation de blocs. La vigilance ici n’était pas de corriger le bloc, mais de résister à l’envie de le corriger avant d’avoir confirmé la nature exacte de l’écart.
