Une association cliente venait de recruter une chargée de communication sans formation technique particulière, chargée de mettre à jour elle-même les actualités du site. Le brief était clair : elle devait pouvoir modifier du texte et ajouter des images librement, mais surtout ne pas pouvoir choisir une couleur de bouton fluo ou insérer un bloc Vidéo YouTube en pleine page d’accueil sans le vouloir.
La solution ne nécessitait aucun plugin de restriction : une combinaison de capacités WordPress personnalisées et d’un theme.json volontairement restreint suffit à encadrer l’usage sans bloquer la créativité éditoriale légitime.
Étape 1 : identifier ce qui doit rester ouvert et ce qui doit être verrouillé
Avant d’écrire la moindre ligne de code, j’ai listé avec la cliente ce qu’elle utiliserait réellement au quotidien : modification de texte, ajout d’images, création d’articles avec le pattern de mise en page standard du site. À l’inverse, la modification des couleurs, la police de caractères et l’ajout de blocs comme Code personnalisé ou HTML brut ne faisaient partie d’aucun besoin exprimé.
Étape 2 : restreindre la palette dans theme.json
Le premier verrou, le plus simple, consiste à définir une palette de couleurs fermée dans theme.json, en désactivant explicitement la personnalisation libre. Sans cette étape, l’éditeur propose par défaut un sélecteur de couleur illimité, en plus de la palette du thème, ce qui ouvre la porte à n’importe quelle teinte.
{
"version": 2,
"settings": {
"color": {
"custom": false,
"customGradient": false,
"defaultPalette": false,
"palette": [
{ "slug": "primaire", "color": "#1d3557", "name": "Bleu principal" },
{ "slug": "accent", "color": "#e63946", "name": "Rouge accent" },
{ "slug": "neutre-clair", "color": "#f1faee", "name": "Fond clair" },
{ "slug": "neutre-fonce", "color": "#1d1d1d", "name": "Texte foncé" }
]
},
"typography": {
"customFontSize": false,
"fontFamilies": [
{ "slug": "titre", "fontFamily": "\"Fraunces\", serif", "name": "Titres" }
]
}
}
}Avec "custom": false, la palette proposée à la cliente se limite exactement aux quatre couleurs définies, sans sélecteur libre. Le réglage customFontSize: false retire de la même façon le contrôle manuel de la taille de police, forçant l’usage des tailles prédéfinies dans le thème.
Étape 3 : restreindre les blocs disponibles par capacité
Le deuxième verrou concerne les blocs eux-mêmes. WordPress permet de retirer des blocs de l’inserteur en fonction d’une capacité utilisateur, via le filtre allowed_block_types_all, appliqué côté serveur. J’ai créé une capacité personnalisée edit_advanced_blocks, attribuée uniquement au rôle Administrateur, et j’ai filtré la liste des blocs disponibles pour les autres rôles.
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $context ) {
if ( current_user_can( 'edit_advanced_blocks' ) ) {
return $allowed_blocks;
}
return array(
'core/paragraph',
'core/heading',
'core/image',
'core/list',
'core/list-item',
'core/quote',
'core/gallery',
'core/pattern',
);
}, 10, 2 );Ce filtre s’applique à tous les contextes d’édition, y compris l’éditeur de site lui-même. Un rôle Éditeur ou Auteur ne voit alors plus apparaître les blocs Code personnalisé, HTML brut, ou Groupe en disposition libre, ce qui évite bien des dérapages visuels sans jamais empêcher la publication d’articles.
Attribuer la capacité au bon rôle
add_action( 'init', function() {
$admin = get_role( 'administrator' );
if ( $admin && ! $admin->has_cap( 'edit_advanced_blocks' ) ) {
$admin->add_cap( 'edit_advanced_blocks' );
}
} );Étape 4 : verrouiller l’accès à l’éditeur de site lui-même
Un dernier point mérite attention : par défaut, seuls les administrateurs ont accès à l’éditeur de site (menu Apparence > Éditeur), grâce à la capacité native edit_theme_options. Sur ce projet, aucune action supplémentaire n’a donc été nécessaire à ce niveau : la cliente, avec un rôle Éditeur standard, n’avait déjà pas accès à la zone Styles ni aux templates, uniquement à la création de contenu classique.
- Rôle Administrateur : accès complet, y compris blocs avancés et éditeur de site.
- Rôle Éditeur (la cliente) : blocs de contenu de base, patterns validés, aucune modification de styles.
- Rôle Auteur (bénévoles occasionnels) : mêmes restrictions, plus une validation éditoriale avant publication.
Restreindre l’éditeur ne consiste pas à brider la créativité, mais à retirer les options qui ne correspondent à aucun besoin réel exprimé par l’utilisateur final. Une palette de quatre couleurs bien choisies vaut mieux qu’un sélecteur illimité mal utilisé.
En résumé
Combiner une palette fermée dans theme.json et un filtre de blocs conditionné par une capacité personnalisée permet de livrer un site FSE à une équipe non technique en toute confiance, sans plugin de restriction tiers. Cette approche reste entièrement documentée dans le code du thème, ce qui facilite grandement sa maintenance future par une autre équipe.
