# Comparer le HTML enregistré d’un bloc à celui rendu en front
> Symptôme, diagnostic et correctif quand le contenu d'un bloc semble correct dans l'éditeur mais s'affiche différemment une fois publié sur le site public.
- Auteur : Clément Hadrot
- Publié le : 2026-01-24
- Mis à jour le : 2026-01-24
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/comparer-html-enregistre-bloc-rendu-front/
## L’essentiel
- Le code source de l'éditeur montre le HTML tel qu'enregistré en base
- Un filtre PHP peut transformer ce HTML avant l'affichage front
- La comparaison ligne à ligne révèle presque toujours la source de l'écart
« Ce n'est pas ce que j'ai enregistré » : cette phrase revient souvent quand un contenu de bloc s'affiche différemment sur le site public par rapport à ce que montrait l'éditeur au moment de la publication. Ce billet ne traite pas du popover d'édition HTML de l'éditeur, mais du cas où l'écart apparaît uniquement entre l'enregistrement et le rendu final, une fois la page consultée par un visiteur.
Le point de départ du diagnostic reste toujours le même : établir avec certitude ce que WordPress a réellement enregistré en base de données, avant de chercher ce qui, ensuite, transforme ce contenu au moment de l'affichage.
## Symptôme : un écart entre deux affichages du même contenu
Le cas typique se présente ainsi : un bloc de mise en avant affiche correctement son titre et son image dans l'éditeur, mais une fois la page publiée, une classe CSS manque, un attribut `alt` a disparu, ou un espace supplémentaire s'est glissé entre deux éléments. L'utilisateur qui republie le contenu, pensant à une erreur de saisie, observe que le problème persiste malgré tout.
## Étape 1 : lire le HTML réellement enregistré
Le bouton « Éditeur de code » du menu des options de l'éditeur affiche le contenu exact tel qu'il est stocké en base de données, sous forme de commentaires de bloc et de HTML statique généré par la fonction `save` du bloc. C'est la seule source fiable pour savoir ce qui a réellement été écrit, indépendamment de tout ce qui pourrait transformer ce contenu plus tard :
```
```
> L'essentiel à retenir : Le code source de l'éditeur montre le HTML tel qu'enregistré en base ; Un filtre PHP peut transformer ce HTML avant l'affichage front ; La comparaison ligne à ligne révèle presque toujours la source de l'écart
## Étape 2 : comparer avec le HTML servi sur le front
La comparaison se fait ensuite en consultant le code source de la page publiée, via l'outil « Afficher le code source de la page » du navigateur, en cherchant précisément le même bloc. Si l'attribut `alt` a disparu à cette étape, ou si une classe supplémentaire est apparue, la différence pointe vers une transformation qui intervient entre l'enregistrement et l'affichage, et non vers un problème de saisie initiale.
### Les points d'intervention possibles entre les deux
Plusieurs mécanismes peuvent modifier le contenu entre son enregistrement et son rendu final, sans jamais toucher au contenu stocké en base :
- Un filtre `render_block` ou `render_block_{$nom_du_bloc}` ajouté par une extension tierce, qui transforme la sortie HTML au moment du rendu.
- Une fonction `wp_kses_post` ou équivalente qui retire, par sécurité, un attribut ou une balise non reconnue par sa liste blanche.
- Un cache de page complet qui sert une version antérieure du contenu, générée avant la dernière modification du bloc.
## Étape 3 : isoler la cause avec une désactivation ciblée
Pour confirmer qu'un filtre PHP est en cause, la méthode la plus directe consiste à désactiver temporairement les extensions tierces une à une, en conservant le thème et l'extension du bloc concerné, puis à recharger la page publiée sans passer par un cache. Si l'écart disparaît après la désactivation d'une extension précise, le filtre fautif se trouve dans son code :
```
add_filter( 'render_block_monplugin/mise-en-avant', function ( $contenu_bloc, $bloc ) {
return str_replace( ' alt="', ' data-alt-supprime="', $contenu_bloc );
}, 10, 2 );
```
## Étape 4 : corriger à la bonne source
Une fois la cause identifiée, la correction doit intervenir à l'endroit précis où le contenu est altéré, jamais en compensant artificiellement dans le bloc lui-même. Modifier le `save` du bloc pour contourner un filtre externe déplace le problème sans le résoudre, et complique le diagnostic pour la prochaine personne qui reprendra le code.
> Un réflexe utile en débogage de rendu : toujours vider le cache de page avant de conclure à un bug, un contenu servi depuis un cache ancien produit exactement le même symptôme qu'une vraie régression.
## En résumé
Un écart entre le contenu enregistré et le rendu affiché sur le front se diagnostique en trois temps : lire le HTML réellement stocké via l'éditeur de code, comparer ce HTML au code source réellement servi, puis isoler par désactivation ciblée le filtre ou le mécanisme de cache responsable de la transformation. Cette démarche évite de modifier le mauvais endroit, et de masquer un problème qui referait surface ailleurs plus tard.
