Le Full Site Editing (FSE) transforme radicalement la façon de créer des thèmes WordPress. Depuis WordPress 5.9, l’éditeur de blocs s’étend désormais à l’ensemble du site — en-têtes, pieds de page, gabarits de pages, archives — et les Block Patterns offrent une bibliothèque de compositions réutilisables que les utilisateurs peuvent insérer en un clic. En 2026, maîtriser le FSE n’est plus facultatif pour un développeur WordPress sérieux : c’est le socle sur lequel repose l’écosystème entier. Ce guide vous accompagne pas à pas dans la création d’un thème FSE robuste et maintenable.
Comprendre l’architecture d’un thème FSE
Un thème Block Theme se distingue d’un thème classique par l’absence totale de fichiers PHP de gabarit tels que header.php ou single.php. À la place, on trouve des fichiers HTML stockés dans le dossier templates/ et parts/ : WordPress parse ces fichiers, identifie les commentaires de blocs, et génère le rendu côté serveur. Cette architecture déclarative sépare clairement le design de la logique métier.
Le dossier templates/ contient les gabarits principaux : index.html (obligatoire), single.html, archive.html, 404.html, search.html. Le dossier parts/ accueille les fragments réutilisables comme header.html, footer.html ou sidebar.html. Chaque fichier est un fichier HTML standard peuplé de commentaires de blocs Gutenberg, entièrement éditable depuis le Site Editor de l’administration WordPress.
La hiérarchie des gabarits FSE suit les mêmes règles que l’ancienne hiérarchie de thèmes PHP : WordPress cherche d’abord le gabarit le plus spécifique. Par exemple, pour un article de la catégorie ‘news’, il cherche category-news.html, puis category.html, puis archive.html, puis index.html. Comprendre cette cascade vous permet de cibler précisément le rendu de chaque section de votre site.
Configurer theme.json : le fichier central
Le fichier theme.json est le cerveau du thème FSE. Il définit les palettes de couleurs, les familles typographiques, les espacements, les tailles de contenu, et bien plus encore — sans écrire une ligne de CSS personnalisé. WordPress génère automatiquement des propriétés CSS custom (–wp–preset–color–primary, etc.) depuis ces déclarations, ce qui garantit une cohérence totale entre l’éditeur visuel et le rendu public.
La clé settings contrôle ce que l’éditeur propose à l’utilisateur : activer ou désactiver la palette étendue, limiter les polices disponibles, fixer les tailles d’espacement. La clé styles applique ces paramètres au niveau global ou par bloc (styles.blocks.core/paragraph, par exemple). Cette dualité settings/styles est au cœur de toute personnalisation FSE avancée.
Avec WordPress 6.5+, theme.json supporte désormais les custom CSS par bloc via styles.blocks, les custom templates pour les Custom Post Types, et les font-face déclarations pour les polices locales. Versionner theme.json dans votre dépôt Git vous offre un audit complet de l’évolution du design de votre thème, et simplifie les déploiements sur des environnements multiples.
Créer et enregistrer des Block Patterns
Les Block Patterns sont des compositions de blocs pré-assemblées : un hero avec image de fond et bouton CTA, un grid de cartes d’articles, une section de témoignages. Depuis WordPress 6.0, ils peuvent être définis directement dans le dossier patterns/ de votre thème. Un fichier PHP minimal suffit : un en-tête commenté avec Title, Slug, Categories et le HTML de la composition.
La déclaration se fait via des métadonnées en commentaire PHP en tête de fichier, sur le modèle Title: Hero Banner; Slug: mytheme/hero-banner; Categories: featured. Le corps du fichier contient le markup de blocs Gutenberg que vous auriez copié depuis l’éditeur. WordPress enregistre automatiquement tous les fichiers .php de patterns/ au chargement du thème, sans appel register_block_pattern() explicite.
Pour offrir des variations de design sans multiplier les patterns, utilisez les Style Variations : des fichiers JSON dans styles/ qui étendent ou surchargent theme.json. Ils apparaissent dans le Site Editor sous forme de thèmes alternatifs que l’utilisateur peut appliquer en un clic. Une variation peut changer la palette, la typographie ou les rayons de bordure, créant une déclinaison visuelle complète à partir du même thème de base.
Travailler avec les gabarits de blocs
Les gabarits FSE s’écrivent en HTML commenté Gutenberg. Par exemple, un gabarit de page simple combine wp:site-logo, wp:navigation, wp:query (pour la boucle d’articles) et wp:site-footer-information. L’éditeur visuel du Site Editor génère ce code automatiquement, mais le comprendre vous permet de le versionner, de le modifier en masse, et de l’intégrer dans des outils de déploiement CI/CD.
Les Block Template Parts (wp:template-part) permettent d’inclure des fragments réutilisables dans vos gabarits. Un appel type ressemble à : . Lorsque l’utilisateur modifie l’en-tête dans le Site Editor, la modification s’applique à tous les gabarits qui l’incluent, exactement comme un composant dans un framework frontend moderne.
Les gabarits personnalisés pour les Custom Post Types s’enregistrent via le fichier functions.php avec add_filter(‘theme_cpt_templates’, …) ou via theme.json en déclarant customTemplates. Cette approche sans PHP pour les CPT est particulièrement précieuse dans les architectures headless où WordPress sert de back-end CMS et expose ses données via l’API REST ou WPGraphQL.
theme.json en pratique : exemple complet
Voici un exemple de theme.json minimaliste mais complet pour un thème professionnel. Il définit une palette de deux couleurs, une police Inter chargée localement, et une largeur de contenu de 800px avec une zone wide à 1200px. Ce fichier est suffisant pour lancer un thème cohérent et personnalisable depuis l’interface d’administration.
L’attribut $schema pointe vers la définition JSON officielle : il active l’autocomplétion et la validation dans VSCode ou PhpStorm. Sans lui, les erreurs de syntaxe ne sont détectées qu’au chargement du thème. Renseignez toujours la version (actuellement 2) pour bénéficier des dernières fonctionnalités et éviter les comportements dépréciés dans les futures versions de WordPress.
Pour les projets d’envergure, découpez theme.json en fichiers partiels et fusionnez-les via un build tool (wp-scripts, Vite). Certaines équipes stockent les variables de design dans un fichier design-tokens.json partagé avec Figma via Style Dictionary, puis génèrent automatiquement theme.json à chaque mise à jour du design system. Cette approche garantit une cohérence parfaite entre maquettes et code.
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"color": {
"palette": [
{ "slug": "primary", "color": "#0073aa", "name": "Primary" },
{ "slug": "secondary", "color": "#23282d", "name": "Secondary" }
]
},
"typography": {
"fontFamilies": [
{
"fontFamily": "Inter, sans-serif",
"slug": "inter",
"name": "Inter"
}
]
},
"layout": {
"contentSize": "800px",
"wideSize": "1200px"
}
},
"styles": {
"color": {
"background": "#ffffff",
"text": "#1a1a1a"
},
"typography": {
"fontFamily": "var(--wp--preset--font-family--inter)",
"fontSize": "1rem",
"lineHeight": "1.7"
}
}
}Optimiser les performances d’un thème FSE
Les thèmes FSE bénéficient d’une optimisation native : WordPress ne charge que les styles des blocs effectivement présents sur la page (Per-Block Styles), contrairement aux thèmes classiques qui chargent un monolithique style.css. Activez l’option shouldLoadSeparateStyles dans theme.json pour exploiter cette granularité. Sur des pages simples, le gain peut atteindre 50 à 70 % de CSS superflu éliminé.
Les fontes locales sont un autre levier majeur. Déclarez vos font-face dans theme.json via settings.typography.fontFamilies avec les propriétés src pointant vers /assets/fonts/. WordPress 6.5 génère automatiquement les préchargements pour les polices utilisées dans les gabarits. Évitez ainsi les appels Google Fonts qui ajoutent une requête DNS externe à chaque visite.
Pour les images dans les Block Patterns, privilégiez des placeholders vectoriels SVG inline ou des images référencées depuis la médiathèque avec leurs IDs. Évitez les URLs absolues qui cassent lors de la migration entre environnements. Le plugin Safe SVG permet d’injecter des SVG optimisés directement dans l’éditeur, sans risque XSS, tout en maintenant des performances d’affichage optimales.
Déployer et versionner un thème FSE
Un thème FSE est un dossier de fichiers texte (HTML, JSON, PHP pour les patterns) : il se versionne naturellement avec Git. Ajoutez wp-content/themes/votre-theme/ à votre dépôt, configurez un .gitignore qui exclut node_modules et les builds, et automatisez le déploiement via GitHub Actions ou GitLab CI. Un pipeline type : lint → build assets → rsync vers le serveur de staging → tests → déploiement production.
Les modifications faites via le Site Editor (personnalisation de gabarits, palettes modifiées) sont stockées en base de données dans la table wp_posts avec post_type=wp_template. Pour les exporter proprement, utilisez le plugin Create Block Theme qui permet d’exporter les customisations utilisateur dans les fichiers de votre thème. Sans cet export, les modifications en production ne sont pas versionnées et peuvent être perdues.
Pour les environnements multiples (local, staging, production), utilisez WP-CLI pour pousser ou tirer les gabarits personnalisés : wp theme activate votre-theme puis wp eval-file reset-templates.php. Coupler WP-CLI à votre pipeline CI/CD vous donne un contrôle total sur l’état du thème à chaque environnement, sans dépendance à une interface graphique manuelle et aux oublis qui en découlent.
Compatibilité plugins et bonnes pratiques 2026
En 2026, la quasi-totalité des plugins populaires — WooCommerce, The Events Calendar, Advanced Custom Fields, Yoast SEO — proposent des blocs compatibles FSE. Vérifiez la compatibilité de vos plugins via la page Has Blocks sur wordpress.org/plugins avant de migrer un thème classique vers FSE. Les plugins qui se reposent encore sur des shortcodes ou des widgets classiques nécessitent des shims ou des mises à jour.
Testez systématiquement votre thème avec le plugin Theme Check : il valide la présence des fichiers obligatoires, les en-têtes corrects, et l’absence de fonctions dépréciées. Le plugin Gutenberg (version expérimentale du cœur) permet de tester les fonctionnalités FSE en avant-première et d’anticiper les changements à venir. Maintenez un environnement de test sur WordPress Playground pour valider les mises à jour majeures sans risquer la production.
Documentez votre thème : un README.md à la racine, un changelog, et des commentaires dans les fichiers de gabarits complexes. Si vous distribuez votre thème sur le répertoire officiel, respectez les standards de revue : pas de code obfusqué, pas de liens publicitaires dans les templates, licences GPL pour tout le code PHP. La communauté FSE est active sur make.wordpress.org/themes : participez aux chats hebdomadaires pour rester informé des évolutions.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.