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

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']);
  }
});

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.