Réserver

Full Site Editing et theme.json : le guide complet

par Francis Rozange | Oct 2, 2026 | Gutenberg

A glowing glass blueprint sheet shaping translucent blocks beneath it

Un thème de blocs WordPress n’a besoin que de deux fichiers pour exister : une feuille de style qui le déclare, et un modèle templates/index.html. Tout le reste, couleurs, typographie, espacements, largeurs, peut tenir dans un troisième fichier, theme.json, qui pilote à la fois l’éditeur et le site.

Ce fichier ne concerne pas que les thèmes de blocs. WordPress charge son propre theme.json par défaut sur tous les sites, y compris ceux qui tournent sur un thème classique. À l’été 2024, une modification de ces styles globaux a souligné tous les liens de navigation de sites qui n’avaient jamais touché à l’éditeur de site.

Ce guide couvre l’édition complète de site, ou Full Site Editing, telle qu’elle se présente dans WordPress 7.1 : thèmes de blocs, classiques et hybrides, modèles et parties de modèle, structure de theme.json en version 3, typographie fluide, variations de style, nouveautés de 7.0 et 7.1, verrouillage de l’éditeur pour un client et migration d’un thème classique.

Thème de blocs, classique, hybride : trois façons de construire

Ce qui fait un thème de blocs

WordPress reconnaît officiellement deux types de thèmes : les thèmes de blocs et les thèmes classiques. Un thème de blocs se compose de modèles HTML écrits en balisage de blocs, modifiables dans l’éditeur de site, et de styles globaux définis dans theme.json. Un thème classique repose sur la hiérarchie de modèles PHP et sur l’outil de personnalisation, toujours pris en charge.

La frontière tient à un fichier : WordPress considère un thème comme un thème de blocs dès qu’il contient templates/index.html. Un theme.json seul ne suffit pas. Kadence ou Blocksy en embarquent un et restent des thèmes classiques.

Le menu d’administration reflète cette différence. Avec un thème de blocs, Apparence ouvre l’éditeur de site, et l’outil de personnalisation disparaît sauf si un plugin ou le thème s’y accroche.

Avec un thème classique, l’éditeur de site n’existe qu’en version réduite, sans modèles ni styles globaux. Depuis WordPress 6.8, le menu Apparence propose Design, avec le Guide de style et les compositions, si le thème a un theme.json ou des styles d’éditeur, et simplement Compositions sinon.

Les thèmes hybrides, un entre-deux officieux

La documentation le précise : les thèmes hybrides ne sont pas un type officiel. Ce sont des thèmes classiques qui adoptent certaines fonctions des blocs, comme un theme.json, des parties de modèle en blocs, des styles de blocs ou des compositions. Le blog des développeurs de WordPress les présente comme un pont : ils prennent en charge l’éditeur de blocs, pas l’éditeur de site.

C’est souvent la voie la plus réaliste pour faire évoluer un thème existant sans tout réécrire. Notre sélection de thèmes de blocs WordPress gratuits montre où en sont les thèmes prêts à l’emploi.

Modèles et parties de modèle

La hiérarchie des modèles de blocs

Les modèles d’un thème de blocs se rangent dans le dossier /templates, les parties de modèle dans /parts, les compositions dans /patterns et les variations de style dans /styles. Seuls style.css et templates/index.html sont obligatoires.

Pour afficher une page, WordPress cherche d’abord un modèle créé par l’utilisateur et enregistré en base, puis dans le thème enfant, puis dans le thème parent. Pour un article, il essaie par exemple un modèle propre au type de contenu, puis single.html, puis singular.html, et termine toujours par index.html. La page d’accueil utilise front-page.html s’il existe, quel que soit le réglage de lecture.

Voici un modèle index.html minimal, en balisage de blocs :

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->
<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">
	<!-- wp:query {"query":{"inherit":true}} -->
	<div class="wp-block-query">
		<!-- wp:post-template -->
			<!-- wp:post-title {"isLink":true} /-->
			<!-- wp:post-content {"layout":{"type":"constrained"}} /-->
		<!-- /wp:post-template -->
		<!-- wp:query-pagination -->
			<!-- wp:query-pagination-previous /-->
			<!-- wp:query-pagination-next /-->
		<!-- /wp:query-pagination -->
	</div>
	<!-- /wp:query -->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

WordPress génère lui-même les balises html, head et body autour de ce contenu.

Parties de modèle et zones

Les parties de modèle, appelées « éléments de modèle » dans l’interface française de WordPress, sont des fragments réutilisables, comme l’en-tête ou le pied de page. Elles se rangent à plat dans /parts : WordPress ne prend pas en charge les sous-dossiers, et lit encore l’ancien nom de dossier block-template-parts par compatibilité. Chacune peut être rattachée à une zone : en-tête, pied de page, générale, et depuis WordPress 7.0, la superposition de navigation.

Ce que l’utilisateur modifie, et où c’est enregistré

Les modifications faites dans l’éditeur de site ne touchent pas aux fichiers du thème. Elles sont enregistrées en base, dans des types de contenus dédiés aux modèles, aux parties de modèle et aux styles globaux. Elles priment sur les fichiers et survivent aux mises à jour du thème.

Conséquence pratique : une correction apportée par l’auteur du thème à un modèle n’atteint pas un site dont l’utilisateur a déjà modifié ce modèle. Pour récupérer ces modifications dans des fichiers, l’éditeur de site propose un export du thème, et le plugin Create Block Theme permet de les réenregistrer dans le thème actif.

Les thèmes enfants de blocs

Un thème de blocs accepte un thème enfant, comme un thème classique. WordPress cherche alors chaque modèle dans le thème enfant avant le parent, et le theme.json de l’enfant complète celui du parent au lieu de le remplacer. Depuis WordPress 6.2, le thème enfant hérite aussi des variations de style du parent, et une variation enregistrée sous le même nom de fichier dans l’enfant remplace celle du parent.

C’est la bonne façon d’adapter un thème du répertoire sans perdre ses mises à jour. Create Block Theme sait aussi créer un thème enfant à partir du thème actif.

theme.json, le fichier qui pilote le design

Structure et version du schéma

Le fichier theme.json est arrivé avec WordPress 5.8, sa version 2 avec WordPress 5.9 et sa version 3 avec WordPress 6.6, en juillet 2024. Dans WordPress 7.1, la version en vigueur reste la 3 : il n’existe pas de version 4, ni dans le cœur, ni dans les schémas officiels.

Méfiez-vous du manuel des thèmes : sa page d’introduction, pourtant mise à jour en juin 2026, indique encore la version 2, et ses exemples l’utilisent. La référence à jour est celle du manuel de l’éditeur de blocs, qui décrit toutefois aussi des clés de la branche de développement.

Pour valider votre fichier, l’équipe des thèmes recommande de pointer la clé $schema vers le schéma de la version minimale de WordPress exigée par votre thème, par exemple celui de 7.1 pour un thème qui exige 7.1, plutôt que vers celui de la branche de développement, qui contient déjà des clés absentes du cœur.

Réglages et styles

Le fichier se divise en deux grandes sections. Les réglages, settings, déterminent quelles options l’éditeur propose et quels préréglages existent : palette de couleurs, tailles de police, espacements, ombres. Les styles, styles, définissent le CSS réellement appliqué, au site entier, à des éléments comme les liens et les titres, ou à des blocs précis.

Chaque préréglage génère une variable CSS, comme --wp--preset--color--accent, et les couleurs, dégradés, tailles et familles de police génèrent aussi une classe, comme .has-accent-color. Dans le fichier, on y fait référence avec une syntaxe propre, par exemple var:preset|color|accent. L’option appearanceTools active d’un coup une série d’outils de design : bordures, couleurs des liens, marges, hauteurs minimales, position collante.

Un exemple de départ

Ce fichier, validé contre le schéma de WordPress 7.1, pose une palette de trois couleurs, des tailles de police fluides, une échelle d’espacement et le style des liens :

{
	"$schema": "https://schemas.wp.org/wp/7.1/theme.json",
	"version": 3,
	"settings": {
		"appearanceTools": true,
		"layout": { "contentSize": "720px", "wideSize": "1200px" },
		"color": {
			"defaultPalette": false,
			"palette": [
				{ "slug": "base", "color": "#ffffff", "name": "Base" },
				{ "slug": "contrast", "color": "#111111", "name": "Contrast" },
				{ "slug": "accent", "color": "#667eea", "name": "Accent" }
			]
		},
		"typography": {
			"fluid": true,
			"defaultFontSizes": false,
			"fontSizes": [
				{ "slug": "small", "size": "1rem", "name": "Small", "fluid": false },
				{ "slug": "large", "size": "2rem", "name": "Large", "fluid": { "min": "1.5rem", "max": "2.5rem" } }
			]
		},
		"spacing": {
			"defaultSpacingSizes": false,
			"spacingScale": { "operator": "*", "increment": 1.5, "steps": 7, "mediumStep": 1.5, "unit": "rem" }
		}
	},
	"styles": {
		"color": { "background": "var:preset|color|base", "text": "var:preset|color|contrast" },
		"elements": {
			"link": {
				"color": { "text": "var:preset|color|accent" },
				":hover": { "color": { "text": "var:preset|color|contrast" } }
			}
		}
	}
}

Réglages par bloc et éléments

Un réglage global peut être surchargé pour un bloc précis dans settings.blocks, et un style dans styles.blocks. Attention à une coquille du manuel des thèmes, qui écrit « settings.block » au singulier : la clé correcte est au pluriel. Les éléments, comme les liens, les boutons ou les titres, se règlent dans styles.elements, avec, pour les liens et les boutons seulement, des états comme le survol ou le focus.

Typographie fluide et espacements

La typographie fluide fait varier la taille d’un texte entre un minimum et un maximum selon la largeur de l’écran, avec la fonction CSS clamp(). Elle est désactivée par défaut dans le cœur : il faut l’activer avec typography.fluid. Chaque taille peut ensuite fixer ses propres bornes, ou refuser la fluidité.

Sans précision, WordPress calcule la fluidité entre 320 et 1 600 pixels de largeur d’écran, ou jusqu’à la largeur large du thème si elle est définie, avec un plancher de 14 pixels pour les petites tailles.

Pour les espacements, deux approches coexistent. L’échelle, spacingScale, génère une série de valeurs à partir d’une opération et d’un pas. La liste, spacingSizes, permet de nommer chaque valeur librement, et c’est la seule façon d’obtenir des espacements fluides. Twenty Twenty-Five, le thème par défaut de WordPress 7.1, utilise cette seconde approche, avec des espacements dont les plus grands sont fluides.

L’option customSpacingSize, réglée sur false, oblige les utilisateurs à choisir parmi les préréglages. Là encore, le manuel des thèmes contient une coquille, « customSpacingSizes » au pluriel, que le schéma refuse.

Des plaques de verre superposées où la lumière change de couleur à chaque couche

De la version 2 à la version 3 : les deux réglages qui ont changé

La version 3 ne change que deux comportements, liés aux préréglages du cœur. Les options defaultFontSizes et defaultSpacingSizes valent désormais true par défaut : les tailles de police et les espacements du cœur s’affichent dans l’éditeur, et un thème ne peut plus réutiliser leurs noms, comme « small » ou « large », sans désactiver ces options.

La recette de migration officielle tient en deux étapes : passer la version à 3, puis régler ces deux options. Si le thème définit ses propres tailles, mettez defaultFontSizes à false. L’ancienne astuce qui masquait l’échelle d’espacement du cœur avec un nombre de pas nul se remplace par defaultSpacingSizes à false.

Rien n’oblige à migrer : les anciennes versions restent prises en charge. La version 3 exige simplement WordPress 6.6 au minimum.

Variations de style, palettes et styles de section

Les variations de style sont des fichiers JSON placés dans le dossier /styles. Elles peuvent contenir n’importe quelle clé de theme.json et apparaissent dans les styles de l’éditeur de site. Depuis WordPress 6.6, un fichier qui ne contient que des couleurs devient une palette proposée seule, et un fichier qui ne contient que de la typographie, un jeu de typographie.

WordPress 6.6 a aussi introduit les styles de section : un fichier qui déclare une liste de types de blocs, avec la clé blockTypes, devient une variation de style applicable à ces blocs, par exemple un groupe sur fond coloré. Twenty Twenty-Five en propose plusieurs.

Voici une variation sombre minimale, placée dans /styles/dark.json. Comme elle ne contient que des couleurs, WordPress la propose comme une palette :

{
	"$schema": "https://schemas.wp.org/wp/7.1/theme.json",
	"version": 3,
	"title": "Dark",
	"settings": {
		"color": {
			"palette": [
				{ "slug": "base", "color": "#0a0a0f", "name": "Base" },
				{ "slug": "contrast", "color": "#f5f5f7", "name": "Contrast" },
				{ "slug": "accent", "color": "#764ba2", "name": "Accent" }
			]
		}
	}
}

Les identifiants (slugs) des couleurs reprennent ceux de la palette principale : c’est ce qui permet à la variation de changer l’apparence de tout le site sans toucher aux contenus. Un détail compte pour la maintenance : quand un utilisateur choisit une variation, ses données sont copiées en base comme une personnalisation. Une mise à jour ultérieure de la variation dans le thème n’atteint donc pas le site tant que l’utilisateur ne la sélectionne pas de nouveau.

Ce que WordPress 7.0 et 7.1 ont ajouté

WordPress 7.0 a permis de définir des états comme le survol pour le bloc Bouton directement dans theme.json, ajouté les dimensions de largeur et de hauteur et la superposition de navigation. Il a surtout rendu les compositions non synchronisées et les parties de modèle éditables en contenu seul par défaut, ce qui masque leurs outils de design.

WordPress 7.1 apporte les styles adaptatifs : des clés @mobile et @tablet dans les styles, et des points de rupture configurables dans settings.viewport, par défaut 480 et 782 pixels. Il n’existe pas de clé pour le bureau.

La même version donne une interface aux états comme le survol, pour les blocs Bouton et Lien personnalisé. Elle ajoute aussi l’ombre de texte dans theme.json, sans interface ni préréglages pour l’instant, et les dégradés d’arrière-plan. Notre point sur les nouveautés de WordPress 7 replace ces ajouts dans l’ensemble des deux versions.

{
	"$schema": "https://schemas.wp.org/wp/7.1/theme.json",
	"version": 3,
	"settings": { "viewport": { "mobile": "30rem", "tablet": "45rem" } },
	"styles": {
		"blocks": {
			"core/group": {
				"spacing": { "padding": { "top": "3rem", "bottom": "3rem" } },
				"@mobile": { "spacing": { "padding": { "top": "1rem", "bottom": "1rem" } } }
			}
		}
	}
}

Le cas réel : l’été où WordPress a souligné tous les liens

L’histoire de WordPress 6.6, sortie le 16 juillet 2024, montre mieux que tout exemple qu’un changement dans les styles globaux concerne tous les sites, thèmes classiques compris. Elle est entièrement documentée par les notes des développeurs, les annonces officielles et les tickets publics de Gutenberg.

Une spécificité nivelée

Pour que les auteurs de thèmes surchargent plus facilement les styles du cœur, et pour préparer les styles de section, les contributeurs de l’éditeur ont décidé d’uniformiser la spécificité CSS des styles globaux et des styles de blocs. La note de développement du 21 juin 2024 l’annonce : les sélecteurs existants seraient enveloppés dans :root :where(...), et les auteurs de thèmes étaient invités à revérifier leurs designs s’ils s’appuyaient sur du CSS aux sélecteurs complexes.

Six jours avant la sortie

Le 10 juillet 2024, un développeur, Ciprian Popescu, ouvre un ticket : les liens de sa navigation, codée à la main dans son propre thème, sont soudain soulignés. Le style de lien par défaut du theme.json du cœur, dont tous les thèmes héritent, venait de passer devant sa règle CSS. Il précise que les quatre cents sites qu’il gère risquent d’être cassés à la sortie de WordPress 6.6.

Un correctif est fusionné dans Gutenberg dès le 12 juillet, sans garantie d’entrer dans la version 6.6.0. Elle sort le 16 juillet avec le problème. Le lendemain, des utilisateurs de Divi signalent dans le même ticket le même soulignement sur tous les sites de leurs clients. Les contournements proposés vont jusqu’à réécrire le CSS des styles globaux à la volée.

Deux versions correctives

WordPress 6.6.1 sort le 23 juillet, avec la correction des liens soulignés en tête de liste. Entre-temps, un autre développeur a signalé que son thème enfant, basé sur Underscores, avait perdu sa police, sa taille de texte et son interlignage à cause du même mécanisme appliqué au sélecteur body. Ce problème-là n’a été corrigé dans le cœur qu’avec WordPress 6.6.2.

D’autres régressions suivent, sur des boutons ou des mises en page. La version candidate de 6.6.2, le 4 septembre, reconnaît que plusieurs correctifs concernent la spécificité CSS, qui faisait que des sites ne s’affichaient pas comme prévu, et invite les sites revenus à la version 6.5 à tester. WordPress 6.6.2 sort le 10 septembre, près de deux mois après la version initiale.

L’épilogue de 2026

En juillet 2026, pendant les tests de WordPress 7.1, une testeuse dont le thème limitait les palettes de texte constate qu’une couleur réglée pour le bureau l’emporte sur la couleur mobile. Les classes de préréglages au niveau des blocs sont alors à leur tour enveloppées dans :where(), avant la sortie, et le changement est documenté avec ses sélecteurs avant et après.

Ce qu’il faut en retenir

Le theme.json du cœur s’applique à tous les sites : un changement de styles globaux est aussi un risque pour les thèmes classiques. La version du schéma ne protège que ce qu’elle versionne : la version 3 encadrait les tailles et les espacements, mais le changement de spécificité a touché les thèmes en version 2 comme en version 3.

Testez les versions majeures sur une copie du site pendant la phase de versions candidates : le problème avait été signalé avant la sortie. Placez le design dans les préréglages et les styles de theme.json plutôt que dans des sélecteurs CSS d’éléments, la couche la plus fragile. Et signalez les régressions : chaque correctif de 6.6.1 et 6.6.2 est parti d’un ticket public.

Verrouiller l’éditeur pour un client

Commencer par theme.json

La façon la plus simple de limiter les choix d’un client passe par theme.json : couleurs personnalisées, dégradés, tailles de police libres et lettrines peuvent être désactivés, et une palette peut être imposée à un bloc précis.

{
	"$schema": "https://schemas.wp.org/wp/7.1/theme.json",
	"version": 3,
	"settings": {
		"color": { "custom": false, "customGradient": false, "defaultPalette": false },
		"typography": { "customFontSize": false, "dropCap": false },
		"spacing": { "customSpacingSize": false }
	}
}

Blocs autorisés et verrouillage

Le filtre allowed_block_types_all restreint les blocs disponibles, le réglage canLockBlocks réserve le verrouillage aux comptes qui gèrent le design, et deux lignes retirent les compositions du cœur et celles du répertoire en ligne :

add_filter( 'allowed_block_types_all', function ( $allowed, $editor_context ) {
	if ( ! empty( $editor_context->post ) ) {
		return array( 'core/paragraph', 'core/heading', 'core/image', 'core/list', 'core/list-item' );
	}
	return $allowed;
}, 10, 2 );

add_filter( 'block_editor_settings_all', function ( $settings ) {
	$settings['canLockBlocks'] = current_user_can( 'edit_theme_options' );
	return $settings;
} );

add_action( 'after_setup_theme', function () {
	remove_theme_support( 'core-block-patterns' );
} );
add_filter( 'should_load_remote_block_patterns', '__return_false' );

Au niveau d’un modèle ou d’un groupe, le verrouillage contentOnly masque les outils de design et ne laisse modifier que le contenu, et l’attribut lock empêche de déplacer ou de supprimer un bloc. Sur un groupe, ce mode simplifie l’interface sans tout fermer : un bouton de la barre d’outils, « Modifier la composition » dans WordPress 7.1, rouvre les outils de design, et la documentation précise qu’on ne peut pas le retirer par le code.

Par défaut, tout utilisateur qui peut modifier peut aussi déverrouiller : d’où l’intérêt de canLockBlocks. Pour aller plus loin avec des blocs supplémentaires, notre sélection de plugins de blocs Gutenberg aide à choisir sans surcharger l’éditeur.

Des réglages différents selon le rôle

Depuis WordPress 6.1, quatre filtres permettent de modifier les données de theme.json à la volée, selon leur origine : le cœur, les blocs, le thème ou l’utilisateur. On peut ainsi proposer une palette complète aux administrateurs et une palette réduite aux rédacteurs, en vérifiant les capacités du compte dans le filtre du thème. La documentation rappelle que les données injectées doivent porter un numéro de version de theme.json.

Quand le contenu seul gêne

En juin 2026, Oliver Juhas, auteur du thème de blocs Zooey et venu des thèmes classiques, constate qu’avec WordPress 7.0 le bloc Élément de modèle n’affiche plus les contrôles de hauteur minimale, de position collante et de marges que son thème lui ajoute, et qui fonctionnaient parfaitement en 6.9. En cause : le nouveau mode contenu seul par défaut. Un mainteneur reconnaît un effet secondaire malheureux, et le correctif est intégré à WordPress 7.0.1.

WordPress 7.1 a ensuite ajouté un réglage documenté, disableContentOnlyForTemplateParts, à côté de disableContentOnlyForUnsyncedPatterns apparu en 7.0. Si votre thème étend les blocs du cœur, testez-le pendant les versions candidates.

Migrer un thème classique, étape par étape

Le manuel des thèmes ne propose plus de page de conversion : son ancienne adresse renvoie une erreur. Learn WordPress publie en revanche une leçon, « Converting a Classic theme to a Block theme », et le chemin se complète avec plusieurs autres ressources officielles.

  1. Ajouter un theme.json au thème classique, pour la palette, la typographie et la mise en page.
  2. Passer aux parties de modèle en blocs, possibles dans un thème classique depuis WordPress 6.1 une fois déclaré add_theme_support( 'block-template-parts' ), puis appelées en PHP avec block_template_part().
  3. Créer des modèles de blocs, puis ajouter templates/index.html : le thème devient alors un thème de blocs.
  4. Importer les zones de widgets, une fonction du bloc Élément de modèle depuis WordPress 6.2.
  5. Enregistrer dans les fichiers les modifications faites dans l’éditeur de site, avec Create Block Theme, dont la dernière version date de juin 2026.

Côté administration, le changement se voit. Avec un thème de blocs, l’outil de personnalisation disparaît, les widgets laissent place aux parties de modèle, et l’éditeur de fichiers du thème passe dans le menu Outils. Prévenez les personnes qui gèrent le site au quotidien avant la bascule, pas après.

Chaque étape se teste sur une copie du site, avec une sauvegarde à jour. Notre guide pour migrer un site WordPress sans interruption détaille la mise en place d’une copie de test et la bascule.

Tableau récapitulatif

Notion Où elle vit Depuis Point de vigilance
Thème de blocs templates/index.html WordPress 5.9 theme.json seul ne suffit pas
theme.json version 3 Racine du thème WordPress 6.6 Pas de version 4, manuel des thèmes en retard
Modifications de l’éditeur de site Base de données WordPress 5.9 Priment sur les fichiers du thème
Variations de style Dossier /styles WordPress 6.0 Copiées en base une fois choisies
Styles de section /styles avec blockTypes WordPress 6.6 Limités aux blocs déclarés
Contenu seul par défaut Compositions, parties de modèle WordPress 7.0 Réglages de désactivation documentés
Styles adaptatifs @mobile, @tablet, settings.viewport WordPress 7.1 Refusés par le schéma de 7.0

Questions fréquentes

Existe-t-il une version 4 de theme.json ?

Non. WordPress 7.1 utilise toujours la version 3, introduite avec WordPress 6.6. Le schéma de la branche de développement contient des clés à venir, mais aucune nouvelle version.

Un thème classique peut-il utiliser theme.json ?

Oui. Le fichier fonctionne avec les deux types de thèmes. Il permet à un thème classique de définir sa palette, sa typographie et sa mise en page dans l’éditeur de blocs, sans lui donner accès aux modèles ni aux styles globaux de l’éditeur de site.

Pourquoi mes modifications de l’éditeur de site n’apparaissent-elles pas après une mise à jour du thème ?

Parce que c’est l’inverse : vos modifications, enregistrées en base, priment sur les fichiers du thème. Ce sont les nouveautés du thème qui n’apparaissent pas sur les modèles que vous avez modifiés. Réinitialiser un modèle dans l’éditeur de site le ramène à la version du thème.

Comment empêcher un client de choisir des couleurs libres ?

Dans theme.json, mettez color.custom et color.customGradient à false, et remplacez la palette du cœur par la vôtre. Le client ne pourra plus choisir que parmi vos couleurs.

Faut-il le plugin Create Block Theme ?

Pas pour utiliser un thème de blocs. Il devient utile pour créer un thème enfant, une variation de style, ou réenregistrer dans les fichiers les modifications faites dans l’éditeur de site. Sa dernière version date de juin 2026, et sa fiche n’annonce des tests que jusqu’à WordPress 6.9 : essayez-le d’abord sur une copie du site.

Conclusion

L’édition complète de site repose sur une idée simple : un fichier, theme.json, décrit le design, et l’éditeur de site laisse l’utilisateur le modifier sans toucher au code. En pratique, il faut connaître la version en vigueur, se méfier des pages de documentation en retard, et comprendre que les modifications de l’utilisateur vivent en base.

L’été 2024 l’a rappelé : ce fichier ne concerne pas que les thèmes de blocs. Que votre thème soit de blocs, hybride ou classique, testez chaque version majeure de WordPress sur une copie, et placez votre design dans les préréglages de theme.json plutôt que dans des surcharges CSS fragiles.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier