Une page affiche le gabarit choisi dans l’aperçu, puis revient au modèle générique une fois publiée. Aucun message d’erreur, aucune trace dans les journaux : le contenu s’affiche, mais avec une mise en page différente de celle prévue. Ce comportement déroute souvent parce qu’il ne produit aucun avertissement visible côté administration.
Le mécanisme derrière ce repli est pourtant assez simple à isoler une fois qu’on sait où chercher. Il tient en trois points : la façon dont WordPress mémorise le choix d’un gabarit sur un contenu, la façon dont il le résout au moment de l’affichage, et ce qui se passe quand cette résolution échoue.
Symptôme observé
Le cas typique : une page a été associée à un gabarit personnalisé du thème (par exemple un modèle « pleine largeur » ou « sans en-tête »). Cette association a été faite depuis le panneau latéral de l’éditeur, dans la section consacrée au modèle de page. Tout fonctionne pendant plusieurs semaines, puis un jour la page s’affiche avec l’en-tête et le pied de page standards, comme n’importe quelle autre page du site.
Ce qui trompe le plus : rien n’a été touché dans le contenu de la page elle-même. Le changement vient d’ailleurs.
Diagnostic
Le choix de gabarit d’un article ou d’une page est stocké dans une métadonnée de post, historiquement _wp_page_template. Pour un thème à blocs, cette valeur contient l’identifiant complet du gabarit, sous la forme nom-du-theme//slug-du-gabarit. Au moment de l’affichage, WordPress tente de résoudre ce gabarit via la fonction get_block_template(), qui va chercher un enregistrement correspondant, soit en base (un gabarit personnalisé enregistré dans le type de contenu wp_template), soit dans les fichiers HTML du thème.
Si cette résolution échoue — parce que le fichier de gabarit a été renommé, supprimé, ou que le thème actif a changé sans que la page ait été réassignée — la fonction ne renvoie rien d’exploitable. WordPress ne lève pas d’erreur fatale : il retombe silencieusement sur la hiérarchie de templates habituelle, celle qui détermine le gabarit à partir du type de contenu (page, article, archive) plutôt que de la préférence explicite enregistrée sur ce contenu précis.
Où se situe la vraie cause dans la pratique
Trois origines reviennent le plus souvent :
- Un gabarit personnalisé a été renommé depuis l’éditeur de site, ce qui change son slug sans mettre à jour les pages qui le référencent.
- Le thème a été changé, ou une variante enfant a été activée, et le nouveau thème ne propose pas de gabarit portant le même identifiant.
- Un gabarit exporté puis réimporté (via l’export de thème à blocs) a repris un slug légèrement différent, par exemple à cause d’un suffixe numérique ajouté en cas de conflit.
Dans les trois cas, la métadonnée de la page reste inchangée : elle pointe toujours vers l’ancien identifiant. C’est la cible qui a disparu, pas la référence.
Correctif
La vérification la plus directe consiste à rouvrir la page concernée, à regarder dans le panneau des réglages de page quel gabarit est actuellement sélectionné, puis à comparer cette valeur avec la liste des gabarits réellement disponibles dans l’éditeur de site. Si le gabarit attendu n’apparaît plus dans cette liste, il faut soit le recréer sous le même identifiant, soit réassigner la page vers le gabarit qui existe désormais sous un nom différent.
Pour un diagnostic plus systématique sur un site avec de nombreuses pages, une requête directe sur la table de métadonnées permet de retrouver toutes les valeurs de _wp_page_template en circulation :
wp db query "SELECT post_id, meta_value FROM wp_postmeta WHERE meta_key = '_wp_page_template'"Cette liste peut ensuite être confrontée à la sortie de wp template list, qui énumère les gabarits effectivement résolus par le thème actif.
Prévention
Deux réflexes limitent ce risque à l’avenir : éviter de renommer un gabarit une fois qu’il est assigné à des contenus publiés, et vérifier après tout changement de thème (ou de thème enfant) que les gabarits personnalisés utilisés existent bien sous le même identifiant dans le nouveau thème. Un export du thème avant modification, via wp_generate_block_templates_export_file() côté code ou l’option d’export de l’éditeur de site côté interface, donne une référence à laquelle revenir en cas de doute.
Sur ce point précis, mieux vaut traiter le slug d’un gabarit comme une interface stable : une fois publié et utilisé, on ne le renomme plus, on en crée un nouveau si besoin.
En résumé
Un gabarit qui « disparaît » sans message d’erreur n’est presque jamais un bug du cœur de WordPress : c’est une référence orpheline entre la métadonnée d’une page et un gabarit qui n’existe plus sous ce nom précis. Le repli vers le modèle par défaut est un comportement voulu, pensé pour éviter qu’une page reste sans affichage du tout. Le retrouver rapidement demande simplement de savoir où regarder : la métadonnée du contenu d’un côté, la liste des gabarits résolus par le thème de l’autre.
