Restreindre l’éditeur de site par rôle : capacités et menus à masquer

Problème : sur un site client géré au quotidien par deux rédacteurs sous le rôle Éditeur, l’un d’eux a modifié « juste pour essayer » la palette de couleurs globale depuis le panneau Styles, changeant l’identité visuelle du site entier sans en avoir conscience. Le rôle Éditeur, par défaut dans WordPress, dispose de la capacité edit_theme_options — celle-là même qui conditionne l’accès à l’éditeur de site, aux styles globaux et aux menus de navigation classiques.

Diagnostic : une seule capacité ouvre beaucoup de portes

Retirer edit_theme_options à un rôle bloque effectivement l’accès à l’éditeur de site, mais aussi, du même coup, la gestion des menus de navigation classiques et l’accès aux widgets sur les thèmes qui en dépendent encore. Une retrait brutal, sans discernement, casse souvent plus qu’il ne corrige — d’où l’intérêt de cibler précisément ce qui doit rester accessible.

Correctif : retirer la capacité puis la redonner sélectivement là où elle est nécessaire

<?php
/**
 * Retire l'accès à l'éditeur de site pour le rôle Éditeur,
 * sans toucher aux autres rôles ni aux administrateurs.
 */
function wpm_restreindre_editeur_site() {
    $role = get_role( 'editor' );

    if ( $role instanceof WP_Role && $role->has_cap( 'edit_theme_options' ) ) {
        $role->remove_cap( 'edit_theme_options' );
    }
}
add_action( 'admin_init', 'wpm_restreindre_editeur_site' );

/**
 * Masque le menu de l'éditeur de site pour qui n'a plus la capacité,
 * en complément du retrait ci-dessus (jamais à la place).
 */
function wpm_masquer_menu_editeur_site() {
    if ( ! current_user_can( 'edit_theme_options' ) ) {
        remove_menu_page( 'site-editor.php' );
    }
}
add_action( 'admin_menu', 'wpm_masquer_menu_editeur_site', 999 );

Le premier bloc agit sur la vraie porte d’entrée : sans la capacité, un accès direct à l’URL de l’éditeur de site (/wp-admin/site-editor.php) se solde par un refus d’accès WordPress standard, quel que soit ce qui est affiché ou masqué dans les menus. Le second bloc n’est qu’un confort d’interface : il évite d’afficher un lien menant vers un écran de toute façon interdit, mais ne remplace jamais le contrôle de capacité — masquer un menu sans retirer la capacité sous-jacente ne protège de rien face à un accès direct par URL.

Prévention : vérifier les effets de bord sur les autres écrans

Sur un thème encore partiellement classique, retirer edit_theme_options peut aussi masquer l’accès aux widgets ou aux menus de navigation classiques pour ce rôle. Si ces écrans doivent rester accessibles indépendamment de l’éditeur de site, il faut soit les gérer avec une capacité personnalisée dédiée créée pour l’occasion, soit accepter ce compromis si l’équipe éditoriale n’a de toute façon pas vocation à y toucher.

Variantes selon le besoin exact

• Autoriser l’accès aux templates mais pas aux styles globaux : plus délicat, car les deux dépendent de la même capacité principale ; la voie la plus fiable reste un filtre sur user_has_cap qui neutralise edit_theme_options uniquement lorsque l’écran courant correspond au panneau Styles, repéré via un paramètre de requête spécifique à cet onglet.
• N’autoriser qu’un seul compte précis, indépendamment de son rôle : conditionner le retrait de capacité à ! in_array( $user->user_login, array( 'nom-autorise' ), true ) dans la fonction ci-dessus, plutôt que de cibler un rôle entier.
• Bloquer uniquement la modification des styles globaux, en lecture seule pour le reste : filtrer plus finement les capacités liées au post type wp_global_styles via map_meta_cap, en laissant edit_theme_options intacte pour ne pas perdre l’accès aux templates.

Ce qu’il ne faut pas faire

Masquer un lien de menu sans jamais toucher à la capacité sous-jacente donne une fausse impression de sécurité : n’importe qui connaissant l’URL directe de l’éditeur de site continue d’y accéder normalement.

En résumé

La restriction de l’éditeur de site par rôle passe presque toujours par la capacité edit_theme_options, qui contrôle bien plus large que le seul éditeur de site. Toute restriction sérieuse doit donc être testée sur l’ensemble des écrans qui en dépendent, et jamais se limiter au seul masquage visuel d’un menu, qui ne constitue en rien une protection réelle.