« J’ai copié content.php dans mon thème enfant, mais la page continue d’afficher visiblement l’ancienne version. » Ce constat, fréquent chez les développeurs qui découvrent les thèmes enfants, cache une nuance importante : tous les fichiers d’un thème ne se résolvent pas selon la même règle de priorité entre parent et enfant.
La règle générale, simple en apparence
Pour les fichiers de template principaux comme single.php, page.php ou archive.php, WordPress applique une règle claire : si le fichier existe dans le thème enfant, il est utilisé en priorité ; sinon, WordPress retombe automatiquement sur la version du thème parent. C’est cette règle simple qui laisse penser, à tort, que toute copie d’un fichier dans l’enfant suffit systématiquement à en prendre le contrôle.
Le cas particulier de get_template_part()
La confusion apparaît le plus souvent avec les fragments de template inclus via get_template_part(), une fonction qui suit bien la même logique de résolution enfant puis parent, mais dont le chemin exact attendu doit correspondre précisément à ce qui est appelé dans le code.
// Appelé depuis single.php du thème parent
get_template_part( 'template-parts/content', 'single' );
Cet appel cherche, dans l’ordre, template-parts/content-single.php dans le thème enfant, puis dans le thème parent. Si le fichier copié dans l’enfant se trouve à un chemin légèrement différent, par exemple directement à la racine plutôt que dans le sous-dossier template-parts, WordPress ne le trouve jamais et retombe silencieusement sur la version du parent, sans avertissement.
Le cas d’un fichier inclus par require ou include
Un autre piège, plus subtil, survient quand le thème parent inclut lui-même certains fichiers directement en PHP, via require ou include, plutôt que via les fonctions de résolution de WordPress comme get_template_part() ou locate_template().
// Dans single.php du thème parent, PROBLÉMATIQUE pour un thème enfant
require get_template_directory() . '/inc/bloc-partage.php';
Ici, get_template_directory() pointe toujours vers le dossier du thème parent, quel que soit le thème enfant actif. Copier inc/bloc-partage.php dans le thème enfant n’a alors strictement aucun effet : le parent continue d’inclure sa propre version en dur, sans jamais consulter l’enfant. Seule une fonction comme locate_template(), conçue pour vérifier l’enfant avant le parent, permet de contourner ce comportement, à condition que le thème parent ait été écrit pour l’utiliser dès le départ.
Comment vérifier la bonne résolution
- Confirmer le chemin exact attendu en lisant le code source du thème parent, pas en devinant d’après le nom du fichier affiché.
- Ajouter temporairement un commentaire visible dans la copie du fichier enfant pour confirmer, sans ambiguïté, laquelle des deux versions s’affiche réellement.
- Vérifier si le fichier concerné est inclus via une fonction de résolution de WordPress ou via un
requiredirect, deux comportements radicalement différents.
Une distinction à connaître avant tout audit de thème enfant
Cette distinction explique pourquoi certains thèmes parents se déclarent explicitement « compatibles enfant » pour une liste précise de fichiers, quand d’autres, moins bien conçus, ne permettent une surcharge complète que sur une poignée de templates principaux, laissant le reste totalement figé côté parent.
Avant de promettre à un client qu’un fichier peut être personnalisé sans toucher au thème parent, vérifier d’abord, dans le code source du parent, comment ce fichier précis est réellement inclus.
En résumé
Copier un fichier dans un thème enfant ne garantit sa prise en compte que si le thème parent l’inclut via une fonction de résolution compatible, avec un chemin exactement identique. Comprendre cette nuance évite bien des recherches infructueuses sur un fichier qui semble ignoré sans raison apparente.
