Un client nous a signalé une régression étrange : le template d’archive de son site, que nous avions livré avec une structure précise, affichait une mise en page différente après une modification qu’il avait faite lui-même depuis l’éditeur de site trois mois plus tôt. Le fichier archive.html du thème, lui, n’avait pas bougé d’un octet. La cause tient au fonctionnement propre des templates enregistrés en base de données, un mécanisme que beaucoup de développeurs découvrent après coup, souvent dans ce type de situation.
Ce guide explique ce mécanisme et la façon de le réconcilier, sans entrer dans le détail du workflow d’agence global autour de la synchronisation entre environnements, qui reste un sujet distinct.
Comment un template atterrit en base
Quand une personne modifie un template depuis l’éditeur de site — même un simple déplacement de bloc — WordPress ne réécrit jamais le fichier HTML du thème. Il crée ou met à jour un contenu de type wp_template en base de données, avec un slug identique au nom du fichier d’origine, et c’est ce contenu en base qui est servi en priorité à chaque affichage suivant.
wp post list --post_type=wp_template --allow-root
+----+---------------------+-------------+----------------------+
| ID | post_title | post_name | post_status |
+----+---------------------+-------------+----------------------+
| 142| Archive | archive | publish |
+----+---------------------+-------------+----------------------+La commande WP-CLI wp post list --post_type=wp_template révèle immédiatement ces surcharges, ce qui en fait le premier réflexe de diagnostic face à un template qui ne correspond plus au fichier du thème.
Comprendre la priorité exacte
Le mécanisme de résolution suit un ordre précis : WordPress cherche d’abord un wp_template en base dont le slug correspond, associé au thème actif via un champ theme stocké sur le post. Ce n’est que si aucune entrée en base ne correspond que le fichier du thème (parent ou enfant) est utilisé.
| Source | Priorité |
|---|---|
| wp_template en base, associé au thème actif | La plus haute |
| Fichier dans le thème enfant | Intermédiaire |
| Fichier dans le thème parent | La plus basse |
Réinitialiser un template modifié en base
Depuis l’éditeur de site, la liste des templates affiche une option de réinitialisation sur tout template qui possède une entrée personnalisée en base : elle supprime le wp_template correspondant et fait retomber l’affichage sur le fichier d’origine du thème. C’est l’opération que nous avons appliquée chez le client, une fois la cause identifiée, en accord avec lui pour repartir de la version livrée initialement.
Exporter un template modifié vers le thème
À l’inverse, quand la modification faite en base doit devenir la nouvelle version officielle du thème — ce qui était en réalité le souhait du client une fois la situation expliquée — WordPress propose une fonctionnalité d’export : l’éditeur de site génère un fichier ZIP contenant les templates et template parts modifiés, prêt à être intégré dans le dépôt du thème.
wp-content/themes/mon-theme/
templates/
archive.html ← remplacé par le contenu exportéUne fois ce fichier remplacé dans le dépôt et déployé, l’entrée wp_template en base devient redondante avec le fichier : nous recommandons de la supprimer via la réinitialisation décrite plus haut, pour que la base et le dépôt de code restent la seule source de vérité, sans double stockage silencieux.
Notre procédure pour éviter la récurrence
- Après toute session de travail du client dans l’éditeur de site, vérifier périodiquement (mensuellement sur nos contrats de maintenance) la présence de
wp_templateen base via WP-CLI. - Pour chaque entrée trouvée, décider avec le client : réinitialiser si la modification était accidentelle, exporter vers le dépôt si elle doit être conservée.
- Documenter dans notre outil de suivi de projet toute décision d’export, pour garder une trace de l’origine de chaque évolution de template.
Ne considérez jamais qu’un fichier de template inchangé dans le dépôt garantit un rendu inchangé en production. La seule vérification fiable reste d’interroger directement la base via WP-CLI, le code du thème ne raconte qu’une partie de l’histoire.
En résumé
Les templates modifiés depuis l’éditeur de site vivent en base de données, avec une priorité totale sur les fichiers du thème, jusqu’à réinitialisation ou export explicite. Cette mécanique, invisible tant qu’on ne la connaît pas, explique la majorité des décalages entre ce que montre le dépôt de code et ce qu’affiche réellement le site en production.
