Sur un site éditorial géré par une dizaine de rédacteurs et deux responsables de la charte graphique, un problème récurrent est apparu peu après le passage à l’éditeur de site : n’importe quel utilisateur disposant de la capacité générale edit_theme_options pouvait aussi bien modifier un simple réglage de couleur que bouleverser la structure entière d’un gabarit, sans distinction possible entre ces deux niveaux de responsabilité pourtant très différents.
Le besoin exprimé par le client était précis : les deux responsables de charte graphique devaient pouvoir ajuster librement les styles globaux, sans jamais avoir accès à la modification des templates eux-mêmes, jugée bien plus risquée pour la stabilité du site.
Comprendre le mécanisme de capacité sous-jacent
En interne, WordPress enregistre les styles globaux comme des articles d’un type de contenu particulier, wp_global_styles, dont les capacités par défaut sont mappées sur edit_theme_options, exactement comme pour les templates et template parts. Cette mutualisation explique pourquoi il n’existe, par défaut, aucune séparation fine entre ces deux univers pourtant distincts pour un utilisateur non technique.
Pour séparer ces deux responsabilités, la solution retenue a consisté à intercepter l’enregistrement de ce type de contenu via le filtre register_post_type_args, afin de lui attribuer une capacité personnalisée distincte, puis à accorder cette capacité uniquement aux rôles concernés.
Mise en œuvre du filtre personnalisé
add_filter( 'register_post_type_args', function( $args, $post_type ) {
if ( 'wp_global_styles' === $post_type ) {
$args['capabilities'] = array(
'read' => 'edit_styles_globaux',
'edit_posts' => 'edit_styles_globaux',
'edit_others_posts' => 'edit_styles_globaux',
'publish_posts' => 'edit_styles_globaux',
'edit_published_posts' => 'edit_styles_globaux',
);
}
return $args;
}, 10, 2 );
Une fois cette capacité personnalisée déclarée, elle a été attribuée explicitement aux deux comptes des responsables de charte graphique via add_cap( 'edit_styles_globaux' ) sur leur rôle dédié, créé spécifiquement pour l’occasion plutôt que de modifier un rôle générique existant partagé avec d’autres usages.
Vérifier que la séparation fonctionne réellement
- Se connecter avec un compte disposant uniquement de la nouvelle capacité et confirmer l’accès effectif au panneau Styles de l’éditeur de site.
- Confirmer, avec ce même compte, l’impossibilité d’accéder à l’écran de modification des templates, qui doit rester conditionné à la capacité
edit_theme_optionsclassique. - Tester également l’accès via l’API REST, en particulier l’endpoint
/wp/v2/global-styles/(id), pour s’assurer que la restriction s’applique aussi côté programmatique et pas uniquement dans l’interface visuelle.
Ce dernier point de vérification s’est révélé important : une extension tierce installée sur le site interrogeait directement cet endpoint REST pour un usage de prévisualisation, et il fallait confirmer que la nouvelle capacité s’appliquait bien également à ce niveau, sans faille de contournement.
Une limite assumée de cette approche
Cette séparation reste propre aux styles globaux enregistrés comme entité de contenu. Certains réglages visuels ponctuels, appliqués directement au niveau d’un bloc individuel dans un gabarit, restent quant à eux couverts par la capacité de modification du template lui-même, sans distinction possible avec cette méthode. La séparation, bien que déjà très utile, n’est donc pas totalement étanche sur l’ensemble des cas de figure du site.
Une capacité personnalisée bien pensée vaut mieux qu’un rôle générique surchargé de permissions approximatives. C’est un peu plus de code à écrire, mais beaucoup moins de confusion à gérer ensuite au quotidien.
Notre verdict
Cette séparation fine des capacités a nettement rassuré le client, qui pouvait enfin déléguer la charte graphique sans craindre une modification accidentelle de la structure du site. Je recommande cette approche à tout projet où plusieurs profils d’éditeurs coexistent avec des niveaux de responsabilité réellement différents sur l’éditeur de site.
