# Un bloc réservé à un rôle, filtré dans l’inserteur sans PHP

> Réserver un bloc maison à l'équipe marketing sans passer par une liste noire générale de blocs, en agissant directement côté JavaScript de l'éditeur.

- Auteur : Clément Hadrot
- Publié le : 2025-10-20
- Mis à jour le : 2025-10-20
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/bloc-reserve-role-filtre-inserteur-sans-php/

## L’essentiel

- hideBlockTypes masque un bloc précis sans toucher aux autres
- Le rôle de l'utilisateur courant est lu via la donnée localisée du script
- Ce filtrage reste côté interface, pas une sécurité serveur

La rédaction du magazine en ligne de l'Atelier Nomade voulait qu'un bloc « bandeau de campagne » créé pour l'équipe marketing reste invisible pour les rédacteurs, sans pour autant restreindre l'accès aux quinze autres blocs maison du site. La solution habituelle, `allowedBlockTypes` côté serveur, fonctionne bien pour restreindre un ensemble large de blocs à un contexte donné (un type de contenu, par exemple), mais s'avère mal adaptée ici : elle exige de lister explicitement tous les blocs autorisés, un entretien lourd à chaque ajout de nouveau bloc au plugin.

La solution retenue agit directement dans l'éditeur, côté JavaScript, avec l'action `hideBlockTypes` du store `core/edit-post`, appliquée conditionnellement selon le rôle de l'utilisateur connecté.

## Transmettre le rôle de l'utilisateur à l'éditeur

Le rôle n'est pas nativement exposé côté JavaScript de l'éditeur ; il faut le transmettre via une donnée localisée au moment de l'enregistrement du script :

```
add_action( 'enqueue_block_editor_assets', function () {
    $utilisateur = wp_get_current_user();
    wp_localize_script( 'atelier-nomade-filtre-blocs', 'atelierNomadeUtilisateur', [
        'roles' => $utilisateur->roles,
    ] );
} );
```

## Masquer le bloc côté JavaScript

Une fois le rôle disponible, un script chargé sur l'écran d'édition appelle `hideBlockTypes` dès que l'éditeur est prêt, en excluant l'équipe marketing (identifiée ici par un rôle personnalisé `equipe_marketing`) de la restriction :

```
import { dispatch } from '@wordpress/data';
import domReady from '@wordpress/dom-ready';

domReady(() => {
  const roles = window.atelierNomadeUtilisateur?.roles || [];
  const estMarketing = roles.includes('equipe_marketing') || roles.includes('administrator');

  if (!estMarketing) {
    dispatch('core/edit-post').hideBlockTypes(['atelier-nomade/bandeau-campagne']);
  }
});
```

> L'essentiel à retenir : hideBlockTypes masque un bloc précis sans toucher aux autres ; Le rôle de l'utilisateur courant est lu via la donnée localisée du script ; Ce filtrage reste côté interface, pas une sécurité serveur

Le bloc disparaît de l'inserteur pour tout utilisateur dont le rôle ne correspond pas à la liste autorisée, sans qu'il soit nécessaire de toucher aux autres blocs du plugin ni de maintenir une liste blanche qui grossirait à chaque ajout.

## Une limite à ne pas négliger : ceci reste un filtre d'interface

`hideBlockTypes` agit uniquement sur l'affichage dans l'inserteur de l'éditeur ; il n'empêche en rien qu'un contenu contenant déjà ce bloc s'affiche normalement, ni qu'une requête REST directe vers l'API des articles insère ce bloc dans le contenu d'une page. Pour une véritable restriction de sécurité (empêcher un rôle de publier ce contenu par un autre biais), il faudrait la combiner à un contrôle serveur, par exemple une vérification lors de l'enregistrement du contenu via `rest_pre_insert_post` vérifiant la présence du bloc et la capacité de l'utilisateur.

- `hideBlockTypes` convient à un confort d'usage pour les rédacteurs, pas à une restriction de sécurité stricte.
- Le rôle transmis en donnée localisée doit rester cohérent avec les capacités réelles vérifiées côté serveur si un contrôle plus strict est nécessaire ailleurs.
- Documenter clairement, pour l'équipe, que ce mécanisme masque sans interdire réellement l'insertion par un autre canal.

## Pourquoi pas allowedBlockTypes ici

Le filtre `allowedBlockTypes`, appliqué côté serveur via le hook du même nom, reste la solution adaptée quand il s'agit de restreindre un ensemble de blocs à un contexte précis (un type de contenu, un rôle très restreint sur un site entier). Il devient en revanche disproportionné pour masquer un unique bloc à un seul groupe d'utilisateurs sur un site qui en compte des dizaines : il faudrait alors soit inverser la logique en listant tout ce qui reste autorisé, soit dupliquer la même liste à chaque ajout de nouveau bloc, ce qui est exactement le fardeau que cette solution cherche à éviter.

> Masquer un bloc à un groupe d'utilisateurs n'est pas la même question que sécuriser son insertion : l'une se résout dans l'interface, l'autre se vérifie sur le serveur.

## En résumé

En ciblant précisément le bloc à restreindre plutôt que de gérer une liste blanche de quinze blocs autorisés, l'Atelier Nomade a résolu le besoin exprimé par la rédaction en une vingtaine de lignes de code, sans jamais toucher à la configuration serveur des types de blocs autorisés.