Кратко: Роли пользователей в WordPress — это именованные наборы прав (capabilities), которые определяют, что человек может делать в админке: писать записи, устанавливать плагины, менять темы. По умолчанию в системе пять ролей — Администратор, Редактор, Автор, Участник и Подписчик (WooCommerce добавляет ещё две). Права проверяются функцией current_user_can(), новая роль создаётся через add_role(), а add_cap() и remove_cap() точечно выдают или забирают возможности. Ниже — полный разбор: таблица ролей, готовые сниппеты для functions.php, обзоры плагинов и частые ошибки новичков.
Когда вы отдаёте доступ к сайту копирайтеру, менеджеру или подрядчику, возникает вопрос: а что он сможет сделать внутри админки? Один щелчок при выборе роли — и человек либо получит возможность удалить половину сайта, либо не сможет даже загрузить картинку. Разбираемся, как устроена система ролей и прав в WordPress, как посмотреть текущие настройки и как создать собственную роль с точным набором возможностей — кодом или плагином.
Материал рассчитан на новичков: каждый шаг объясняется простыми словами, а весь код можно вставить в functions.php дочерней темы без правок ядра. Если вы только настраиваете защиту сайта, начните со статьи про безопасность WordPress для новичков, а потом вернитесь сюда — правильные роли это вторая линия обороны после бэкапов и обновлений.
Как устроена система ролей в WordPress
В WordPress нет размытых «уровней доступа» вроде «модератор чуть повыше автора». Всё построено на двух понятных сущностях: роль (role) — это контейнер с названием, а возможность (capability) — конкретное разрешение, например «публиковать записи» или «управлять плагинами». Роль — просто набор таких разрешений, записанный в базу данных (таблица опций wp_options, ключ wp_user_roles).
У каждого пользователя указана роль (обычно одна, хотя технически можно присвоить несколько). Когда человек заходит в админку, WordPress смотрит на список возможностей его роли и на основании этого рисует меню: у кого-то есть пункт «Плагины», у кого-то — только «Записи». Если роль не даёт возможность manage_options, пункт «Настройки» в меню просто не появится — и прямым заходом по ссылке тоже не получится ничего изменить, потому что сервер снова проверит права.
Важно понять: иерархия «админ выше редактора» — это условность для человека. Для WordPress роли не связаны автоматически: каждая роль имеет собственный явный список capabilities. То есть, создавая свою роль, вы не «наследуете» права редактора, а честно перечисляете каждое разрешение. Это чуть больше работы, зато полный контроль — вы никогда случайно не дадите лишнего.
Пять стандартных ролей: кто что может
После установки WordPress создаёт пять ролей. Если стоит WooCommerce, добавляются ещё две — «Менеджер магазина» и «Клиент». Вот полная таблица с расшифровкой:
| Роль | Что может | Кому подходит |
|---|---|---|
| Администратор (Administrator) | Всё: плагины, темы, пользователи, настройки, импорт-экспорт, правка кода через редактор | Владелец сайта и максимум один-два доверенных человека |
| Редактор (Editor) | Все записи и страницы — свои и чужие: создание, правка, публикация, удаление; модерация комментариев; работа с медиафайлами | Контент-менеджер, главный редактор блога |
| Автор (Author) | Свои записи: написать, опубликовать, отредактировать; загрузка изображений | Штатный автор блога, копирайтер |
| Участник (Contributor) | Пишет черновики и отправляет на проверку, но публиковать не может и файлы загружать не может | Гостевые авторы, стажёры |
| Подписчик (Subscriber) | Только свой профиль и комментирование | Читатели, участники закрытого раздела, клиенты с личным кабинетом |
| Менеджер магазина (Shop Manager, WooCommerce) | Товары, заказы, купоны, отчёты магазина; правка записей | Администратор интернет-магазина на WooCommerce |
| Клиент (Customer, WooCommerce) | Личный кабинет, история заказов, повторные покупки | Покупатели интернет-магазина |
Где это смотреть в админке: раздел «Пользователи → Все пользователи» — в списке есть колонка «Роль», а над таблицей выпадающий список «Изменить роль на…». Выделите пользователя, выберите роль, нажмите «Применить» — и права обновятся мгновенно, без кода.
Возможности (capabilities): главный ключ к правам
Возможность — это короткая строка-разрешение, которую WordPress проверяет в коде. Стандартных возможностей несколько десятков, и у каждой роли свой их набор. Самые важные для повседневной работы:
| Возможность | Что разрешает | У кого есть по умолчанию |
|---|---|---|
| manage_options | Экран «Настройки» и изменение конфигурации сайта | Администратор |
| edit_posts | Создание записей (черновиков) | Участник и выше |
| publish_posts | Самостоятельная публикация записей | Автор и выше |
| edit_others_posts | Редактирование чужих записей | Редактор и выше |
| edit_pages | Работа со страницами | Редактор и выше |
| moderate_comments | Модерация комментариев | Редактор и выше |
| upload_files | Загрузка изображений и файлов в медиатеку | Автор и выше |
| edit_theme_options | Кастомайзер, меню, виджеты | Администратор |
| manage_plugins | Установка, включение и удаление плагинов | Администратор |
| edit_users | Управление учётными записями пользователей | Администратор |
Проверка в коде всегда идёт через функцию current_user_can() — ей передают название возможности, а она возвращает true или false для текущего пользователя:
<?php
if ( current_user_can( 'publish_posts' ) ) {
echo 'Вы можете публиковать записи.';
} else {
echo 'Ваша роль не позволяет публиковать записи.';
}
?>Обратите внимание: проверять нужно именно возможность, а не роль. Сравнение вида «пользователь — администратор?» хрупко: как только на сайте появится кастомная роль с правами админа (или владелец переименует роль), логика сломается. А current_user_can( 'manage_options' ) работает в любом случае — она спрашивает про суть разрешения, а не про название контейнера.
Как управлять ролями без кода: плагины
Если разовая настройка или вы пока не хотите трогать код — хватит плагина. Два самых удобных решения:
| Плагин | Что умеет | Когда выбрать |
|---|---|---|
| User Role Editor | Галочками добавляет и убирает любые возможности у любой роли; может создать новую роль с нуля | Нужно точечно докрутить права — например, разрешить редактору менять меню |
| Members | Роли и возможности плюс ограничение доступа к контенту по ролям | Нужны не только права, но и закрытые разделы сайта |
Порядок действий в User Role Editor: установите плагин, откройте «Пользователи → User Role Editor», выберите роль слева, поставьте галочки напротив нужных возможностей и сохраните. Изменения записываются в базу сразу — сниппеты не нужны. Единственный нюанс: плагин не откатывает изменения при удалении, поэтому фиксируйте, что и кому выдали, в отдельной заметке.
Создаём свою роль через код: add_role()
Код даёт воспроизводимость: роль описана сниппетом, и при переносе сайта на новый хостинг она создаётся заново сама. Классическая задача — роль «Контент-менеджер»: может всё по контенту, включая чужие записи, но не видит плагины, темы и настройки.
<?php
add_action( 'init', 'ds_add_content_manager_role' );
function ds_add_content_manager_role() {
if ( get_role( 'content_manager' ) ) {
return; // роль уже существует, не дублируем
}
add_role(
'content_manager',
'Контент-менеджер',
array(
'read' => true,
'upload_files' => true,
'edit_posts' => true,
'edit_others_posts' => true,
'delete_posts' => true,
'publish_posts' => true,
'edit_pages' => true,
'moderate_comments' => true,
)
);
}
?>Как это работает: хук init запускает функцию при каждой загрузке WordPress. Функция сначала проверяет через get_role(), существует ли уже такая роль (роль хранится в базе, поэтому достаточно создать её один раз), и если да — выходит. Если нет — add_role() создаёт контейнер с техническим именем content_manager (только латиница и подчёркивания), человекочитаемым названием «Контент-менеджер» и массивом возможностей. После создания роль сразу появится в выпадающем списке «Роль» в карточке пользователя — можно назначать её прямо из админки, без кода.
Назначить роль пользователю можно в админке или кодом:
<?php
$user = new WP_User( 12 ); // 12 — ID пользователя
$user->set_role( 'content_manager' );
?>Куда вставлять код: в functions.php дочерней темы или в mu-plugin. Не вставляйте такой сниппет во «временные» места вроде плагина-заглушки, который потом удалите, — сама роль при этом не исчезнет (она в базе), а вот документация по проекту перепутается.
Выдаём и забираем отдельные возможности: add_cap() и remove_cap()
Часто создавать новую роль не нужно — достаточно чуть подправить существующую. Например, разрешить редактору управлять меню и виджетами, а у автора забрать возможность удалять свои опубликованные записи:
<?php
add_action( 'init', 'ds_tune_role_caps' );
function ds_tune_role_caps() {
$editor = get_role( 'editor' );
if ( $editor && ! $editor->has_cap( 'edit_theme_options' ) ) {
$editor->add_cap( 'edit_theme_options' );
}
$author = get_role( 'author' );
if ( $author && $author->has_cap( 'delete_published_posts' ) ) {
$author->remove_cap( 'delete_published_posts' );
}
}
?>Здесь та же логика, что и с ролями: изменения сохраняются в базу данных и остаются там после удаления сниппета. Поэтому проверки has_cap() нужны, чтобы не гонять лишние записи в базу при каждой загрузке страницы — защита уже стоит, дублировать нечего.
Два практических следствия. Первое: перед экспериментами с правами сделайте резервную копию — восстановить случайно отнятые у админа возможности вручную неприятнее, чем развернуть бэкап. Второе: если хотите вернуть роль к заводскому состоянию, проще всего удалить её через remove_role() и пересоздать стандартный набор — у User Role Editor есть кнопка сброса к значениям по умолчанию.
Проверка прав в своём коде: меню, AJAX, front-end
Когда вы пишете свой функционал, права проверяются в трёх типичных местах. Первое — регистрация пунктов меню в админке: параметр capability в add_menu_page() автоматически скрывает пункт у тех, кому нельзя:
<?php
add_action( 'admin_menu', 'ds_register_reports_menu' );
function ds_register_reports_menu() {
add_menu_page(
'Отчёты магазина',
'Отчёты',
'manage_options', // увидят только администраторы
'ds-reports',
'ds_render_reports_page',
'dashicons-chart-bar',
3
);
}
?>Второе — AJAX-обработчики: сам по себе admin-ajax.php не проверяет права, это делает ваш код. Всегда начинайте обработчик с проверки current_user_can():
<?php
add_action( 'wp_ajax_ds_like_post', 'ds_like_post_handler' );
function ds_like_post_handler() {
if ( ! current_user_can( 'read' ) ) {
wp_send_json_error( array( 'message' => 'Недостаточно прав' ), 403 );
}
$post_id = absint( $_POST['post_id'] ?? 0 );
wp_send_json_success( array( 'post_id' => $post_id ) );
}
?>Третье — интерфейс на фронтенде: кнопку «Редактировать» показываем только тем, кто реально может редактировать. Со стороны браузера запрос к обработчику выглядит так:
fetch('/wp-admin/admin-ajax.php', {
method: 'POST',
credentials: 'same-origin',
body: new URLSearchParams({ action: 'ds_like_post', post_id: '12' })
})
.then(response => response.json())
.then(data => console.log(data));Скрытие кнопки на фронтенде — только косметика: нельзя рассчитывать, что «кто не видит кнопку, тот и не нажмёт». Проверка на сервере в обработчике обязательна всегда, потому что запрос можно подделать. Если интегрируете сайт с внешними сервисами, посмотрите разбор REST API WordPress — там доступ к данным тоже ограничивается проверками прав, а за основу асинхронных запросов на стороне сервера часто берут тот же admin-ajax.php.
Частые ошибки новичков при работе с ролями
Разбор типовых граблей сэкономит вам несколько вечеров:
- Дать всем администратора «чтобы не возиться». Админ может удалить плагины, сменить тему, отредактировать файлы и пользователей. Один скомпрометированный аккаунт — и сайт потерян. Для контента есть редактор, для магазина — shop_manager.
- Проверять роль вместо возможности. Конструкция «если роль = administrator» ломается при кастомных ролях и переносе сайта. Всегда
current_user_can()с конкретной возможностью. - Забывать, что роли живут в базе. Удалили сниппет с
add_role(), а роль никуда не делась. Созданные роли и выданные capabilities — это данные, а не код, и «чинить» их нужно тоже данными или плагином. - Вызывать add_role() без проверки на существование. WordPress молча пропустит повторное создание, и вы никогда не узнаете, что старая версия роли с устаревшим набором прав всё ещё работает. Всегда проверяйте
get_role()перед созданием. - Ограничиваться проверкой прав без валидации данных. Право «read» ещё не значит, что в
$_POSTпришло безопасное число. Приводите входные данные черезabsint()и проверяйте nonce — иначе дыра останется даже при идеальных ролях. - Править роли напрямую в базе без бэкапа. Опция wp_user_roles сериализована; одна опечатка в phpMyAdmin — и все пользователи могут потерять доступ. Сначала копия, потом эксперименты.
Частые вопросы о ролях и правах в WordPress
Где в админке посмотреть и изменить роль пользователя?
Раздел «Пользователи → Все пользователи»: в таблице есть колонка «Роль». Чтобы изменить, наведите курсор на пользователя и нажмите «Изменить», либо выделите галочками нескольких людей, выберите роль в выпадающем списке над таблицей и нажмите «Применить» — массовая смена ролей занимает секунды.
Можно ли переименовать или удалить стандартную роль?
Технически да: функции remove_role() и фильтры переводов позволяют и удалять, и переименовывать. Но делать это не стоит: плагины и темы рассчитывают на стандартные роли, а после обновлений могут появиться конфликты. Если название «Автор» не нравится — создайте свою роль, а стандартную просто не назначайте никому.
Сколько администраторов должно быть на сайте?
Минимум: один-два. Владелец и, при необходимости, технический подрядчик. Каждый дополнительный администратор — это доступ к плагинам, темам, базе и пользователям сразу. Для всех остальных задач существует роль по месту: редактор для контента, менеджер магазина для WooCommerce, подписчик для читателей.
Что произойдёт с ролями, если удалить плагин Members или User Role Editor?
Ничего: роли и возможности хранятся в базе данных WordPress, а не в файлах плагина. Созданные роли останутся работать, но исчезнет удобный интерфейс управления. Иногда после удаления остаются ненужные «мусорные» роли — их можно убрать функцией remove_role() или снова установить плагин на время чистки.
Как дать подрядчику доступ, не отдавая аккаунт администратора?
Создайте отдельную учётную запись с ролью по задаче: «Редактор» для контента, «Менеджер магазина» для товаров и заказов. Если подрядчику нужны точечные дополнительные права — добавьте их конкретной возможности через User Role Editor. Никогда не передавайте свой личный админский аккаунт: для разовой технической работы проще временно повысить его отдельную учётку, а после приёмки вернуть роль обратно.
Чем управление ролями отличается в WooCommerce?
WooCommerce добавляет две роли: «Клиент» (customer) — для покупателей с личным кабинетом и историей заказов, и «Менеджер магазина» (shop_manager) — для администраторов магазина. Менеджер работает с товарами, заказами, купонами и отчётами, но не может менять темы и плагины, поэтому передача магазина сотруднику на эту роль безопаснее, чем выдача полных прав администратора.
Вывод: настройте роли один раз — и забудьте о страхе за сайт
Система ролей — один из тех механизмов WordPress, которые выглядят сложно только до первого практического разбора. На деле всё сводится к трём вопросам: какие возможности существуют, у какой роли они есть и как проверить право в коде. Минимальный план для новичка:
- Аудит: откройте «Пользователи → Все пользователи» и проверьте, нет ли лишних администраторов;
- Минимальные права: каждому работающему с сайтом — роль по задаче, а не админку «чтобы проще»;
- Автоматизация: либо галочки в User Role Editor, либо сниппеты add_role/add_cap в дочерней теме;
- Контроль: весь свой код начинайте с current_user_can(), а входные данные проверяйте отдельно.
Настройка ролей отлично дополняет базовые меры из гайда по безопасности WordPress, а понимание хуков из статьи про actions и filters поможет строить на проверках прав собственную логику. Если работаете с мультисайтовой сетью WordPress, учитывайте: там роли действуют в пределах каждого сайта сети отдельно. Больше практических материалов о разработке — в блоге delai-sait.ru, а если нужен сайт под ключ с продуманной структурой доступа для команды — посмотрите услуги разработки и напишите нам через форму контактов или загляните в портфолио.
