« Ce bloc n’existe pas. Il peut avoir été supprimé, ou il appartient à une extension désinstallée. » Ce message est apparu sur une dizaine de pages, un lundi matin, après qu’un client a désactivé « pour tester » une extension listée par un plugin de sécurité comme suspecte de ralentir le site. Aucun avertissement préalable n’avait mentionné que cette extension enregistrait un bloc personnalisé utilisé sur plusieurs pages stratégiques.
La bonne nouvelle arrive avant même de commencer le diagnostic : ce message ne signifie pas que le contenu a disparu. Gutenberg sérialise chaque bloc dans post_content sous forme de commentaire HTML structuré, et ce commentaire reste parfaitement intact tant que personne n’a republié la page depuis l’éditeur. Le contenu existe toujours en base ; c’est uniquement l’éditeur qui ne sait plus comment l’interpréter.
Comprendre ce que Gutenberg fait d’un bloc non enregistré
Chaque bloc est stocké dans post_content sous la forme <!-- wp:namespace/nom-du-bloc {"attribut":"valeur"} -->...<!-- /wp:namespace/nom-du-bloc -->. Quand l’éditeur charge une page, il appelle parse_blocks() côté client pour reconstituer la liste des blocs. Si le nom de bloc rencontré ne correspond à aucun bloc enregistré via register_block_type() — parce que l’extension qui l’enregistrait est désactivée — Gutenberg affiche un espace réservé « bloc introuvable », sans toucher au contenu sérialisé sous-jacent.
Côté affichage public (front-end), le comportement diffère selon qu’il s’agit d’un bloc statique ou dynamique. Un bloc dynamique, dont le rendu dépend d’un render_callback PHP absent, disparaît simplement de l’affichage public — la fonction n’existe plus, WordPress ignore le commentaire correspondant. Un bloc à rendu statique enregistré uniquement côté JavaScript peut, selon la configuration du thème, continuer à afficher son dernier HTML sauvegardé, car ce HTML est également présent dans le contenu sérialisé.
La procédure de récupération, étape par étape
- Ne surtout pas enregistrer de modification sur les pages concernées tant que l’extension n’a pas été réactivée : republier depuis l’éditeur avec des blocs « introuvables » présents peut, selon la version de WordPress, purger silencieusement leur contenu au moment de la sérialisation.
- Réactiver l’extension immédiatement, le temps du diagnostic. Cela suffit en général à faire réapparaître normalement l’ensemble des blocs, éditeur comme affichage public.
- Exporter le contenu brut des pages concernées avant toute autre manipulation, avec
wp post get {ID} --field=post_contenten WP-CLI, pour disposer d’une sauvegarde exacte du contenu sérialisé. - Identifier la cause réelle du ralentissement suspecté, sans confondre l’extension qui enregistre le bloc avec l’extension réellement responsable — un profilage avec
Query Monitorest plus fiable qu’une désactivation à l’aveugle. - Si l’extension doit vraiment disparaître, convertir chaque occurrence du bloc en un format que WordPress sait afficher sans elle (bloc de paragraphe, bloc HTML personnalisé), avant de la désactiver définitivement.
Le bouton « Tenter la récupération du bloc »
Lorsque l’extension reste désactivée par nécessité (incompatibilité avec une montée de version PHP, par exemple), l’éditeur propose parfois un bouton Tenter la récupération du bloc sur le bloc affiché comme introuvable. Ce bouton ne fait rien de magique : il tente de réafficher le contenu sérialisé tel quel, en le traitant comme du HTML brut plutôt que comme un bloc structuré. Le résultat visuel est souvent correct pour un bloc simple (texte, mise en forme basique), mais perd toute interactivité pour un bloc qui reposait sur du JavaScript ou des attributs dynamiques.
- Utiliser ce bouton uniquement en dernier recours, après avoir exporté une copie du contenu original.
- Vérifier visuellement le rendu obtenu avant de republier, car la mise en forme peut différer du rendu d’origine.
- Documenter, pour l’équipe, que ce contenu n’est plus un bloc structuré mais du HTML figé, ce qui compliquera toute évolution future.
Sur ce type d’incident, mon premier réflexe est toujours de vérifier si une modification a été enregistrée depuis l’éditeur après la désactivation : c’est ce moment précis, et pas la désactivation elle-même, qui peut transformer un contenu récupérable en contenu réellement perdu.
Prévenir la prochaine fois
La cause racine de cet incident n’était pas technique mais organisationnelle : une extension désactivée sans vérifier au préalable son usage réel sur le site. Une simple recherche de wp:acme/ dans un export de contenu (wp db search "wp:acme/" en WP-CLI) permet, avant toute désactivation, de savoir précisément combien de pages seraient affectées, et d’agir en conséquence plutôt que de le découvrir a posteriori dans les journaux du support client.
