Différence entre un template part classique et celui du FSE

Avec l’arrivée du Full Site Editing (FSE) dans WordPress, la gestion des template-parts (parties de modèle) a évolué de manière significative.

Alors que les thèmes classiques utilisaient des fichiers PHP et des appels comme get_template_part() pour inclure des parties spécifiques du site, le FSE repose sur des fichiers HTML modifiables et intégrés directement à l’éditeur de blocs Gutenberg.

Structure et fonctionnement dans un thème FSE

Fichier HTML : les template-parts du FSE sont des fichiers .html situés dans le répertoire /block-template-parts/ du thème.
Utilisation dans l’éditeur : ces parties peuvent être créées, modifiées et organisées directement via l’éditeur de site dans WordPress (Gutenberg).
Intégration avec les blocs : chaque template-part est un “bloc” modifiable, ce qui permet aux utilisateurs de personnaliser la structure et le contenu sans écrire de code.
Définition dans theme.json : le fichier theme.json du thème peut spécifier les template-parts (par exemple, header, footer) pour qu’ils soient disponibles dans l’éditeur.

Déclaration :

Création du template-part : block-template-parts/header.html

<!-- wp:group -->
<div class="wp-block-group">
  <h1>Header Content</h1>
</div>
<!-- /wp:group -->

Appel dans un modèle : block-templates/page.html

<!-- wp:template-part {"slug":"header","theme":"mon-theme","tagName":"header"} /-->

Déclaration du template-part pour qu’il soit reconnu et utilisable dans l’éditeur de site : theme.json

{
  "version": 2,
  "settings": {
    "templateParts": {
      "header": {
        "title": "Header",
        "area": "header"
      }
    }
  }
}

La clé "templateParts" informe WordPress que ce fichier est une partie de modèle.

Le champ "area": "header" spécifie l’emplacement du template-part (parmi header, footer, ou uncategorized).

Les différences principales

Aspect	Template-parts classique	Template-parts FSE
Type de fichier	PHP	HTML
Répertoire	`template-parts/`	`block-template-parts/`
Modification utilisateur	Non, nécessite un développeur	Oui, via l’éditeur de site
Appel	PHP (`get_template_part()`)	Bloc Gutenberg (`wp:template-part`)
Compatibilité	Classique (non-Gutenberg)	Full Site Editing et blocs

Avantages

Les utilisateurs peuvent personnaliser les template-parts sans intervention d’un développeur, directement depuis l’interface WordPress.
Compatible avec le système de blocs, ce qui favorise la flexibilité et la créativité.
Les template-parts sont stockés dans la base de données après modification via l’éditeur, permettant des personnalisations sauvegardées indépendamment des fichiers du thème.

Limites

Moins de contrôle direct pour les développeurs, car les utilisateurs peuvent modifier ces parties librement.
Les modifications faites via l’éditeur peuvent être écrasées si le thème est réinitialisé ou si les fichiers sont restaurés.

Où et comment implanter les template-parts ?

Thème classique (PHP)

index.php

<?php get_header(); ?>

<main>
    <?php get_template_part('loop'); ?>
</main>

<?php get_footer(); ?>

header.php

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
    <meta charset="<?php bloginfo('charset'); ?>">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <?php wp_head(); ?>
</head>
<body <?php body_class(); ?>>
<header>
    <h1><?php bloginfo('name'); ?></h1>
</header>

loop.php

<?php if (have_posts()) : ?>
    <?php while (have_posts()) : the_post(); ?>
        <article>
            <h2><?php the_title(); ?></h2>
            <div><?php the_content(); ?></div>
        </article>
    <?php endwhile; ?>
<?php else : ?>
    <p>Aucun article trouvé.</p>
<?php endif; ?>

footer.php

<footer>
    <p>&copy; <?php echo date('Y'); ?> - <?php bloginfo('name'); ?></p>
    <?php wp_footer(); ?>
</footer>
</body>
</html>

Thème FSE (HTML)

block-templates/index.html

<!-- wp:template-part {"slug":"header","tagName":"header","theme":"mon-theme"} /-->

<!-- wp:group -->
<main>
    <!-- wp:post-template -->
    <article>
        <!-- wp:post-title /-->
        <!-- wp:post-content /-->
    </article>
    <!-- /wp:post-template -->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer","theme":"mon-theme"} /-->

block-template-parts/header.html

<!-- wp:group -->
<div class="wp-block-group">
    <header>
        <h1>Site Title</h1>
    </header>
</div>
<!-- /wp:group -->

block-templates/footer.html

<!-- wp:group -->
<div class="wp-block-group">
    <footer>
        <p>&copy; <?php echo date('Y'); ?> - <?php bloginfo('name'); ?></p>
    </footer>
</div>
<!-- /wp:group -->

theme.json

{
  "version": 2,
  "settings": {
    "templateParts": {
      "header": {
        "title": "Header",
        "area": "header"
      },
      "footer": {
        "title": "Footer",
        "area": "footer"
      }
    }
  }
}

Pourquoi WordPress utilise un fichier de configuration avec JSON et non YAML ?

Standardisation WordPress : JSON est déjà utilisé dans WordPress pour d’autres configurations et interfaces REST API.
Compatibilité avec JavaScript : WordPress s’oriente de plus en plus vers JavaScript (notamment via Gutenberg). JSON est un format natif pour JavaScript, ce qui simplifie les intégrations.
Simplicité : JSON est plus largement adopté et compatible avec la majorité des outils WordPress.

La nouvelle syntaxe

 commence la boucle.

Les blocs enfants (wp:post-title, wp:post-content, etc.) définissent les informations à afficher pour chaque article.

 termine la boucle.

Les avantages de cette nouvelle syntaxe

Éditeur visuel : les utilisateurs peuvent personnaliser les éléments directement depuis l’éditeur de site en mode code.L’éditeur Gutenberg permet de passer en mode code pour manipuler directement la structure HTML des blocs. Les parties essentielles d’un thème, telles que le header, le footer ou des modèles complets de page, peuvent être conçues directement depuis l’éditeur de site. Ces éléments sont enregistrés dans la base de données, rendant leur sauvegarde dynamique.
Standardisation : réduction des erreurs de syntaxe, car WordPress gère les structures complexes.
Flexibilité : possibilité d’ajouter d’autres blocs (images, boutons, etc.) dans la boucle sans écrire de code.

Exportation en dur dans les fichiers du thème

Une fonctionnalité clé du FSE est la possibilité de consolider les modifications réalisées dans l’éditeur en fichiers statiques pour un déploiement ou une gestion plus professionnelle.

Processus d’exportation :

Une fois le design d’un header, footer ou autre partie complété dans l’éditeur de site :
- Les utilisateurs ou développeurs peuvent accéder à l’option d’exportation intégrée.
- Cette option génère les fichiers .html correspondants et les enregistre dans les répertoires adéquats du thème :
  - block-template-parts/header.html
  - block-template-parts/footer.html
- Le fichier theme.json est mis à jour automatiquement avec les nouvelles déclarations.
Ces fichiers exportés deviennent alors des parties statiques du thème et peuvent être intégrés au code source pour plus de stabilité ou pour être utilisés sur d’autres sites. Cela permet de combiner le travail visuel (dans l’éditeur) et le travail statique (en dur dans les fichiers du thème), idéal pour les développeurs souhaitant affiner les détails après l’exportation.

De nouvelles possibilités pour les développeurs

La notion de patterns et blocs réutilisables

Les patterns et blocs réutilisables permettent de gagner du temps et de structurer efficacement les contenus. Selon l’approche choisie — “code” ou “low-code” — leur création peut être entièrement automatisée ou personnalisée par un développeur pour répondre à des besoins spécifiques.

Les patterns sont conçus et intégrés avant que l’utilisateur commence à travailler sur son contenu. Ils servent de modèles préconçus, définis en amont par le développeur ou le concepteur, et peuvent être utilisés comme base pour structurer rapidement des pages ou des sections. Ils ne sont pas synchronisés.

Les patterns dans WordPress sont statiques par nature : une fois insérés dans l’éditeur Gutenberg, ils deviennent des blocs autonomes. Cela signifie que les modifications apportées au pattern initial (par le développeur) ne se répercutent pas sur les pages où le pattern a été utilisé. Ce comportement est intentionnel pour éviter de modifier accidentellement des contenus déjà personnalisés par l’utilisateur.

Si vous devez mettre à jour un pattern sur plusieurs pages automatiquement, vous pouvez utiliser un script PHP ou l’API REST pour rechercher et remplacer les anciennes instances du pattern par la version mise à jour.

Vous pouvez sinon convertir le pattern en bloc dynamique (créé en PHP) ce qui peut rendre la mise à jour automatique.

Pour un contenu devant être synchronisé ou mis à jour régulièrement utilisez un bloc réutilisable, synchronisé ou transformez le pattern en bloc dynamique pour des mises à jour automatiques.

Exemples typiques :

Une bannière “Hero”.
Une section “À propos” avec une image et un texte.
Un modèle de galerie ou de FAQ.

Les blocs réutilisables sont créés pendant ou après la conception, généralement par l’utilisateur ou un concepteur. Ils permettent de sauvegarder des blocs ou des groupes de blocs spécifiques pour les réutiliser dans d’autres parties du site, avec le même contenu ou les mêmes paramètres.

Exemples typiques :

Un formulaire de contact.
Un appel à l’action (CTA) identique sur plusieurs pages.
Une signature de pied de page.

Avant les utilisateurs devaient souvent faire appel au développeur pour des ajustements. Maintenant Les développeurs conçoivent des modèles modulaires en amont (patterns) ou dynamiques (blocs personnalisés). Ils livrent un outil clé en main, où l’utilisateur final peut insérer et personnaliser ces éléments sans toucher au code.

Les développeurs travaillaient jusqu’ici principalement avec PHP. Avec Gutenberg, JavaScript et React deviennent essentiels pour créer des blocs interactifs et dynamiques.

Cela implique :

d’apprendre à utiliser les bibliothèques et APIs Gutenberg (par exemple, @wordpress/block-editor et @wordpress/scripts)
de créer des blocs avec React pour gérer des interactions avancées ou des données dynamiques.
de gérer la transition de la logique PHP (serveur) vers une logique côté client avec des appels API (via apiFetch ou l’API REST).
de concevoir des patterns en amont, directement intégrés dans le thème ou le plugin
d’utiliser la fonction PHP register_block_pattern() ou d’exporter des modèles créés manuellement dans l’éditeur.

Les blocs dynamiques

Contrairement aux blocs statiques, les blocs dynamiques affichent du contenu qui évolue en fonction des données ou des contextes (par exemple, les métadonnées d’un article (auteur, rubrique, date…) ou des champs personnalisés.

Ces blocs sont définis en PHP avec une logique dynamique et peuvent être intégrés dans des fichiers HTML du thème via la syntaxe FSE.

Binding FSE ACF

Quand l’administrateur ou le développeur crée des champs personnalisés dans ACF (par exemple, un champ texte “Titre du bloc”), ces champs peuvent être remplis pour chaque page, article ou contenu.

Le bloc créé par le développeur en PHP utilise alors ces données saisies dans ACF pour pré-remplir son contenu dans l’éditeur Gutenberg

Par exemple, le bloc affiche automatiquement un titre ou une image liés à un contenu défini dans ACF.

Les données saisies dans ACF sont récupérées via PHP ou l’API REST pour être affichées dynamiquement sur la page ou l’article final.

Cela implique pour le développer de maîtriser ACF et l’API Bindings.

React et Gutenberg : une architecture dynamique pour les blocs

Chaque bloc Gutenberg (par exemple, un paragraphe, une image ou une galerie) est en réalité un composant React. Gutenberg repose sur un ensemble d’API JavaScript, comme @wordpress/block-editor ou @wordpress/components, qui sont elles-mêmes construites avec React. Cela permet aux développeurs d’ajouter facilement de nouvelles fonctionnalités ou d’étendre celles déjà existantes.

Les blocs peuvent être modifiés en direct dans l’éditeur Gutenberg, et React met à jour l’affichage sans recharger la page. Cela offre une expérience fluide pour l’utilisateur. La gestion des états d’un composant est également facilitée avec React, ce qui permet aux blocs de stocker des données ou d’interagir avec des APIs, comme l’API REST de WordPress, pour afficher des contenus dynamiques.

Enfin, les développeurs peuvent utiliser React pour créer des blocs entièrement personnalisés. Ces blocs peuvent inclure des interfaces complexes, comme des formulaires, des carrousels ou des tableaux interactifs, tout en restant intuitifs et fluides à utiliser dans Gutenberg.

AJAX est devenu inutile dans l’éditeur de blocs, car React gère déjà les interactions dynamiques. Ceci dit AJAX peut être utilisé pour des actions en back-office qui ne sont pas directement liées à Gutenberg, comme des calculs complexes ou des synchronisations avec des services tiers.

Les blocs personnalisés ou dynamiques utilisent souvent API Fetch pour récupérer ou envoyer des données (par exemple, récupérer des articles, des utilisateurs ou des champs ACF).

Pour conclure

La transition des template-parts classiques vers ceux du Full Site Editing reflète le passage de WordPress d’une approche orientée développeur à une solution davantage centrée sur l’utilisateur. Cette évolution offre aux utilisateurs une liberté accrue pour personnaliser leur site via l’éditeur de blocs, rendant les modifications accessibles sans compétences en code.

Pour autant, le rôle du développeur reste tout aussi déterminant, voire plus complexe. En effet, la création de thèmes FSE nécessite une maîtrise approfondie des nouveaux outils comme theme.json, l’organisation des blocs, et une approche plus stratégique pour anticiper les besoins des utilisateurs tout en garantissant une structure cohérente et performante.

Le développeur WordPress devient ainsi un architecte de l’expérience utilisateur, conciliant flexibilité et robustesse dans un environnement en constante évolution.

Différence entre un template part classique et celui du FSE

Structure et fonctionnement dans un thème FSE

Déclaration :

Création du template-part : block-template-parts/header.html

Appel dans un modèle : block-templates/page.html

Déclaration du template-part pour qu’il soit reconnu et utilisable dans l’éditeur de site : theme.json

Les différences principales

Avantages

Limites

Où et comment implanter les template-parts ?

Thème classique (PHP)

Thème FSE (HTML)

Pourquoi WordPress utilise un fichier de configuration avec JSON et non YAML ?

La nouvelle syntaxe

Les avantages de cette nouvelle syntaxe

Exportation en dur dans les fichiers du thème

Processus d’exportation :

De nouvelles possibilités pour les développeurs

La notion de patterns et blocs réutilisables

Les blocs dynamiques

Binding FSE ACF

React et Gutenberg : une architecture dynamique pour les blocs

Pour conclure

Plus d’articles

Différence entre un template part classique et celui du FSE

Modèle de devis pour un site FSE

Checklist qualité web pour portfolio WordPress avec Full Site Editing (FSE)

Qualité web : le modèle VPTCS