# « Modèle introuvable » après une migration de thème bloc : diagnostic

> Diagnostic d'un identifiant de template orphelin en base après changement de thème bloc, et procédure de nettoyage pas à pas.

- Auteur : WordPress Développement
- Publié le : 2023-04-04
- Mis à jour le : 2023-04-04
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/modele-introuvable-migration-theme-bloc/

## L’essentiel

- L'erreur vient d'un post wp_template orphelin, pas du thème
- wp post list --post_type=wp_template révèle l'incohérence
- Nettoyage ciblé sans toucher au contenu éditorial

« 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.

> L'essentiel à retenir : L'erreur vient d'un post wp_template orphelin, pas du thème ; wp post list --post_type=wp_template révèle l'incohérence ; Nettoyage ciblé sans toucher au contenu éditorial

## 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.

1. Identifier l'ID du post orphelin via la commande WP-CLI précédente.
2. 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.
3. Supprimer le post via `wp post delete <ID> --force`, ou le renommer via une requête SQL directe sur la table `wp_posts` si 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.