Chapitre 3.3 — Full Site Editing : l’éditeur de site

⏱️ TL;DR — Le Full Site Editing (FSE) étend Gutenberg au site entier : avec un thème bloc, on édite l’en-tête, le pied de page, et les gabarits (templates) directement en blocs, via Apparence → Éditeur. De nouveaux blocs « de thème » apparaissent (Logo du site, Navigation, Titre de l’article, Requête — une boucle en blocs). Fini (en grande partie) le PHP des templates classiques : la structure du site devient du contenu en blocs, piloté par theme.json.

🎯 Objectifs

• Comprendre ce qu’apporte le FSE par rapport aux thèmes classiques.
• Naviguer dans l’éditeur de site (gabarits, parties, styles).
• Connaître les blocs de thème clés (Navigation, Requête, Logo…).
• Situer le FSE face au développement de thèmes (Partie 6).

1. Deux mondes de thèmes

WordPress vit une transition : deux familles de thèmes coexistent.

Le FSE ne supprime pas les thèmes classiques (Partie 6 couvre les deux), mais c’est la direction de WordPress. Pour un dev moderne, le thème bloc est souvent plus rapide et plus « déclaratif ».

2. L’éditeur de site (Apparence → Éditeur)

Avec un thème bloc actif, Apparence → Éditeur ouvre une interface qui gère :

• Navigation : les menus (bloc Navigation).
• Styles : les styles globaux (couleurs, typo, espacements) — l’UI de theme.json (ch. 3.4).
• Pages : édition directe de pages.
• Gabarits (Templates) : les modèles de page (Accueil, Article seul, Archive, 404…).
• Parties de gabarit (Template Parts) : en-tête, pied de page réutilisables.

On y édite tout avec les mêmes blocs que pour un article — plus les blocs « de thème ».

⚠️ Piège — Les modifications faites dans l’éditeur de site sont enregistrées en base de données (elles « surchargent » les fichiers du thème). D’où deux sources possibles pour un même gabarit : la version du thème (fichiers) et la version personnalisée (base). Le bouton Effacer les personnalisations rétablit la version du thème. En développement, gardez cette dualité en tête (Partie 6) : ce que vous livrez en fichiers peut être écrasé par des éditions en base.

3. Les blocs « de thème »

Le FSE introduit des blocs qui exposent des données du site, impensables dans un simple article :

💡 Pour un dev React — Le bloc Requête est un map sur une liste rendu visuellement : « pour chaque article correspondant à ces critères, rends ce template de blocs ». C’est posts.map(post => <Card {...post} />), mais éditable à la souris. Les blocs comme Titre de l’article sont des placeholders de données (« affiche le titre du post courant ») — pensez à des composants qui lisent un contexte. Cette logique « template = blocs + données » est exactement ce que vous retrouverez en headless et en dev de blocs.

4. Ce que le FSE change pour le créateur

• Autonomie : le client peut modifier son en-tête, son pied, ses couleurs sans développeur.
• Cohérence : tout passe par theme.json → un design system unifié.
• Moins de code jetable : plus besoin d’un PHP custom pour chaque variation de mise en page.

Mais attention : cette autonomie peut aussi produire des incohérences si on ne cadre pas (styles globaux, blocs verrouillés, motifs imposés). Une partie du travail du dev de thème bloc (Partie 6) est justement de guider ce que le client peut faire.

5. Situer le FSE dans le cours

Ici, vous découvrez le FSE en créateur. En Partie 6, vous construirez un thème bloc (fichiers theme.json, templates/, parts/). En Partie 8, vos blocs custom viendront s’ajouter à la palette de l’éditeur de site. Le FSE est donc un pivot : il relie le contenu, le thème et les blocs custom dans un même modèle.

✏️ Exercices

1. Citez deux différences concrètes entre un thème classique et un thème bloc.
2. Quel bloc utiliseriez-vous pour afficher « les 6 derniers articles de la catégorie Actus » dans un gabarit ?
3. Où sont enregistrées les modifications faites dans l’éditeur de site, et comment revenir à la version du thème ?

🧠 Quiz de révision

Chapitre suivant : theme.json & styles globaux.