# Restreindre couleurs et blocs disponibles selon le rôle utilisateur

> Livrer un site à une équipe marketing peu technique implique de limiter ce qu'elle peut casser. Combinaison de capacités personnalisées et theme.json restreint, étape par étape.

- Auteur : Clément Hadrot
- Publié le : 2024-08-05
- Mis à jour le : 2024-08-05
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/restreindre-couleurs-blocs-par-role/

## L’essentiel

- Une capacité personnalisée par rôle limite l'accès aux réglages sensibles
- theme.json restreint évite les couleurs hors palette validée
- Les deux mécanismes se combinent sans plugin tiers

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

> L'essentiel à retenir : Une capacité personnalisée par rôle limite l'accès aux réglages sensibles ; theme.json restreint évite les couleurs hors palette validée ; Les deux mécanismes se combinent sans plugin tiers

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.