# Préparer ses thèmes au Full Site Editing dès 2020 : checklist d’intégrateur

> Le Full Site Editing n'existe encore que dans le plugin Gutenberg expérimental. Voici ce qu'un intégrateur peut déjà changer dans ses thèmes classiques pour ne pas tout refaire plus tard.

- Auteur : Clément Hadrot
- Publié le : 2020-11-19
- Mis à jour le : 2020-11-19
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/prepare-themes-fse-2020-checklist/

## L’essentiel

- Découpler le HTML des templates PHP
- Réduire les options du Customizer
- Suivre les commits du plugin Gutenberg

Depuis quelques mois, chaque nouvelle version du plugin Gutenberg embarque son lot de blocs expérimentaux : Site Title, Template Part, Post Content. Rien n'est stable, tout peut changer d'une semaine à l'autre, et pourtant une direction se dessine clairement : à terme, les thèmes ne seront plus seulement des fichiers PHP, mais des assemblages de blocs stockés en HTML.

Sur un projet client livré la semaine dernière, on a pris une décision qui semblait presque anodine : sortir toutes les couleurs codées en dur des fichiers de template pour les centraliser dans un unique tableau PHP. Ce genre de petit chantier, répété sur quelques thèmes, prépare le terrain sans rien miser sur une fonctionnalité qui n'est même pas encore fusionnée dans le cœur de WordPress.

## Découpler le markup de la logique métier

Le premier réflexe à prendre consiste à séparer nettement ce qui relève de l'affichage de ce qui relève de la donnée. Un `header.php` qui mélange une requête `WP_Query`, un menu et trois `if` imbriqués sera un cauchemar à convertir en template part le jour venu. À l'inverse, un en-tête qui se contente d'appeler `get_template_part()`, `wp_nav_menu()` et `bloginfo()` se lit presque déjà comme une future séquence de blocs.

Concrètement, cela veut dire déplacer la logique complexe dans des fonctions dédiées, appelées depuis `functions.php`, et ne laisser dans les fichiers de template que des appels simples et prévisibles.

## Limiter et documenter les options du Customizer

> L'essentiel à retenir : Découpler le HTML des templates PHP ; Réduire les options du Customizer ; Suivre les commits du plugin Gutenberg

Le Customizer a été, pendant des années, l'endroit où l'on entassait tous les réglages visuels d'un thème : couleur du lien, taille du logo, marge du footer. Chaque option ajoutée aujourd'hui est un réglage qu'il faudra, demain, retrouver sous forme de bloc ou de preset dans un futur `theme.json` — un format encore inexistant à l'heure où ces lignes sont écrites, mais dont la logique de presets centralisés se devine déjà dans les discussions du groupe de travail Gutenberg.

- Auditer les options existantes et supprimer celles qui ne servent plus.
- Regrouper les couleurs et tailles de police dans une palette limitée, plutôt qu'un champ de couleur libre par élément.
- Documenter, pour chaque option restante, à quel élément visuel elle correspond exactement.

## Adopter un contrôle de version pour les futurs fichiers HTML

Un thème bloc, tel qu'il se dessine dans les prototypes du plugin, stocke ses templates sous forme de fichiers HTML dans un dossier `block-templates`. Rien n'empêche, dès maintenant, d'organiser son thème classique de façon à faciliter cette bascule : un dossier `template-parts` propre, des noms de fichiers cohérents avec ce que l'on imagine des futurs gabarits (`header.php`, `footer.php`, `sidebar.php` bien isolés), et surtout un historique Git qui permettra de comparer l'avant et l'après.

## Suivre l'avancement du plugin sans paniquer

Il ne s'agit pas de réécrire un thème en urgence pour coller à une API qui bouge chaque semaine. Le plugin Gutenberg, en version 9.x à l'heure où j'écris, propose encore des blocs marqués comme expérimentaux et parfois retirés d'une mise à jour à l'autre. La bonne pratique consiste à installer le plugin sur un site de test, à observer, à noter ce qui semble se stabiliser, sans jamais le déployer en production.

> Sur nos projets, on garde un environnement de veille séparé pour tester chaque version du plugin Gutenberg : cela évite de confondre une fonctionnalité expérimentale avec une base fiable pour un client.

## La checklist à appliquer dès aujourd'hui

1. Extraire toute logique métier des fichiers de template vers des fonctions dédiées.
2. Réduire le nombre d'options du Customizer et documenter celles qui restent.
3. Centraliser les couleurs et tailles de police dans un tableau PHP unique, facilement exportable plus tard.
4. Organiser les template parts existants dans une arborescence claire et cohérente.
5. Installer le plugin Gutenberg sur un environnement de test dédié, jamais en production.
6. Tenir un petit journal des blocs expérimentaux testés et de leurs évolutions.

## Notre verdict

Personne ne peut dire aujourd'hui à quelle date le Full Site Editing sortira en version stable, ni sous quelle forme exacte. Mais les chantiers décrits ici — découplage du markup, sobriété du Customizer, organisation du code — ont une vertu qu'on oublie parfois : ils rendent un thème classique plus maintenable, indépendamment de toute promesse future. Autant en profiter maintenant plutôt que d'attendre un signal officiel qui ne changera rien à la nécessité de ce ménage.