Chaque fois qu’un visiteur du site s’inscrit, crée un compte, ou que vous ajoutez manuellement un nouvel utilisateur dans l’administration, WordPress enregistre les données utilisateur essentielles dans les tables wp_users et wp_usermeta. Le nouvel utilisateur reçoit le nom d’utilisateur de son choix, un mot de passe, une adresse email et un rôle qui détermine ce qu’il peut voir dans le panneau d’administration. Mais que sont exactement les rôles utilisateur de WordPress ?

Rôles et prmissions utilisateurs dans WordPress

Le système de gestion des utilisateurs de WordPress repose sur deux concepts clés : Rôles et Permissions.

  • Un rôle identifie un groupe d’utilisateurs qui sont autorisés à exécuter les mêmes tâches sur le site Web.
  • Une permission est la capacité (ou l’autorisation) d’exécuter chaque tâche individuelle assignée à un rôle.

WordPress est livré prêt à l’emploi avec six rôles :

  • Le Super Administrateur est un utilisateur qui a un accès complet aux fonctionnalités multisites : il peut créer et gérer des sous-sites, créer et gérer des utilisateurs sur le réseau, installer et supprimer des thèmes et plugins et les activer sur le réseau.
  • L’Administrateur est un utilisateur qui a un accès complet aux fonctions d’administration d’une installation WordPress régulière.
  • L’Éditeur est un utilisateur qui peut éditer et publier le contenu créé par n’importe quel utilisateur.
  • L’Auteur peut publier et éditer son propre contenu.
  • Le Contributeur peut créer et éditer mais pas publier son propre contenu.
  • L’Abonné ne peut accéder qu’à son profil.

Ces rôles utilisateur WordPress sont hiérarchiquement ordonnés, ce qui signifie que les rôles de niveau supérieur ont les mêmes permissions que les rôles inférieurs, plus un certain nombre de permissions spécifiques aux rôles.

Considérons le tableau suivant :

Abonné Contributeur Éditeur
read read read
edit_posts edit_posts
delete_posts delete_posts
delete_published_posts
publish_posts
upload_files
edit_published_posts

Un Contributeur a la même capacité de lecture qu’un Abonné, mais il a deux autres permissions, edit_posts et delete_posts, qui sont spécifiques à ce rôle : le contributeur peut créer, modifier et supprimer ses propres articles non publiés.
Un éditeur a les mêmes permissions qu’un contributeur, et en plus, il peut publier, éditer et supprimer ses propres articles, et télécharger des fichiers multimédia.

Il faut distinguer deux types de permissions :

  • Les permissions méta dépendent du contexte (c’est-à-dire de l’utilisateur connecté et de l’article ou de la page en cours).
  • Les permissions primitives ne dépendent pas du contexte (ex : éditer les articles créés par d’autres utilisateurs)

Un utilisateur peut éditer un article s’il est l’auteur de cet article (permission méta ‘edit_post’) ou s’il a la permission d’éditer les articles créés par d’autres utilisateurs (permission primitive ‘edit_others_posts’).
WordPress traduit automatiquement les permissions méta en une ou plusieurs permissions primitives pour les articles réguliers, mais lorsque nous utilisons les types de posts, nous devons mapper manuellement les permissions méta aux permissions primitives.
Voir le Codex pour une liste complète des permissions intégrées.

Les rôles et permissions par défaut suffisent généralement aux exigences les plus courantes d’un site Web, mais il vous sera parfois demandé de fournir à l’administrateur du site un contrôle plus granulaire sur ce que les utilisateurs peuvent voir et faire.
Heureusement, en tant qu’utilisateurs et/ou développeurs de WordPress, nous ne sommes pas limités aux rôles et permissions par défaut, car WordPress nous permet de créer de nouvelles permissions et de nouveaux rôles, et d’attribuer différents ensembles de permissions aux rôles existants. À titre d’exemple, vous pouvez assigner aux Abonnés la capacité de créer et d’éditer des articles, et/ou assigner aux Contributeurs la capacité de publier. Mais vous pouvez obtenir beaucoup plus du système de gestion des utilisateurs :

  • Vous pouvez afficher/masquer les éléments du front-end – comme les éléments de menu, les articles ou les widgets – selon le rôle de l’utilisateur
  • Vous pouvez personnaliser le contenu de l’article en fonction de l’utilisateur
  • Vous pouvez restreindre l’accès à des sections spécifiques du site pour des utilisateurs ou des rôles spécifiques
  • Vous pouvez créer des types de postes personnalisés avec des permissions personnalisées qui peuvent être déclinées différemment pour chaque rôle

Ce dernier point marque l’objectif de cet article.

Élèves, Enseignants et Devoirs

Supposons que vous construisez un site Web éducatif où les élèves et les enseignants sont autorisés à interagir les uns avec les autres. Les élèves devraient créer des projets et les soumettre pour examen.
Les enseignants devraient être en mesure de réviser les projets des élèves et de les publier s’ils sont approuvés.
Les commentaires sont permis : les élèves peuvent commenter n’importe quel projet, mais seuls les enseignants peuvent modérer les commentaires.
Voici notre liste de choses à faire :

  • Ajouter les rôles d’utilisateur des élèves et des enseignants
  • Enregistrer le type de poste projet_etudiant et la taxonomie personnalisée du sujet
  • Enregistrer et mapper les permissions spécifiques pour le type de poste projet_etudiant
  • Attribuer des permissions aux rôles d’administrateur, d’étudiant et d’enseignant

Nous disséquerons le sujet principalement du point de vue d’un développeur, en construisant un plugin qui enregistre le type de poste personnalisé et la taxonomie, les rôles et les permissions. Mais nous n’oublierons pas les non-développeurs, et dans la dernière partie de cet article, je proposerai certains des plugins les plus populaires et les plus complets que vous trouverez pour gérer les rôles utilisateurs et les permissions comme un pro sans écrire une seule ligne de code.

Avant de lire l’article, jetez un coup d’oeil au code du plugin sur Gist

Enregistrer les rôles et les permissions des utilisateurs de WordPress

Les élèves pourront lire tous les projets et créer, modifier et supprimer leurs propres projets. Ils ne seront pas autorisés à publier des projets, ni à éditer ou supprimer des projets publiés.
Les enseignants doivent contrôler tous les aspects de l’administration du projet. Ils pourront créer de nouveaux projets, éditer, supprimer et publier les projets créés par n’importe quel utilisateur.

Affectation du rôle Étudiant à un nouvel utilisateur dans l’écran d’ajout d’un utilisateur

Affectation du rôle Étudiant à un nouvel utilisateur dans l’écran d’ajout d’un utilisateur

Cela étant dit, inscrivons les rôles des élèves et des enseignants :

function kinsta_add_roles() {
	add_role( 'student', 'Student', array( 
		'read' => true, 
		'edit_posts'   => true, 
		'delete_posts' => true ) );
	add_role( 'teacher', 'Teacher', array( 
		'read' => true, 
		'edit_posts'   => true, 
		'delete_posts' => true,
		'delete_published_posts' => true,
		'publish_posts' => true,
		'upload_files' => true,
		'edit_published_posts' => true,
		'manage_categories' => true ) );
}
register_activation_hook( __FILE__, 'kinsta_add_roles' );
  • register_activation_hook enregistre une fonction à exécuter lorsqu’un plugin est activé. Ici, il est préférable à un hook d’action comme init, car les nouveaux rôles sont enregistrés dans la base de données, et nous n’avons pas besoin d’exécuter la fonction chaque fois que WordPress se charge. register_activation_hook conserve deux arguments : le chemin vers le fichier principal du plugin (__FILE__), et la fonction callback à exécuter (‘kinsta_add_roles’).
  • Lors de l’activation du plugin, register_activation_hook est exécuté, et add_role enregistre le nouveau rôle dans la table wp_options s’il n’existe pas. Cette seconde fonction conserve trois arguments : nom du rôle, nom d’affichage et un tableau des permissions.

La fonction de rappel ajoute deux rôles. Chaque rôle est doté d’un ensemble différent de permissions : les étudiants seront autorisés à lire les articles publics, à créer, modifier et supprimer leurs propres articles s’ils ne sont pas publiés. Les enseignants pourront publier leurs propres articles, éditer et supprimer les articles publiés, télécharger des fichiers multimédia et gérer des catégories.

L'image montre le menu Rôle dans l'écran Profil utilisateur

L’image montre le menu Rôle dans l’écran Profil utilisateur

Maintenant, nous pouvons créer une communauté d’étudiants et d’enseignants, mais ils ne sont pas beaucoup plus que des contributeurs et des éditeurs. Faisons donc un pas en avant, et enregistrons un type de poste personnalisé pour les étudiants, les enseignants et les administrateurs du site.

Enregistrer un type de poste personnalisé et une taxonomie associée

Le code suivant enregistre le type de poste projet_étudiant :

function kinsta_project_post_type(){

	// define an array of labels
	$post_type_labels = array(
		'name' 					=> __( 'Projects' ),
		'singular_name'			=> __( 'Project' ),
		'add_new_item'			=> __( 'Add New Project' ),
		'edit_item'				=> __( 'Edit Project' ),
		'new_item'				=> __( 'New Project' ),
		'view_item'				=> __( 'View Project' ),
		'view_items'			=> __( 'View Projects' ),
		'not_found'				=> __( 'No Projects found' ),
		'not_found_in_trash'	=> __( 'No Projects found in Thrash' ),
		'all_items'				=> __( 'All Projects' ),
		'archives'				=> __( 'Project Archives' ),
		'insert_into_item'		=> __( 'Insert into Project' ),
		'uploaded_to_this_item'	=> __( 'Uploaded to this Project' )
		);

	// define an array of arguments
	$post_type_args = array(
		'labels' => $post_type_labels,
		'public' => true,
		'menu_position' => 5,
		'menu_icon' => 'dashicons-media-document',
		'hierarchical' => false,
		'supports' => array( 'title', 'editor', 'author', 'excerpt', 'custom-fields', 'comments' ),
		'taxonomies' => array( 'subject' ),
		'has_archive' => true,
		);

	register_post_type( 'student_project', $post_type_args );

}
add_action( 'init', 'kinsta_project_post_type' );

Pour enregistrer un nouveau type de poste, nous devons appeler la fonction register_post_type, qui doit être appelée par l’action init.
register_post_type conserve deux arguments : la barre de type de poste (‘student_project’), et un tableau d’arguments définissant les paramètres d’admin et de type de poste.
Ci-dessous, nous allons enregistrer une taxonomie non hiérarchique qui identifie le sujet du projet :

function kinsta_project_post_type(){

	$taxonomy_labels = array(
		'name'                       => __( 'Subjects' ),
		'singular_name'              => __( 'Subject' ),
		'search_items'               => __( 'Search Subjects' ),
		'popular_items'              => __( 'Popular Subjects' ),
		'all_items'                  => __( 'All Subjects' ),
		'parent_item'                => null,
		'parent_item_colon'          => null,
		'edit_item'                  => __( 'Edit Subject' ),
		'update_item'                => __( 'Update Subject' ),
		'add_new_item'               => __( 'Add New Subject' ),
		'new_item_name'              => __( 'New Subject Name' ),
		'separate_items_with_commas' => __( 'Separate subjects with commas' ),
		'add_or_remove_items'        => __( 'Add or remove subjects' ),
		'choose_from_most_used'      => __( 'Choose from the most used subjects' ),
		'not_found'                  => __( 'No subjects found.' ),
		'menu_name'                  => __( 'Subjects' ),
		);

	$taxonomy_args = array(
		'hierarchical'          => false,
		'labels'                => $taxonomy_labels,
		'show_ui'               => true,
		'show_admin_column'     => true,
		'update_count_callback' => '_update_post_term_count',
		'query_var'             => true,
		'rewrite'               => array( 'slug' => 'subject' ),
	);

	register_taxonomy( 'subject', 'student_project', $taxonomy_args );
}
add_action( 'init', 'kinsta_project_post_type' );

register_taxonomy conserve trois arguments : la barre de taxonomie (‘subject’), le type de poste lié (‘student_project’), un tableau d’arguments stockant les étiquettes et autres paramètres (voir le Codex pour plus d’informations).

Tout comme register_post_type, register_taxonomy doit être relié à l’action init.
Une fois fait, il est temps de définir l’ensemble des permissions qui permettront des niveaux distincts de contrôle sur le type de poste.

Un ensemble spécifique de permissions pour le type de poste du projet d’étudiant

Afin d’ajouter des permissions spécifiques pour le nouveau type de poste, nous devrions utiliser un ou deux des arguments register_post_type suivants :

capability_type : (string|array) une chaîne de caractères à utiliser comme base pour construire les permissions de lecture, d’édition et de suppression (ex ‘student_project’). Si vous avez besoin de passer des pluriels alternatifs, (c’est-à-dire histoire/histoires), vous devez définir sa valeur dans un tableau (c’est-à-dire array(‘histoire’,’histoires’). capability_type génère les permissions suivantes :

Permissions méta :

  • edit_{capability_type}
  • read_ {capability_type}
  • delete_{capability_type}

Des permissions primitives :

  • edit_{capability_type}s
  • edit_others_{capability_type}s
  • publish_{capability_type}s
  • read_private_{capability_type}s

Capacités primitives définies dans la fonction map_meta_cap :

  • read
  • delete_{capability_type}s
  • delete_private_{capability_type}s
  • delete_published_{capability_type}s
  • delete_others_{capability_type}s
  • edit_private_{capability_type}s
  • edit_published_{capability_type}s

capability_type donne un contrôle général sur les permissions de type de poste. Si vous avez besoin d’un contrôle plus granulaire, vous pouvez utiliser l’argument capabilities.

Capabilities : (array) c’est un tableau de permissions pour le type de poste. Si vous choisissez cet argument au lieu de capability_type, vous pouvez le passer à la fonction register_post_type comme suit :

'capabilities' => array(
	'read_post'			=> 'read_student_project',
	'read_private_posts' 		=> 'read_private_student_projects',
	'edit_post'			=> 'edit_student_project',
	'edit_posts'			=> 'edit_student_projects',
	'edit_others_posts'		=> 'edit_others_student_projects',
	'edit_published_posts'		=> 'edit_published_student_projects',
	'edit_private_posts'		=> 'edit_private_student_projects',
	'delete_post'			=> 'delete_student_project',
	'delete_posts'			=> 'delete_student_projects',
	'delete_others_posts'		=> 'delete_others_student_projects',
	'delete_published_posts'	=> 'delete_published_student_projects',
	'delete_private_posts'		=> 'delete_private_student_projects',
	'publish_posts'			=> 'publish_student_projects',
	'moderate_comments'		=> 'moderate_student_project_comments',
	),

map_meta_cap : (booléen) convertit automatiquement les permissions méta en une ou plusieurs permissions primitives pour le type de poste. Dans notre exemple, il doit être mis à true lorsque vous utilisez l’argument capabilities, mais vous pourriez être amené à mettre sa valeur à false lorsque vous utilisez l’argument capability_type (plus d’informations à ce sujet dans le Codex).

Maintenant nous pouvons revenir à notre fonction register_post_type et définir un nouveau tableau d’arguments comme suit :

$post_type_args = array(
	'labels' => $post_type_labels,
	'public' => true,
	'menu_position' => 5,
	'menu_icon' => 'dashicons-media-document',
	//'capability_type' => 'student_project',
	'capabilities' => array(
		'read_post'					=> 'read_student_project',
		'read_private_posts' 		=> 'read_private_student_projects',
		'edit_post'					=> 'edit_student_project',
		'edit_posts'				=> 'edit_student_projects',
		'edit_others_posts'			=> 'edit_others_student_projects',
		'edit_published_posts'		=> 'edit_published_student_projects',
		'edit_private_posts'		=> 'edit_private_student_projects',
		'delete_post'				=> 'delete_student_project',
		'delete_posts'				=> 'delete_student_projects',
		'delete_others_posts'		=> 'delete_others_student_projects',
		'delete_published_posts'	=> 'delete_published_student_projects',
		'delete_private_posts'		=> 'delete_private_student_projects',
		'publish_posts'				=> 'publish_student_projects',
		'moderate_comments'			=> 'moderate_student_project_comments',
		),
	'map_meta_cap' => true,
	'hierarchical' => false,
	'supports' => array( 'title', 'editor', 'author', 'excerpt', 'custom-fields', 'comments' ),
	'taxonomies' => array( 'subject' ),
	'has_archive' => true,
	);

register_post_type( 'student_project', $post_type_args );

Les permissions sont entièrement documentées dans le fichier /wp-includes/post.php et dans la référence de la fonction register_post_type.

Ajouter des permissions aux enseignants et aux élèves

Maintenant que nous avons enregistré deux rôles et un type de poste avec des permissions spécifiques, notre tâche est d’attribuer des permissions aux rôles :

function kinsta_add_caps(){
	$admin = get_role( 'administrator' );
	$admin->add_cap( 'read_student_project' );
	$admin->add_cap( 'read_private_student_project' );
	$admin->add_cap( 'edit_student_project' );
	$admin->add_cap( 'edit_student_projects' );
	$admin->add_cap( 'edit_others_student_projects' );
	$admin->add_cap( 'edit_published_student_projects' );
	$admin->add_cap( 'edit_private_student_projects' );
	$admin->add_cap( 'delete_student_projects' );
	$admin->add_cap( 'delete_student_project' );
	$admin->add_cap( 'delete_others_student_projects' );
	$admin->add_cap( 'delete_published_student_project' );
	$admin->add_cap( 'delete_student_project' );
	$admin->add_cap( 'delete_private_student_project' );
	$admin->add_cap( 'publish_student_projects' );
	$admin->add_cap( 'moderate_student_project_comments' );

	$student = get_role( 'student' );
	$student->add_cap( 'read_student_project' );
	$student->add_cap( 'edit_student_project' );
	$student->add_cap( 'edit_student_projects' );
	$student->add_cap( 'delete_student_project' );
	$student->add_cap( 'delete_student_projects' );

	$teacher = get_role( 'teacher' );
	$teacher->add_cap( 'read_student_project' );
	$teacher->add_cap( 'read_private_student_project' );
	$teacher->add_cap( 'edit_student_project' );
	$teacher->add_cap( 'edit_student_projects' );
	$teacher->add_cap( 'edit_others_student_projects' );
	$teacher->add_cap( 'edit_published_student_projects' );
	$teacher->add_cap( 'edit_private_student_projects' );
	$teacher->add_cap( 'delete_student_project' );
	$teacher->add_cap( 'delete_student_projects' );
	$teacher->add_cap( 'delete_others_student_projects' );
	$teacher->add_cap( 'delete_published_student_projects' );
	$teacher->add_cap( 'delete_private_student_project' );
	$teacher->add_cap( 'publish_student_projects' );
	$teacher->add_cap( 'moderate_student_project_comments' );
}
add_action( 'admin_init', 'kinsta_add_caps');

Ce code est assez explicite : la fonction callback est connectée à l’action admin_init, qui se déclenche avant tout autre hook lorsque le panneau d’administration est chargé. La méthode add_cap de l’objet WP_Role affecte la capacité spécifiée à un rôle.

L'écran Projets pour un élève

L’écran Projets pour un élève

Nettoyage de la base de données sur la désactivation des plugins

Enfin, nous pouvons supprimer les rôles de l’étudiant et de l’enseignant, et supprimer les permissions de type de poste personnalisé du rôle administrateur lors de la désactivation du plugin :

function kinsta_remove_roles(){
	//check if role exist before removing it
	if( get_role('student') ){
		remove_role( 'student' );
	}
	if( get_role('teacher') ){
		remove_role( 'teacher' );
	}

	$admin = get_role( 'administrator' );

	$caps = array(
		'read_student_project',
		'read_private_student_project',
		'edit_student_project',
		'edit_student_projects',
		'edit_others_student_projects',
		'edit_published_student_projects',
		'edit_private_student_projects',
		'delete_student_projects',
		'delete_student_project',
		'delete_others_student_projects',
		'delete_published_student_project',
		'delete_student_project',
		'delete_private_student_project',
		'publish_student_projects',
		'moderate_student_project_comments'
	);

	foreach ( $caps as $cap ) {
		$admin->remove_cap( $cap );
	}	
}
register_deactivation_hook( __FILE__, 'kinsta_remove_roles' );

Le projet est maintenant terminé, et vous pouvez récupérer le code complet de ces exemples à partir de ce Gist public

L'écran Projets pour un enseignant

L’écran Projets pour un enseignant

Contrôlez les rôles et les permissions des utilisateurs de WordPress avec les plugins

Si vous n’êtes pas développeur, vous pouvez quand même prendre le contrôle des rôles et des permissions, grâce à un certain nombre de plugins gratuits disponibles dans le répertoire des plugins.

Members de Justin Tadlock est un éditeur de rôles et de permissions facile à utiliser et complet. Il permet à l’administrateur du site d’ajouter, de modifier et de supprimer des rôles et des permissions, d’assigner aux utilisateurs plus d’une capacité, de refuser des majuscules spécifiques à des rôles spécifiques, de contrôler quels rôles peuvent accéder au contenu des articles, de fournir des shortcodes et des widgets, et plus.

Members - Ajouter un nouveau rôle

Members – Ajouter un nouveau rôle

User Role Editor de Vladimir Garagulya est un autre plugin qui permet un contrôle total des rôles et des permissions. De plus, il permet aux administrateurs du site d’attribuer des rôles à des utilisateurs individuels et garantit la compatibilité du Multisite. Ce plugin est également disponible en version commerciale avec des fonctionnalités supplémentaires.

WPFront User Role Editor est une autre option pour gérer les rôles et les permissions dans WordPress. Il est disponible en version gratuite dans le répertoire de plugins WordPress, et en version commerciale avec des fonctionnalités plus avancées.

Bien qu’il ne s’agisse pas d’un éditeur de rôles, User Switching est un plugin indispensable pour la gestion des rôles et des permissions. Son seul but est de permettre à l’administrateur du site de passer d’un compte utilisateur à l’autre en un seul clic, de sorte qu’il n’ait pas besoin de se déconnecter et de se connecter à plusieurs reprises pour vérifier ce que les utilisateurs peuvent voir sur le site.

Conclusions

A première vue, les concepts de rôles et de permissions des utilisateurs de WordPress peuvent être un peu confus, surtout en ce qui concerne les permissions méta et les permissions primitives. Quoi qu’il en soit, une fois que vous avez compris le concept clé derrière le système de gestion des utilisateurs WordPress, vous pouvez facilement obtenir un contrôle précis des activités des utilisateurs.
Avez-vous déjà eu l’occasion de créer des sites Web centrés sur l’utilisateur ? Partagez vos expériences avec nous dans les commentaires.

17
Partages