« Ce modèle contient un bloc non enregistré. » Ce message, affiché en rouge au-dessus d’un gabarit dans l’éditeur de site, provoque toujours la même réaction chez un client : la panique. Il pense avoir perdu du contenu. En réalité, dans la quasi-totalité des cas, rien n’est perdu : le bloc existe toujours dans le code stocké du gabarit, seul son moteur de rendu a disparu.
Ce cas est apparu après la désactivation, par un client pressé, d’une extension d’annuaire professionnel qui fournissait un bloc personnalisé affichant une liste de partenaires sur la page d’accueil. Sans prévenir personne, il a simplement décoché l’extension depuis l’administration, pensant qu’elle ne servait plus.
Symptôme : un gabarit qui refuse de s’afficher normalement
Le gabarit concerné (une page d’accueil personnalisée dans l’éditeur de site) affiche, à l’ouverture de l’éditeur, un bandeau d’avertissement au-dessus de la zone concernée, avec deux boutons : « Convertir en blocs classiques » et « Conserver en HTML ». Côté visiteur, le bloc disparaît purement et simplement du rendu public, sans message d’erreur visible, ce qui rend le problème difficile à repérer sans ouvrir l’éditeur.
Diagnostic : retrouver quel bloc a disparu
Le nom technique du bloc manquant apparaît dans l’attribut du commentaire HTML qui délimite le bloc dans le contenu stocké. En affichant le code source du gabarit (bouton « Code » dans le menu des options de l’éditeur, ou consultation directe de l’entrée en base de données), on retrouve une ligne du type :
<!-- wp:annuaire-partenaires/liste {"nombre":6} /-->Le préfixe annuaire-partenaires/ indique le nom de domaine du bloc, généralement identique au slug de l’extension qui le fournissait. Une recherche rapide dans le répertoire des extensions, ou dans l’historique des extensions installées si l’on y a accès, confirme l’origine du problème : l’extension correspondante a bien été désactivée récemment.
Confirmer l’hypothèse avec la console du navigateur
Dans l’éditeur, la console JavaScript du navigateur affiche généralement un avertissement explicite lors du chargement du gabarit concerné, signalant qu’un type de bloc référencé n’est pas enregistré côté client. Cet avertissement, bien que technique, confirme sans ambiguïté qu’il ne s’agit pas d’une corruption de données mais bien d’un bloc dont le moteur de rendu est absent.
Correctif : trois options selon le contexte
Une fois l’origine confirmée, trois issues sont possibles, à choisir selon la situation du client :
- Réactiver l’extension si elle est toujours nécessaire : c’est la solution la plus rapide et la plus sûre, le bloc retrouve immédiatement son rendu normal.
- Remplacer le bloc par son équivalent natif si l’extension n’est plus souhaitée : on reconstruit manuellement l’affichage avec une Query Loop et des champs personnalisés, puis on supprime l’ancien bloc du gabarit.
- Convertir en HTML personnalisé via le bouton proposé par l’éditeur, ce qui fige le rendu tel qu’il apparaissait avant la désactivation, sans conserver la logique dynamique du bloc d’origine.
Le troisième choix mérite une mise en garde : la conversion en HTML personnalisé fige un instantané du rendu, ce qui signifie que si le bloc affichait une liste dynamique de partenaires, celle-ci ne se mettra plus jamais à jour automatiquement après la conversion.
Prévention : éviter que le problème se reproduise
La cause profonde de cet incident n’est pas technique mais organisationnelle : un client peut désactiver une extension sans mesurer son impact sur les gabarits. Quelques mesures limitent le risque :
- Documenter, dans un fichier accessible au client, la liste des extensions qui fournissent des blocs utilisés dans les gabarits critiques.
- Ajouter un commentaire explicite dans la description de l’extension, côté administration, rappelant qu’elle est utilisée par tel ou tel gabarit.
- Restreindre, si le contexte le permet, la capacité à désactiver des extensions au seul rôle administrateur technique plutôt qu’à tous les éditeurs.
Un filet de sécurité côté code
Pour les blocs critiques fournis par une extension maison, un enregistrement défensif avec register_block_type() accompagné d’un rendu de repli minimal évite l’avertissement brutal, en affichant un message neutre plutôt qu’un blocage complet de l’éditeur :
register_block_type( __DIR__ . '/build/liste-partenaires', array(
'render_callback' => function( $attributs ) {
if ( ! function_exists( 'obtenir_partenaires_actifs' ) ) {
return '<p>Contenu temporairement indisponible.</p>';
}
return obtenir_partenaires_actifs( $attributs );
},
) );
Un avertissement rouge dans l’éditeur fait peur au client bien plus qu’il ne devrait : la première chose à faire est de le rassurer sur l’absence de perte de données, avant même de corriger le problème.
En résumé
« Ce modèle contient un bloc non enregistré » signale presque toujours une extension désactivée, pas une perte de contenu. Le diagnostic passe par le préfixe du bloc dans le code source du gabarit, et le correctif dépend du contexte : réactiver, remplacer, ou convertir en HTML figé en connaissance de cause.
