Capacités et rôles : qui peut réellement modifier un template du Site Editor

Qui, sur un site utilisant le plugin Gutenberg avec l’éditeur de site expérimental activé, a le droit de modifier un gabarit ? La question paraît simple, mais la réponse implique de comprendre un mécanisme peu documenté à ce stade : les capacités de gabarits ne suivent pas exactement les mêmes règles que celles des articles.

Ce billet s’adresse à un développeur qui doit restreindre l’accès à l’éditeur de site expérimental à une poignée de personnes, sans pour autant priver l’administrateur de ses droits habituels. Il ne traite pas de la restriction par capacité d’un bloc précis à l’intérieur de l’éditeur, seulement de l’accès à l’écran lui-même et aux gabarits qu’il expose.

Une capacité héritée, pas une nouvelle

L’écran expérimental d’édition de site ne repose pas sur une capacité inédite. Il s’appuie sur edit_theme_options, la même capacité qui contrôle historiquement l’accès aux menus, aux widgets et à l’éditeur de thème classique. Par défaut, seuls les rôles administrateur en disposent, ce qui explique pourquoi l’éditeur de site expérimental reste, en pratique, invisible pour les rôles éditeur ou auteur.

$roles = wp_roles();
$administrateur = $roles->get_role( 'administrator' );
var_dump( $administrateur->has_cap( 'edit_theme_options' ) ); // true

Le piège du blocage complet

La tentation la plus courante, pour restreindre l’accès à l’éditeur de site expérimental, consiste à retirer purement et simplement la capacité edit_theme_options au rôle administrateur. Cette approche fonctionne, mais elle bloque en même temps l’accès aux menus et aux widgets classiques, ce qui dépasse largement l’intention initiale.

• Retirer edit_theme_options à l’administrateur bloque aussi les menus et les widgets.
• Créer un rôle intermédiaire permet de découpler ces accès sans toucher au rôle administrateur natif.
• Un filtre sur les capacités au moment précis de l’accès à l’écran évite de modifier durablement la table des rôles.

Une approche plus fine avec map_meta_cap

Plutôt que de manipuler directement les rôles, il est possible d’intercepter la vérification de capacité au moment précis où l’éditeur de site expérimental la demande, grâce au filtre map_meta_cap :

add_filter( 'map_meta_cap', function( $caps, $cap, $user_id ) {
    if ( 'edit_theme_options' === $cap ) {
        $utilisateur_autorise = in_array(
            $user_id,
            array( 4, 7 ), // identifiants autorisés à modifier les gabarits
            true
        );

        if ( ! $utilisateur_autorise ) {
            return array( 'do_not_allow' );
        }
    }

    return $caps;
}, 10, 3 );

Cette approche a un défaut assumé : elle est grossière, car elle bloque toute la capacité, y compris pour les menus et les widgets, pour les utilisateurs non listés. Elle convient pour un test rapide, mais pas pour une distinction fine entre accès aux gabarits et accès aux menus.

Distinguer gabarits et reste du thème

Pour une distinction plus rigoureuse, il faut s’intéresser au contexte de l’appel plutôt qu’à la seule capacité demandée. L’écran de l’éditeur de site expérimental s’exécute sur une page d’administration identifiable, ce qui permet de conditionner la restriction à ce contexte précis plutôt qu’à la capacité seule, en vérifiant par exemple le paramètre de page courant avant d’appliquer une restriction supplémentaire.

Restreindre une capacité sans regarder le contexte revient souvent à réparer un problème en en créant un autre, plus discret, qui n’apparaît que des semaines plus tard.

Une prudence propre à l’expérimental

Comme l’éditeur de site reste, à cette date, une fonctionnalité expérimentale du plugin Gutenberg, la façon dont les capacités y sont vérifiées pourrait évoluer avant une éventuelle stabilisation dans le cœur de WordPress. Tout mécanisme de restriction construit aujourd’hui devra être revu au moment de cette stabilisation, plutôt que considéré comme définitivement acquis.

En résumé

L’accès à l’éditeur de site expérimental repose, pour l’instant, sur la capacité edit_theme_options, héritée des mécanismes plus anciens de gestion des menus et des widgets. La retirer sans discernement bloque plus que prévu ; une vérification contextuelle, via map_meta_cap ou une lecture fine de l’écran courant, reste la voie la plus sûre pour restreindre l’accès sans priver l’administrateur de ses droits habituels.