# Templates en base contre fichiers du thème : qui gagne et comment réconcilier

> Comment fonctionnent les wp_template et wp_template_part enregistrés en base, leur priorité sur les fichiers du thème, et comment les réinitialiser ou les exporter proprement.

- Auteur : Clément Hadrot
- Publié le : 2025-05-06
- Mis à jour le : 2025-05-06
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/templates-base-vs-fichiers-theme-reconciliation/

## L’essentiel

- Un template modifié dans l'éditeur est copié en base, pas dans le fichier
- Le contenu en base a priorité totale sur le fichier du thème correspondant
- L'export vers le thème remet le fichier et la base en cohérence

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 |

> L'essentiel à retenir : Un template modifié dans l'éditeur est copié en base, pas dans le fichier ; Le contenu en base a priorité totale sur le fichier du thème correspondant ; L'export vers le thème remet le fichier et la base en cohérence

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

1. 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_template` en base via WP-CLI.
2. 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.
3. 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.