Demander « cet utilisateur est-il administrateur ? » avant d’autoriser une action semble intuitif, mais devient vite rigide : que faire si l’on veut qu’un simple auteur puisse aussi publier des articles sans passer administrateur ? WordPress évite ce piège en séparant deux notions : la capacité, une permission précise et nommée comme edit_posts ou manage_options, et le rôle, un ensemble de capacités regroupées sous un nom (Administrateur, Éditeur, Auteur). Le code ne devrait presque jamais tester un rôle directement, mais toujours une capacité.
Fonctionnement dans WordPress
La fonction current_user_can( 'capacite' ) est le point d’entrée standard pour vérifier une permission avant d’afficher une option ou d’exécuter une action sensible. Une extension peut ajouter de nouvelles capacités à un rôle existant avec add_cap() sur un objet WP_Role, ou définir des permissions plus fines encore, spécifiques à un article précis, via le filtre map_meta_cap, qui traduit une capacité générique en vérifications concrètes.
Exemple
if ( current_user_can( 'edit_others_posts' ) ) {
// Afficher le bouton de modification pour tous les articles
}
$role = get_role( 'contributeur' );
$role->add_cap( 'upload_files' );À ne pas confondre avec
- Le rôle, qui n’est qu’un regroupement nommé de capacités : deux sites peuvent très bien redéfinir ce que contient le rôle « Éditeur » sans changer le fonctionnement de l’API des capacités elle-même.
- L’Abilities API, plus récente, qui décrit des actions exécutables destinées à des agents logiciels et s’appuie sur cette même API des capacités pour la partie permissions, sans s’y substituer.
- Une vérification de connexion simple (
is_user_logged_in()), qui ne dit rien des permissions réelles de l’utilisateur, contrairement à une vérification de capacité précise.