Возможность WordPress

Роль «Редактор» сама по себе ничего не разрешает: это лишь название для набора возможностей. Когда пользователь нажимает «Опубликовать», WordPress проверяет не роль, а наличие права publish_posts. Такая схема позволяет тонко настраивать доступ: дать менеджеру магазина управление заказами, но не настройками сайта, или запретить автору загружать файлы. Список ролей с их возможностями хранится в базе, в опции wp_user_roles.

Простые и мета-возможности

Возможности бывают двух видов. Простые — edit_posts, upload_files, manage_options — прямо записаны в роли. Мета-возможности вроде edit_post или delete_user относятся к конкретному объекту и в ролях не хранятся. Функция map_meta_cap() превращает их в простые: правка своей черновой записи требует edit_posts, чужой — edit_others_posts, уже опубликованной — edit_published_posts.

Пример проверки и выдачи права

// проверка в своём коде: может ли пользователь править эту запись
if ( current_user_can( 'edit_post', $post_id ) ) {
    // показываем кнопку «Редактировать»
}

// выдать редакторам доступ к меню и виджетам — один раз, при активации плагина
register_activation_hook( __FILE__, function () {
    get_role( 'editor' )->add_cap( 'edit_theme_options' );
} );

Метод add_cap() записывает изменение в базу. Вызывать его на каждой загрузке страницы бессмысленно — это лишняя запись в базу при каждом запросе.

Типичные ошибки

• Проверка роли вместо права: current_user_can( 'administrator' ) работает, но ломается, как только роли переименуют или появится своя роль с теми же правами.
• Проверка только права без проверки nonce в обработчиках форм и AJAX: злоумышленник может заставить администратора выполнить действие по подделанной ссылке.
• Права, выданные плагином управления ролями, остаются в базе и после удаления плагина.

Как из возможностей собираются стандартные роли, рассказано в статье о ролях пользователей WordPress. В мультисайте суперадминистратор проходит почти любую проверку прав автоматически.