# get_block_template() partage un en-tête entre thème et React

> Éviter de dupliquer la structure de l'en-tête entre l'administration et un front headless, avec un snippet commenté autour de get_block_template et ses variantes selon le site.

- Auteur : Clément Hadrot
- Publié le : 2024-07-04
- Mis à jour le : 2024-07-04
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/get-block-template-partage-en-tete-theme-react/

## L’essentiel

- get_block_template récupère un template part enregistré comme entité wp_template_part
- do_blocks transforme ensuite ses blocs en HTML réutilisable côté API
- La même source sert à l'aperçu admin et au rendu du front React

`get_block_template( $id, 'wp_template_part' )`. Cette fonction, disponible depuis la mise en place de l'édition complète de site en WordPress 5.9, permet de récupérer un template part enregistré, avec son contenu de blocs bruts. C'est elle qui a permis de résoudre un problème classique sur un site de location de salles de réception événementielles : l'en-tête du site (logo, menu, bouton de contact) était défini deux fois, une fois dans le thème block pour l'administration, une fois recopié en JSX dans le composant d'en-tête du front React.

La duplication n'était pas volontaire : au lancement du projet, l'équipe front avait simplement recopié la structure visuelle de l'en-tête telle qu'elle apparaissait dans l'éditeur de site, faute de disposer d'un moyen simple de la récupérer dynamiquement depuis l'API. Chaque ajustement du menu, décidé par l'équipe marketing dans l'éditeur de site, devait ensuite être répercuté manuellement dans le code du composant React, une source d'erreur régulière.

## Récupérer le template part et non sa capture d'écran

La solution a consisté à exposer, via un endpoint REST personnalisé, le rendu HTML du template part « header », obtenu en récupérant son entité avec `get_block_template()` puis en transformant ses blocs en HTML avec la fonction `do_blocks()`, celle-là même utilisée par le cœur de WordPress pour afficher le contenu d'un article.

```
add_action( 'rest_api_init', function () {
    register_rest_route( 'salle-reception/v1', '/en-tete', array(
        'methods'  => 'GET',
        'callback' => function () {
            $template = get_block_template( get_stylesheet() . '//header', 'wp_template_part' );

            if ( ! $template ) {
                return new WP_Error( 'template_introuvable', 'Le template part header est introuvable', array( 'status' => 404 ) );
            }

            return array(
                'html' => do_blocks( $template->content ),
            );
        },
        'permission_callback' => '__return_true',
    ) );
} );
```

## Ce que le front en fait

Le composant d'en-tête du front React ne contient plus de structure figée : il récupère ce HTML au moment du build et l'injecte dans une zone dédiée, avec un minimum de styles globaux partagés entre le thème et le front pour que le rendu reste cohérent visuellement.

> L'essentiel à retenir : get_block_template récupère un template part enregistré comme entité wp_template_part ; do_blocks transforme ensuite ses blocs en HTML réutilisable côté API ; La même source sert à l'aperçu admin et au rendu du front React

```
async function chargerEnTete() {
  const reponse = await fetch('https://admin.salle-reception.fr/wp-json/salle-reception/v1/en-tete');
  const donnees = await reponse.json();
  return donnees.html;
}
```

Un point de vigilance a rapidement émergé : le HTML retourné par `do_blocks()` contient les classes générées par les blocs natifs (`wp-block-navigation`, `wp-block-site-logo`), qu'il a fallu styliser côté front avec les feuilles de styles issues du même thème block, plutôt que de les réécrire à la main dans un fichier CSS séparé du front.

### Les variantes selon le site

- Sur le site principal, l'en-tête complet est récupéré, avec menu et bouton de réservation
- Sur une page d'atterrissage isolée liée à une campagne publicitaire, seul le logo est récupéré depuis un template part distinct, plus léger, pour ne pas distraire le visiteur du formulaire de contact
- Sur l'espace professionnel réservé aux traiteurs partenaires, un template part encore différent inclut un lien vers leur portail dédié, absent de l'en-tête public

> Un en-tête recopié à la main dans un composant front n'est jamais vraiment synchronisé avec son original : il est synchronisé au moment où quelqu'un s'en souvient, ce qui, avec le temps, finit toujours par ne plus être vrai.

## Ce que cette approche ne couvre pas

Le CSS n'est volontairement pas traité dans cet article : la question de la synchronisation des styles entre le thème block et le front React mériterait un traitement séparé, tant les approches possibles varient selon que l'équipe choisit de partager littéralement un fichier de styles ou de le reconstruire fidèlement côté front.

## Le bilan

Depuis la mise en place de cet endpoint, l'équipe marketing modifie le menu directement dans l'éditeur de site WordPress, et le changement apparaît sur le front à la prochaine reconstruction programmée, sans qu'aucun développeur n'ait à intervenir sur le code du composant d'en-tête. La source de vérité est redevenue unique.

## Pour aller plus loin

Ce mécanisme s'applique à n'importe quel template part défini dans un thème block : pied de page, bannière d'alerte, ou tout élément structurel récurrent qu'une équipe marketing souhaite pouvoir modifier sans dépendre d'un déploiement de code côté front. Le principe reste le même : ne jamais recopier une structure qui peut être récupérée dynamiquement.