# Un bloc qui valide mal ses attributs après une mise à jour discrète > Un changement de comportement du parser core a rendu un bloc invalide sur des contenus anciens, sans message d'erreur explicite au premier abord. - Auteur : Clément Hadrot - Publié le : 2025-05-13 - Mis à jour le : 2025-05-13 - Catégorie : Blocs Gutenberg - URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/bloc-valide-mal-attributs-mise-a-jour-discrete/ ## L’essentiel - Le parser compare le rendu sauvegardé au rendu recalculé - Un changement d'échappement HTML suffit à invalider un bloc ancien - Comparer le contenu brut avant d'accuser le bloc lui-même 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. > L'essentiel à retenir : Le parser compare le rendu sauvegardé au rendu recalculé ; Un changement d'échappement HTML suffit à invalider un bloc ancien ; Comparer le contenu brut avant d'accuser le bloc lui-même ``` // Ancien contenu enregistré (extrait) :
Chantier de l’atelier Dupré
// Rendu recalculé par la version actuelle du bloc :
Chantier de l’atelier Dupré
``` 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.