# WordPress 5.9 et l’éditeur de site : ce qui change vraiment pour les développeurs

> WordPress 5.9 sort officiellement le Full Site Editing du statut expérimental. Éditeur de site, Twenty Twenty-Two, templates : décryptage à chaud.

- Auteur : Clément Hadrot
- Publié le : 2022-01-25
- Mis à jour le : 2022-01-25
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/wordpress-5-9-editeur-site-nouveautes/

## L’essentiel

- L'éditeur de site quitte enfin le statut expérimental du plugin Gutenberg
- Twenty Twenty-Two, premier thème-bloc par défaut du cœur
- Le bloc Navigation remplace les menus classiques sur les thèmes de blocs

C'est officiel depuis aujourd'hui : WordPress 5.9 est disponible, et avec lui l'arrivée dans le cœur de ce qu'on testait depuis plus d'un an dans le plugin Gutenberg sous statut expérimental. L'éditeur de site, les templates en blocs, le thème Twenty Twenty-Two : tout ce qui relevait jusque-là du bricolage réservé aux curieux devient une fonctionnalité officielle, activable sans flag caché.

Après une phase de tests souvent frustrante marquée par des interfaces qui changeaient d'une semaine à l'autre, la question se pose naturellement : qu'est-ce qui a réellement mûri, et qu'est-ce qui reste fragile ? Voici une analyse à chaud, du point de vue de quelqu'un qui développe des thèmes WordPress au quotidien.

## L'éditeur de site sort de l'ombre

Le menu **Apparence > Éditeur de site** n'a plus besoin d'un flag expérimental pour apparaître : il est là par défaut, à condition d'utiliser un thème compatible. Concrètement, cela signifie un thème qui déclare le support `add_theme_support( 'block-templates' )` et qui embarque un fichier `theme.json`.

L'interface elle-même a gagné en stabilité par rapport aux versions testées l'an dernier dans le plugin Gutenberg. La navigation entre templates ne provoque plus de rechargements intempestifs, les sauvegardes sont fiables, et un nouveau panneau latéral permet de visualiser la hiérarchie des templates utilisés par le site : template général, templates spécifiques par type de contenu, template parts pour l'en-tête et le pied de page.

> L'essentiel à retenir : L'éditeur de site quitte enfin le statut expérimental du plugin Gutenberg ; Twenty Twenty-Two, premier thème-bloc par défaut du cœur ; Le bloc Navigation remplace les menus classiques sur les thèmes de blocs

## Twenty Twenty-Two, premier thème-bloc officiel

Nouveauté marquante de cette version : le thème par défaut change radicalement de nature. **Twenty Twenty-Two** est le premier thème du cœur WordPress construit entièrement comme un thème de blocs, sans un seul template PHP classique. Sa structure de fichiers illustre bien le changement d'approche :

- Un dossier `templates/` contenant des fichiers HTML (`index.html`, `single.html`, `archive.html`...) au lieu des habituels `.php` ;
- Un dossier `parts/` pour les fragments réutilisables comme l'en-tête et le pied de page ;
- Un fichier `theme.json` fourni, riche et bien commenté, qui sert désormais de référence pour comprendre les possibilités du format ;
- Aucun fichier `functions.php` volumineux : la majorité de la configuration passe par le JSON plutôt que par du PHP.

Pour un développeur habitué aux thèmes classiques, la première ouverture du code source de Twenty Twenty-Two est déstabilisante : chercher la boucle WordPress habituelle ou un appel à `the_content()` ne mène nulle part. Tout est remplacé par des blocs de template comme `core/post-content`, exactement comme observé l'an dernier dans les premières expérimentations du plugin.

## Templates et template parts, enfin documentés

La hiérarchie des templates conserve globalement la même logique que la hiérarchie PHP historique (`single.html` pour un article, `page.html` pour une page, `archive.html` pour une liste), ce qui limite la courbe d'apprentissage pour qui maîtrise déjà le système de templates classique.

La vraie nouveauté réside dans les **template parts**, des fragments de template indépendants et réutilisables entre plusieurs templates. On les déclare via le bloc `core/template-part`, et elles sont éditables directement depuis l'éditeur de site sans devoir ouvrir le template complet qui les contient :

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

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
    <!-- wp:post-title /-->
    <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

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

Ce mécanisme rappelle directement les `get_header()` et `get_footer()` du PHP classique, mais avec un avantage net : les template parts sont éditables visuellement, sans toucher au code, et leur contenu peut être différent selon le contexte gérable depuis l'interface plutôt que via des conditions PHP.

## Le bloc Navigation remplace les menus classiques

Sur un thème de blocs comme Twenty Twenty-Two, le bloc `core/navigation` prend le relais de la fonction `wp_nav_menu()`. Son fonctionnement diffère sensiblement de l'ancien système de menus :

- La structure du menu est éditable directement dans l'éditeur, avec glisser-déposer des liens ;
- Les menus créés sont stockés comme un nouveau type de contenu (`wp_navigation`), pas dans les options classiques de l'administration Menus ;
- La compatibilité avec l'ancien écran *Apparence > Menus* reste assurée pour les thèmes qui n'ont pas basculé en thème de blocs.

Pour les développeurs, l'implication la plus concrète est immédiate : un thème hybride qui mélange templates PHP classiques et blocs FSE doit choisir son camp pour la gestion des menus, au risque de créer une confusion pour les utilisateurs qui verraient deux interfaces différentes coexister.

## Ce qui reste fragile pour l'instant

Malgré ces avancées réelles, tout n'est pas encore parfaitement rond. Plusieurs points méritent la prudence avant de basculer un projet client en thème de blocs pur :

- La compatibilité avec les extensions tierces reste partielle, notamment les constructeurs de pages historiques qui n'ont pas encore adapté leur intégration ;
- La traduction des templates HTML via les outils habituels (fichiers `.po`/`.mo`) demande encore des ajustements par rapport aux templates PHP ;
- La documentation officielle progresse, mais reste en retrait par rapport à la richesse déjà offerte par l'interface.

Pour des projets clients avec des besoins complexes de champs personnalisés ou d'intégrations tierces, un thème hybride (classique avec support partiel du FSE) reste souvent le choix le plus raisonnable à court terme.

> Avant de migrer un site existant vers un thème de blocs, testez d'abord en local avec une copie complète du contenu. Les écarts de rendu entre un template PHP et son équivalent en blocs ne sont pas toujours évidents à anticiper sur le papier.

## Notre verdict

WordPress 5.9 marque un vrai tournant : ce qui relevait du prototype expérimental il y a encore quelques mois devient une fonctionnalité livrée par défaut, testée par des millions d'installations dès le premier jour. La maturité globale a clairement progressé par rapport aux versions du plugin Gutenberg testées en 2021.

Pour autant, il ne s'agit pas encore du moment où tous les nouveaux projets doivent basculer en thème de blocs pur. Sur les prochains mois, l'écosystème des extensions et les outils de développement vont devoir rattraper leur retard. En attendant, comprendre en profondeur templates, template parts et bloc Navigation est devenu un prérequis pour tout développeur WordPress qui veut rester pertinent.