Подробный обзор ролей и прав пользователей WordPress

Каждый раз, когда на сайте регистрируется новый профиль, WordPress добавляет данные в таблицы wp_users и wp_usermeta. Новый пользователь получает роль, которая определяет доступные действия в панели администрирования. Но какие именно роли существуют в WordPress?

Содержание

Роли и права пользователей WordPress

Система управления пользователями WordPress основана на двух ключевых понятиях: роли и права.

  • Роль идентифицирует группу пользователей, которым разрешено выполнять те или иные задачи на сайте.
  • Права – это разрешение на выполнение отдельной задачи, доступной для конкретной роли.

По умолчанию в WordPress доступно шесть ролей:

  • Супер-администратор— пользователь, имеющий полный доступ к функциям администрирования мультисайтовой установки WordPress. Он может создавать и управлять дочерними сайтами, пользователями, устанавливать и удалять темы и плагины.
  • Администратор— это пользователь, имеющий полный доступ ко всем функциям управления обычной версией WordPress.
  • Редактор— может редактировать и публиковать контент, созданный любым пользователем.
  • Автор — может публиковать и редактировать собственный контент.
  • Участник — может создавать и редактировать, но не публиковать свой собственный контент.
  • Подписчик — имеет доступ только к своему профилю.

Права ролей пользователей WordPress упорядочены по иерархии. Рассмотрим следующую таблицу:

Подписчик Участник Редактор
Read read read
edit_posts edit_posts
delete_posts delete_posts
delete_published_posts
publish_posts
upload_files
edit_published_posts

Участник имеет те же права read, что и подписчик. Но участник еще может создавать, редактировать и удалять свои собственные неопубликованные записи.

Редактор обладает теми же правами, что и участник. Кроме этого, он может публиковать, редактировать и удалять записи, загружать мультимедийные файлы.

Существует два типа прав:

  • Мета-права – возможности пользователя на текущей странице.
  • Примитивные права – основные права пользователя (в рамках движка).

Пользователь может редактировать запись, если он является автором этой записи (мета-право ‘edit_post’) . Разрешение на редактирование записей, созданные другими пользователями (примитивные права ‘edit_others_posts’).

Полный список встроенных прав всех ролей доступен в Кодексе.

WordPress позволяет создавать новые права и роли. Например, вы можете разрешить подписчикам создавать и редактировать записи. Но от системы управления пользователями можно получить гораздо больше:

  • Показать / скрыть элементы интерфейса (пункты меню, сообщения или виджеты) в зависимости от роли пользователя.
  • Настроить содержимое записей в зависимости от роли пользователей.
  • Ограничить доступ к определенным разделам сайта для определенных пользователей или ролей.
  • Создавать собственные типы записей с индивидуальными правами, которые могут по-разному обрабатываться для каждой роли.

Последний пункт определят цель этой статьи.

Учащиеся, учителя и домашние задания

Допустим, вы создаете образовательный сайт, на котором учащимся и учителям разрешается взаимодействовать друг с другом. Ученики должны создавать проекты и представлять их на рассмотрение. Учителя могут редактировать проекты и публиковать их в случае одобрения.
Ученики могут комментировать любой проект, но только учителя могут модерировать комментарии.

Что нам нужно реализовать:

  • Добавить роли учащегося и учителя.
  • Зарегистрировать тип записи student_project и пользовательскую таксономию
  • Зарегистрировать и отобразить конкретные права для типа записи
  • Назначить права для ролей администраторовучащихся и учителей

Для этого мы создадим плагин, который регистрирует пользовательский тип записи и таксономию, а также роли и права. Полный код плагина доступен в Gist.

/wp-content/uploads/-000//1/44796-5cce84fb42319.png

Регистрация ролей и прав пользователей WordPress

Ученикам разрешено читать все проекты, создавать, редактировать и удалять свои собственные проекты. Они не могут публиковать проекты, а также редактировать и удалять размещенные посты.

Учителя должны контролировать каждый аспект администрирования проекта. Им разрешено создавать новые проекты, редактировать, удалять и публиковать проекты, созданные любым пользователем.

Назначение роли учащегося новому пользователю в панели «Добавить пользователя»

Сначала зарегистрируем роли учащегося и учителя:

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  — регистрирует функцию, которая запускается при активации плагина. Здесь предпочтительнее использовать хук действий, такой как init. Потому что новые роли регистрируются в базе данных, и нам не нужно запускать функцию каждый раз, когда загружается WordPress. register_activation_hook содержит два аргумента: путь к главному файлу плагина ( __FILE__ ) и функцию обратного вызова, которую нужно запустить (‘kinsta_add_roles’).
  • При активации плагина выполняется register_activation_hook, а add_role регистрирует новую роль в таблице wp_options,если она еще не существует. Данная функция принимает три аргумента: имя роли, отображаемое имя и массив прав.

Функция обратного вызова добавляет две роли. Каждая роль имеет свой набор прав.

Меню «Роль» в административной панели пользователя.

Теперь мы можем создать сообщество учащихся и учителей. Но набор их прав не сильно отличаются от авторов и редакторов. Зарегистрируем пользовательский тип записи для учащихся, учителей и администраторов сайта.

Регистрация пользовательского типа записи и связанной с ним таксономии

Следующий код регистрирует тип записи student_project:

function kinsta_project_post_type(){

	// определяем массив меток
	$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' )
		);

	// определяем массив аргументов
	$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' );

Чтобы зарегистрировать новый тип записи, нужно вызвать функцию register_post_type в хуке init.

register_post_type принимает два аргумента: слаг записи пользовательского типа (‘student_project’ ) и массив аргументов, устанавливающих метки администрирования и параметры записи.
Далее мы зарегистрируем неиерархическую таксономию, которая идентифицирует проект:

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 принимает три аргумента: слаг таксономии (‘subject’), связанный тип записи (‘student_project’), массив аргументов, хранящих метки и другие параметры (дополнительную информацию смотрите в Кодексе).
При этом register_taxonomy должна быть подключена к действию init.

Набор прав для типа записи проекта учащегося

Чтобы добавить права для нового типа записи, нужно использовать один или два из следующих аргументов register_post_type:

capability_type: ( string | array ) — строка, которая будет использоваться в качестве основы для создания прав чтения, редактирования и удаления (т. е. ‘student_project’). Генерирует следующие права:

Мета-права:

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

Примитивные права:

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

Примитивные права, определенные в функции 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 предоставляет общий контроль над правами типа записи. Если нужен более гибкий контроль, вы можете использовать аргумент capabilities.

capabilities: (массив) — массив прав для этого типа записи. Если вы выберете этот аргумент вместо capability_type, то сможете передать его функции register_post_type следующим образом:

'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, когда используем аргумент capabilities.

Теперь мы можем вернуться к функции register_post_type и определить новый массив аргументов:

$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 );

Права описаны в файле /wp-includes/post.php и в справочнике по функции register_post_type.

Добавление прав для учителей и учащихся

Теперь осталось назначить права ролям пользователей:

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');

Функция обратного вызова подключается к действию admin_init, которое запускается перед любым другим хуком при загрузке панели администрирования. Метод объекта WP_Role add_cap  назначает указанные права для роли.

Панель проектов для учащегося

Очистка базы данных при деактивации плагина

Также мы можем удалить роль учащегося, учителя и права для пользовательского типа записи роли администратора при деактивации плагина:

function kinsta_remove_roles(){
	//проверяем, существует ли роль, перед тем как ее удалить
	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' );

Плагин завершен. Полный код примера доступен здесь.

Панель проектов для учителя

Управление ролями и правами пользователей WordPress с помощью плагинов

Также ролями и их правами можно управлять с помощью следующих плагинов:

Members — простой в использовании редактор ролей и прав. Он позволяет администратору сайта добавлять, редактировать и удалять роли и права,  запрещать определенные действия. А также контролировать, какие роли могут получать доступ к содержимому публикации. Предоставляет шорткоды, виджеты и многое другое.

Страница добавления новой роли с помощью плагина Members

User Role Editor — плагин позволяет администратору назначать роли отдельным пользователям и роли для мультисайтовой установки.

WPFront User Role Editor — еще один плагин для управления ролями и правами пользователей в WordPress.

User Switching — позволяет администратору сайта переключаться между учетными записями пользователей одним кликом мыши.

Заключение

На первый взгляд система ролей и прав пользователей WordPress может показаться немного запутанной. Но как только вы поймете ее ключевую концепцию, то с легкостью сможете получить контроль над действиями пользователей.

Данная публикация представляет собой перевод статьи «A Deep Dive Into WordPress User Roles and Capabilities» , подготовленной дружной командой проекта Интернет-технологии.ру