# Template parts et éditeur de site WordPress : le mode d’emploi complet > Comment fonctionne le bloc Template Part, où placer header.html et footer.html, et comment l'éditeur de site de WordPress 6.0 exploite ces zones réutilisables. - Auteur : Clément Hadrot - Publié le : 2022-07-20 - Mis à jour le : 2022-07-20 - Catégorie : Thèmes - URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/template-parts-editeur-site-mode-emploi/ ## L’essentiel - Un template part est un fragment HTML réutilisable stocké en base ou en fichier - wp_template_part est le type de contenu qui les gère - L'éditeur de site de WP 6.0 les rend modifiables visuellement Depuis que la Full Site Editing s'est stabilisée avec WordPress 6.0 sorti en mai dernier, une question revient souvent dans les échanges avec mes clients : comment modifier l'en-tête ou le pied de page sans toucher au code du thème ? La réponse tient en trois mots : les **template parts**. Ce mécanisme, disponible depuis WordPress 5.9 et largement enrichi dans l'éditeur de site de la version 6.0, permet de découper un gabarit en zones réutilisables, modifiables visuellement, et partagées entre tous les templates qui les appellent. Voyons comment ça fonctionne concrètement, du fichier source jusqu'à l'interface de l'éditeur. ## Qu'est-ce qu'un template part, exactement Un template part est un fragment de contenu composé de blocs Gutenberg, destiné à être inséré dans plusieurs gabarits différents. Les deux exemples les plus courants sont l'en-tête et le pied de page, mais rien n'empêche de créer un template part pour une bannière promotionnelle, une barre latérale, ou un bloc d'appel à l'action répété sur plusieurs pages. ## Où placer header.html et footer.html Dans un thème bloc, les template parts par défaut vivent dans le dossier `parts/` à la racine du thème, sous forme de fichiers HTML contenant des commentaires de bloc, exactement comme les fichiers du dossier `templates/`. > L'essentiel à retenir : Un template part est un fragment HTML réutilisable stocké en base ou en fichier ; wp_template_part est le type de contenu qui les gère ; L'éditeur de site de WP 6.0 les rend modifiables visuellement ``` mon-theme/ ├── theme.json ├── templates/ │ └── index.html └── parts/ ├── header.html └── footer.html ``` Pour qu'un template soit reconnu et proposé automatiquement dans l'éditeur, il faut également le déclarer dans `theme.json`, sous la clé `templateParts` : ``` { "templateParts": [ { "name": "header", "title": "En-tête", "area": "header" }, { "name": "footer", "title": "Pied de page", "area": "footer" } ] } ``` La propriété `area` indique à WordPress la fonction sémantique du fragment : `header`, `footer`, ou `uncategorized` pour tout le reste. Cela conditionne notamment la balise HTML générée automatiquement autour du contenu quand on insère le bloc dans l'éditeur. ## Le bloc Template Part dans l'éditeur Une fois ces fichiers en place, un utilisateur peut insérer le bloc **Template Part** depuis l'inserteur de blocs, choisir parmi les zones déclarées, et le fragment s'affiche directement dans la page en cours d'édition. Dans un fichier de gabarit, on l'appelle avec le commentaire de bloc suivant : ``` ``` L'attribut `slug` correspond au nom du fichier sans extension, et `tagName` permet de choisir la balise HTML englobante, ici `header` plutôt que la `div` par défaut. C'est une bonne pratique pour conserver une structure sémantique propre, dans la continuité de ce qu'on ferait sur un thème accessible. ## wp_template_part, le type de contenu sous le capot Techniquement, chaque template part activé dans l'éditeur devient une entrée du type de contenu personnalisé `wp_template_part`, stockée en base de données comme n'importe quel article. Tant que l'utilisateur n'a pas modifié le fragment depuis l'éditeur de site, WordPress continue de lire directement le fichier HTML du thème. Dès qu'une modification est enregistrée via l'interface, une entrée est créée en base et prend le pas sur le fichier source, exactement selon le même mécanisme que les templates complets. Ce comportement, hérité du système de résolution de templates introduit avec la Full Site Editing, permet de livrer un thème avec des valeurs par défaut solides tout en laissant l'utilisateur final personnaliser librement son en-tête ou son pied de page sans toucher au code. - Fichier du thème non modifié : WordPress sert directement `parts/header.html` - Fragment personnalisé via l'éditeur : WordPress sert la version stockée en base, de type `wp_template_part` - Possibilité de revenir à la version du thème via l'option « Effacer la personnalisation » dans l'éditeur de site ## L'éditeur de site : modifier visuellement ces zones L'éditeur de site, accessible depuis **Apparence → Éditeur** sur un thème bloc, propose une entrée dédiée aux template parts, listant tous ceux déclarés dans `theme.json`. On peut y accéder directement, indépendamment d'un template complet, pour retoucher uniquement l'en-tête par exemple, avec un aperçu isolé du fragment. Cette séparation entre templates complets et template parts est l'un des grands apports de l'éditeur de site version 6.0 : elle rend beaucoup plus clair ce qui appartient à la structure globale du site et ce qui est un fragment réutilisable, une distinction qui manquait cruellement aux premières versions expérimentales de la Full Site Editing en 2021. > Mon conseil : découpez toujours vos template parts par fonction, pas par page. Un en-tête unique réutilisé partout est plus facile à maintenir que trois en-têtes légèrement différents dupliqués dans plusieurs templates, même si la tentation existe au début d'un projet. ## En résumé Les template parts structurent un thème bloc en zones réutilisables, gérées par le type de contenu `wp_template_part`, et rendues modifiables visuellement grâce à l'éditeur de site. Bien les organiser dès la conception du thème, en les déclarant proprement dans `theme.json` et en leur attribuant la bonne `area` sémantique, facilite énormément la vie des utilisateurs finaux qui souhaitent personnaliser leur site sans écrire une ligne de code.