Права редактора в WordPress: что проверить до настройки

Редактору нужно поправить меню сайта, а в левой колонке админки нет раздела «Внешний вид». Самый частый выход, сделать человека администратором, заодно отдаёт ему установку плагинов, смену паролей и раздел «Настройки». Ниже способ выдать роли «Редактор» одно конкретное право, проверить результат и откатить, если что-то пошло не так. На всё уйдёт 15–20 минут, код приведён целиком.

Что нужно иметь до начала

• WordPress 6.x. Функции ядра из примера существуют давно, но названия пунктов меню в вашей версии и локализации могут отличаться.
• Учётная запись с ролью «Администратор».
• Доступ к файлам сайта по SFTP или через файловый менеджер хостинга. Либо терминал с установленным WP-CLI. Хватит одного варианта.
• Свежая копия базы данных. Роли и права хранятся в таблице options, и ошибка в них ломает вход в админку.
• Второй браузер или приватное окно, чтобы проверять результат под другим пользователем.
• Свободный адрес электронной почты для тестовой учётной записи.

Capability (право) в WordPress: строковый ключ вроде edit_posts или edit_theme_options. Роль есть набор таких ключей, а проверка в коде всегда идёт по праву, а не по названию роли. Поэтому правильнее добавить право, чем поднимать роль.

Что редактор уже умеет и что можно добавить

По умолчанию редактор правит и публикует чужие записи и страницы, модерирует комментарии, управляет рубриками и загружает файлы. Всё остальное выдаётся по одному праву. Вот те, что просят чаще всего, и цена каждого.

Каждое лишнее право превращает учётную запись редактора в более ценную цель. Взломать её должно быть выгоднее ровно настолько, насколько она нужна для работы.

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

Пошаговая инструкция

1. Сделайте копию базы. Через панель хостинга или командой wp db export. Проверка: файл дампа лежит на вашем диске и весит больше нуля.
2. Создайте тестового пользователя. «Пользователи», затем «Добавить нового», роль «Редактор». Проверка: в списке пользователей у него указана роль «Редактор».
3. Войдите под ним в приватном окне. Проверка: в левом меню нет пунктов «Внешний вид», «Плагины» и «Настройки». Если они есть, у пользователя другая роль или права ему выдал сторонний плагин.
4. Зафиксируйте исходное состояние. Откройте под этим же пользователем адрес /wp-admin/nav-menus.php. Проверка: вместо страницы меню вы увидите отказ в доступе (в английской локали «Sorry, you are not allowed to access this page»).
5. Создайте плагин. В каталоге wp-content/plugins/ сделайте папку editor-menus-access и файл editor-menus-access.php с кодом ниже. Право пишется в базу, поэтому его достаточно выдать один раз при активации, а не проверять на каждом запросе. Проверка: в разделе «Плагины» появился «Editor Menus Access».

   <?php
   /**
    * Plugin Name: Editor Menus Access
    * Description: Выдаёт роли «Редактор» право edit_theme_options, пока плагин активен.
    * Version: 1.0.0
    */
   
   // Прямой запуск файла вне WordPress запрещён.
   if ( ! defined( 'ABSPATH' ) ) {
       exit;
   }
   
   // При активации добавляем право. Оно сохранится в базе.
   register_activation_hook( __FILE__, function () {
       $role = get_role( 'editor' );
       if ( $role ) {
           $role->add_cap( 'edit_theme_options' );
       }
   } );
   
   // При деактивации забираем право обратно.
   register_deactivation_hook( __FILE__, function () {
       $role = get_role( 'editor' );
       if ( $role ) {
           $role->remove_cap( 'edit_theme_options' );
       }
   } );

6. Активируйте плагин. Проверка: вверху страницы появилось сообщение об активации, ошибок нет.
7. Проверьте под тестовым пользователем. Обновите страницу в приватном окне. Проверка: появился раздел «Внешний вид», а адрес /wp-admin/nav-menus.php открывается. В блочной теме редактор получит и доступ к Редактору сайта, учитывайте это.
8. Проверьте откат. Деактивируйте плагин и обновите страницу в приватном окне. Проверка: «Внешний вид» снова исчез. Если удалить плагин, не деактивировав, право останется в базе.

То же самое через WP-CLI

Если на сервере есть WP-CLI, плагин не нужен. Команды выполняйте из корня сайта.

wp cap add editor edit_theme_options
wp cap list editor
wp cap remove editor edit_theme_options

Первая команда выдаёт право, вторая выводит все права роли (в списке должна быть строка edit_theme_options), третья отзывает. На multisite добавляйте параметр --url с адресом нужного сайта сети: роли там хранятся отдельно для каждого сайта.

Если не получилось

• Плагина нет в списке. Проверьте путь: файл должен лежать как wp-content/plugins/editor-menus-access/editor-menus-access.php, а в шапке должна быть строка Plugin Name.
• «Plugin could not be activated because it triggered a fatal error». Обычно при копировании потерялась строка <?php или фигурная скобка. Сравните файл с примером посимвольно.
• «Cannot modify header information - headers already sent by…». Перед <?php попал пробел, пустая строка или BOM из редактора. Сохраните файл в UTF-8 без BOM.
• Плагин активен, но доступа по-прежнему нет. Скорее всего, права роли переопределяет другой плагин управления ролями. Либо вы выдали право не на том сайте multisite. Посмотрите wp cap list editor именно для нужного адреса.
• Раздел «Внешний вид» есть, а пункта «Меню» нет. Тема не регистрирует классические меню. В блочных темах навигацией управляют через Редактор сайта.

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

Пройдите по списку тех, кто может публиковать: команда wp user list --role=editor покажет всех редакторов. Лишние учётные записи отключите, а для оставшихся включите двухфакторную защиту средствами вашего плагина безопасности. Раз в квартал сверяйте права роли через wp cap list editor с тем, что вы выдавали намеренно. Создание собственной роли через add_role для случаев, когда прав нужно много, отдельная тема.