Права редактора в WordPress: выдать нужное и не отдать сайт

У редактора журнала три условия: он правит меню рубрик, не удаляет чужие материалы и не вставляет в записи произвольный HTML и скрипты. Роль Editor из коробки не умеет первого и умеет остальное: меню ей недоступны, а удалять чужие записи и вставлять сырой HTML она может. Привычный выход, выдать Administrator, закрывает первую задачу и открывает новую: человек получает установку плагинов и настройки сайта. Ниже разбор на примере сайта-журнала с WordPress 6.x.

Что у Editor есть из коробки

Права в WordPress хранятся как набор флагов у роли, они называются capabilities¹. На обычном сайте (не multisite) Editor правит, публикует и удаляет свои и чужие записи и страницы, модерирует комментарии, управляет рубриками и метками, загружает файлы. У него есть и unfiltered_html: HTML в записях не чистится.

Чего у него нет: edit_theme_options (меню, виджеты, Customizer), manage_options (раздел «Настройки»), install_plugins, edit_users и list_users. Актуальный список для вашей версии покажет команда wp cap list editor.

Задача на живом примере

Сайт-журнал, три редактора отделов. Что нужно получить:

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

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

Четыре способа и их цена

Способ 1: правим роль Editor

Подходит, если редактор на сайте один или всем нужен одинаковый набор. Через WP-CLI:

wp cap add editor edit_theme_options
wp cap remove editor delete_others_posts delete_published_posts unfiltered_html

Изменение записывается в базу и переживёт любое отключение плагинов и смену темы. Это удобно и неприятно одновременно: следов в коде нет, и через год никто не вспомнит, откуда у редакторов такие права.

Способ 2: отдельная роль

Для нашего журнала берём этот вариант. Роль клонируется из Editor, затем правится. Если есть доступ по SSH:

wp role create desk_editor 'Редактор отдела' --clone=editor
wp cap add desk_editor edit_theme_options
wp cap remove desk_editor delete_others_posts delete_published_posts unfiltered_html
wp user set-role 42 desk_editor

Здесь 42 — ID пользователя, его покажет wp user list --role=editor. Без SSH то же делает небольшой плагин (WordPress 6.x, PHP 7.4 и новее):

<?php
/**
 * Plugin Name: Роль «Редактор отдела»
 * Description: Роль на основе Editor с изменённым набором прав.
 * Version: 1.0.0
 */

// Выполняется один раз при активации, а не на каждый запрос.
function jrn_create_desk_editor_role() {
	$editor = get_role( 'editor' );
	if ( null === $editor ) {
		return;
	}

	// Берём все права Editor за основу.
	$caps = $editor->capabilities;

	// Нужно: меню, виджеты, Customizer.
	$caps['edit_theme_options'] = true;

	// Убираем удаление чужого и опубликованного, а также сырой HTML.
	unset(
		$caps['delete_others_posts'],
		$caps['delete_published_posts'],
		$caps['unfiltered_html']
	);

	// add_role() не трогает уже существующую роль, поэтому сначала удаляем.
	remove_role( 'desk_editor' );
	add_role( 'desk_editor', 'Редактор отдела', $caps );
}
register_activation_hook( __FILE__, 'jrn_create_desk_editor_role' );

Пользователи, которым вы назначили эту роль, сохраняют её при пересоздании: она записана в их данных, а не в самой роли.

Способы 3 и 4 одной строкой

Плагин с галочками стоит ставить, когда права будет менять выпускающий, а не разработчик. Права на одного пользователя (wp user add-cap) годятся на неделю, но не как постоянная схема.

Когда что выбирать

• Все редакторы получают одинаковые права и других наборов не планируется: способ 1.
• Нужно хотя бы два набора прав или возможность откатиться, не трогая стандартную роль: способ 2.
• Права будет менять человек без доступа к коду и серверу: способ 3, и доступ к самому плагину оставьте только администраторам.
• Выдаёте на время, например заместителю на отпуск: способ 4, и сразу поставьте себе напоминание снять права.

Что ломается

• Страницы остались без внимания. Мы убрали удаление чужих записей, но delete_others_pages и delete_published_pages по-прежнему у редактора. Если страницы тоже критичны, уберите и их.
• Роль не обновилась. add_role() ничего не делает, если роль с таким ключом уже есть, поэтому в коде выше стоит remove_role().
• Customizer открыл больше, чем ожидали. edit_theme_options даёт доступ к меню и виджетам, а в классических темах заодно и к «Дополнительному CSS». Что именно появилось в разделе «Внешний вид», проверьте под тестовым пользователем на своей версии.
• Без unfiltered_html часть чужого кода встраиваний (iframe, скрипты виджетов) в записях будет вырезаться. Стандартные oEmbed-вставки продолжат работать, остальное придётся вставлять администратору.
• Ручная смена префикса таблиц. Роли лежат в опции {префикс}user_roles, а права пользователя в его метаданных. Если префикс меняли руками и ключи внутри не поправили, роли «пропадают».
• Плагины добавили права после клонирования. Новые права, которые плагин выдал роли Editor позже, в вашу копию не попадут.

Мультисайт, права для WooCommerce и кастомные типы записей — отдельные темы, здесь их не разбираем.

Что делать дальше

1. Перед экспериментами сделайте дамп базы: все роли лежат в одной опции, и ошибка затронет весь сайт.
2. Зайдите под тестовым пользователем с новой ролью и пройдите весь рабочий путь: создать запись, поправить меню, попытаться удалить чужое.
3. Проверьте право напрямую: wp eval 'var_dump( user_can( 42, "edit_theme_options" ) );'.
4. Раз в квартал выводите wp user list --role=administrator и сверяйте список с реальными людьми.

¹ Capability — именованное право на одно действие, например publish_posts. Роль — это просто набор таких прав. Подробности есть в разделе о ролях и правах в документации для разработчиков WordPress.