« Ce bloc contient du contenu inattendu » dans un template : diagnostic

Un mail de client, un vendredi après-midi : « la template part de l’en-tête affiche un message bizarre, on ne peut plus rien modifier ». Le message en question : « Ce bloc contient du contenu inattendu », accompagné de trois boutons — Tenter la récupération, Convertir en blocs HTML personnalisé, Résoudre.

Ce cas revient régulièrement dès qu’une template part ou un pattern a été retouché via l’éditeur de code (l’icône </> qui bascule un bloc en HTML brut). Voici comment identifier précisément ce qui s’est cassé, et comment le réparer sans perdre le travail déjà fait.

Symptôme : un bandeau jaune à la place du rendu normal

À l’ouverture du template concerné dans l’éditeur de site, le bloc fautif n’affiche plus son rendu habituel mais un encart d’avertissement jaune. Le reste du template s’affiche normalement — seul le bloc modifié est en cause. Sur le front, selon les cas, soit le contenu s’affiche quand même de façon dégradée, soit il disparaît purement et simplement.

Ce comportement n’est pas un bug isolé : c’est un garde-fou volontaire de WordPress.

Diagnostic : une comparaison entre contenu enregistré et rendu attendu

Chaque bloc enregistre son contenu sous forme de commentaire HTML porteur d’attributs (<!-- wp:paragraph {"align":"center"} -->) suivi du balisage produit par sa fonction save() côté JavaScript. À l’ouverture, l’éditeur régénère ce balisage à partir des attributs stockés et le compare, comparaison de type diff, à ce qui est réellement enregistré en base.

Si quelqu’un a modifié le HTML directement — en supprimant une classe CSS générée automatiquement, en changeant un niveau de titre, en cassant une balise fermante — la comparaison échoue : le balisage réel ne correspond plus à ce que produirait le bloc avec ses attributs actuels. WordPress ne sait alors plus avec certitude comment continuer à éditer ce bloc en toute sécurité, et affiche l’avertissement plutôt que de risquer d’écraser silencieusement une modification volontaire.

Correctif : choisir la bonne option de récupération

Les trois boutons proposés ne se valent pas :

• Tenter la récupération : WordPress essaie de faire correspondre le contenu existant à la structure du bloc d’origine. Fonctionne bien pour des écarts mineurs (un attribut style ajouté à la main, un espace en trop) mais échoue si la structure a trop divergé.
• Convertir en blocs HTML personnalisé : transforme le contenu en un bloc HTML brut, figé, qui n’est plus reconnu comme le bloc d’origine. Le rendu revient à la normale mais on perd tous les contrôles visuels du bloc (plus de réglages dans la barre latérale). À utiliser en dépannage temporaire, pas comme solution définitive.
• Résoudre : ouvre un comparatif texte entre l’ancien et le nouveau contenu HTML, et laisse choisir manuellement lequel garder ou fusionner à la main. C’est l’option la plus fastidieuse, mais la seule qui permette de récupérer précisément une modification volontaire sans rien perdre.

Pour une template part critique en production, je recommande systématiquement Résoudre : elle prend deux minutes de plus mais évite de perdre un réglage qu’on avait mis du temps à obtenir.

Prévention : ne jamais éditer le HTML sans repasser par les attributs

La cause profonde, dans la quasi-totalité des cas que j’ai vus, est la même : quelqu’un ouvre le mode HTML d’un bloc (menu à trois points du bloc, Modifier en HTML), modifie une classe ou un attribut à la main, puis repasse en mode visuel sans que l’attribut correspondant côté interface ait été mis à jour en cohérence.

Quelques réflexes limitent drastiquement le risque :

• Préférer les réglages de la barre latérale (couleur, marge, alignement) à la retouche manuelle du HTML, même quand celle-ci semble plus rapide.
• Si une retouche HTML est vraiment nécessaire, la faire en dernière étape, une fois tous les réglages visuels terminés — pour ne plus rouvrir le bloc en mode visuel ensuite.
• Tester le template concerné juste après la modification, pas des semaines plus tard : l’erreur est immédiate à l’ouverture, elle ne se manifeste pas progressivement.
• Exporter régulièrement le thème (ou versionner via Create Block Theme) pour disposer d’un point de retour propre en cas de blocage sérieux.

En résumé

Ce message n’indique ni une corruption de la base de données ni un bug de WordPress : c’est un contrôle de cohérence entre le HTML enregistré et ce que le bloc, avec ses attributs actuels, devrait produire. Il se déclenche presque toujours après une édition manuelle du HTML d’un bloc dans un template ou une template part. Face au message, l’option Résoudre permet de comparer précisément les deux versions plutôt que de risquer une perte silencieuse ; en amont, limiter les retouches HTML manuelles reste la meilleure prévention.