Symptôme : après la désactivation d’une extension de blocs métier lors d’une migration, plusieurs dizaines d’articles affichent en front un simple message « Votre site ne prend pas en charge ce bloc actuellement. » à l’endroit exact où figurait auparavant un bloc « Fiche produit » personnalisé. Panique légitime côté client, qui craint d’avoir perdu du contenu — ce qui n’est heureusement jamais le cas dans ce scénario précis.
Un bloc devient « orphelin » quand WordPress rencontre, en base de données, un commentaire de bloc référençant un nom de bloc qu’aucune extension active n’a enregistré au moment du rendu — que ce soit parce que l’extension a été désactivée, désinstallée, ou parce que le bloc a été renommé sans mécanisme de migration. Le contenu HTML brut reste intact dans la base ; seul le mécanisme de rendu du bloc échoue à le reconnaître et l’afficher correctement.
Comprendre pourquoi rien n’est perdu
Le contenu d’un article WordPress stocke les blocs sous forme de HTML commenté, avec une délimitation de bloc en commentaire qui précède le balisage réel :
<!-- wp:agence/fiche-produit {"produitId":42,"afficherPrix":true} -->
<div class="wp-block-agence-fiche-produit">
<h3>Perceuse sans fil 18V</h3>
<p>49,90 €</p>
</div>
<!-- /wp:agence/fiche-produit -->
Quand l’extension qui enregistrait agence/fiche-produit est désactivée, WordPress ne trouve plus de définition correspondant à ce nom de bloc, mais le contenu HTML entre les commentaires reste stocké tel quel dans wp_posts. C’est ce HTML brut que l’éditeur affiche à la place du rendu normal, avec le message d’avertissement caractéristique et un aperçu du contenu figé.
Diagnostic : identifier tous les articles concernés
Avant toute correction, on identifie l’ampleur réelle du problème avec WP-CLI, en cherchant les articles contenant la signature du bloc concerné :
wp post list --post_type=post --format=ids | xargs -I {} wp post meta list {} 2>/dev/null
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%wp:agence/fiche-produit%' AND post_status = 'publish'"
Cette requête donne un décompte précis, indispensable pour dimensionner correctement la correction et éviter de découvrir de nouveaux cas après coup.
Solution rapide : réactiver l’extension
La première option, la plus simple si elle est possible : réactiver temporairement l’extension qui enregistrait le bloc, le temps de traiter le contenu correctement plutôt que de laisser les visiteurs voir le message d’erreur pendant l’investigation. Si l’extension a été désinstallée définitivement suite à une décision produit, cette option n’est pas toujours disponible, ce qui amène à la solution de conversion.
Convertir en blocs classiques (récupération manuelle)
Dans l’éditeur, sur un bloc orphelin affiché avec l’avertissement, le menu propose l’option Convertir en blocs classiques, qui transforme le contenu HTML brut du bloc en un simple bloc HTML personnalisé (core/html) modifiable directement. Cette opération récupère intégralement le balisage affiché, sans perte, mais fait perdre en contrepartie la structure d’attributs typés du bloc d’origine (produitId, afficherPrix dans l’exemple), qui n’existe plus qu’implicitement dans le HTML brut.
Conversion en masse par script
Pour plusieurs dizaines d’articles, traiter chaque conversion manuellement dans l’éditeur n’est pas réaliste. On préfère un script WP-CLI qui parcourt les articles concernés et remplace la délimitation de bloc orpheline par une délimitation de bloc HTML classique, en conservant le contenu interne intact :
<?php
// wp eval-file convertir-blocs-orphelins.php
$articles = get_posts( array(
'post_type' => 'post',
'posts_per_page' => -1,
's' => 'wp:agence/fiche-produit',
) );
foreach ( $articles as $article ) {
$motif = '/<!-- wp:agence\/fiche-produit(.*?)-->(.*?)<!-- \/wp:agence\/fiche-produit -->/s';
$nouveau_contenu = preg_replace_callback( $motif, function ( $correspondances ) {
$html_interne = trim( $correspondances[2] );
return "<!-- wp:html -->\n{$html_interne}\n<!-- /wp:html -->";
}, $article->post_content );
if ( $nouveau_contenu !== $article->post_content ) {
wp_update_post( array(
'ID' => $article->ID,
'post_content' => $nouveau_contenu,
) );
WP_CLI::log( "Article {$article->ID} converti." );
}
}
On teste toujours ce script d’abord sur une copie de la base en environnement de développement, avec une sauvegarde préalable en production avant exécution — une conversion en masse par expression régulière sur du contenu HTML reste une opération délicate si la structure varie légèrement d’un article à l’autre.
Prévenir plutôt que guérir
- Avant de désactiver définitivement une extension de blocs en production, vérifier systématiquement l’usage réel du ou des blocs qu’elle enregistre avec une requête similaire à celle du diagnostic ci-dessus.
- Pour un renommage de bloc plutôt qu’une suppression, préférer un mécanisme de dépréciation de bloc (voir la documentation officielle sur les dépréciations,
deprecateddans la définition du bloc côté JavaScript) qui migre automatiquement l’ancien nom vers le nouveau sans jamais produire de bloc orphelin.
Le réflexe qu’on a désormais systématisé en agence : avant toute désactivation d’extension en production, une requête SQL de comptage sur
post_contentfait partie de la checklist de mise en production, au même titre qu’une sauvegarde de base.
En résumé
Un bloc orphelin n’est jamais une perte de contenu, seulement un échec de rendu réversible tant que la base de données n’est pas modifiée. Réactiver l’extension d’origine reste la solution la plus simple quand elle est possible ; sinon, la conversion en blocs HTML classiques, manuelle ou scriptée selon le volume, récupère intégralement le contenu affiché, au prix de la perte des attributs typés d’origine.
