« Modèle introuvable ». C’est le seul message affiché par l’éditeur de site après le passage d’un client d’un premier thème bloc à un second, plus abouti, sur un site vitrine de cabinet de conseil. La page d’accueil, personnalisée avant la migration, refusait de s’ouvrir dans le Site Editor, sans plus de détails que ce message générique.
Ce billet retrace le diagnostic d’un identifiant de template orphelin en base de données, symptôme classique après un changement de thème bloc, et la procédure de nettoyage appliquée. La migration de contenu au sens large et la compatibilité des extensions tierces sortent du périmètre de ce billet : il ne s’agit ici que du cas précis du template introuvable.
Symptôme : un écran qui refuse de s’ouvrir
Le clic sur « Modifier » depuis la page d’accueil dans l’administration renvoyait vers l’éditeur de site avec le message d’erreur, sans possibilité d’afficher le moindre bloc. La page elle-même s’affichait normalement côté public, ce qui excluait d’emblée une corruption du contenu : le problème se situait dans la résolution du template associé, pas dans le contenu de la page.
Premier réflexe : vérifier que le thème bloc nouvellement activé possède bien un fichier templates/front-page.html ou templates/home.html. C’était le cas. Le thème n’était donc pas en cause directement.
Diagnostic : un post wp_template orphelin
WordPress enregistre en base, dans le type de contenu wp_template, toute personnalisation d’un template effectuée depuis l’éditeur de site. Ce post porte un post_name composé du slug du thème et du nom du fichier de template, par exemple ancien-theme//front-page. Après le changement de thème, ce post restait présent en base, mais son post_name référençait encore l’ancien thème.
wp post list --post_type=wp_template --fields=ID,post_name,post_status
La commande WP-CLI a révélé l’incohérence : un post wp_template avec pour post_name ancien-theme//front-page, alors que le thème actif était désormais nouveau-theme-bloc. WordPress cherchait un template personnalisé pour le thème actif, ne le trouvait pas sous ce nom, et l’éditeur de site échouait à résoudre correctement le contenu à afficher, générant le message d’erreur générique.
Correctif : renommer ou supprimer le post orphelin
Deux options s’offraient ici. La première, renommer le post_name pour qu’il corresponde au nouveau thème, préserve les personnalisations effectuées avant la migration. La seconde, supprimer purement le post, revient à repartir du template par défaut du nouveau thème.
- Identifier l’ID du post orphelin via la commande WP-CLI précédente.
- Décider si les personnalisations de l’ancien template méritent d’être conservées : dans ce cas précis, le client souhaitait repartir du template par défaut du nouveau thème, plus abouti visuellement.
- Supprimer le post via
wp post delete <ID> --force, ou le renommer via une requête SQL directe sur la tablewp_postssi la conservation est souhaitée.
UPDATE wp_posts
SET post_name = 'nouveau-theme-bloc//front-page'
WHERE ID = 4821;
Après cette correction, l’écran de l’éditeur de site s’est ouvert normalement, affichant soit le template par défaut du nouveau thème, soit la version renommée selon l’option choisie.
Prévention : un nettoyage systématique avant migration
- Avant toute migration de thème bloc, lister les templates personnalisés existants avec la commande WP-CLI présentée plus haut.
- Décider, template par template, s’il faut les conserver en les renommant ou les purger volontairement.
- Vérifier après migration que chaque écran de type page, article et archive s’ouvre correctement dans le Site Editor avant de livrer au client.
Un message d’erreur générique dans l’éditeur de site mérite toujours une vérification côté base de données avant de suspecter le thème lui-même.
Pour aller plus loin
Ce type d’incohérence illustre une caractéristique propre à l’architecture de l’éditeur de site : les personnalisations de templates sont des contenus en base, liés à un thème par convention de nommage, et non par une relation formelle en base de données. Toute migration de thème bloc devrait donc systématiquement inclure une étape d’audit des posts wp_template et wp_template_part, pour éviter ce genre de mauvaise surprise après livraison.
