WordPress: редакторские роли
Структура материалов и меню «Веб-мастерской» уже согласованы. Пока все действия выполняет администратор учебной установки, но в настоящей редакции это неудобная модель. Автору нужно подготовить текст, редактору — проверить и выпустить его, сопровождающему — менять тему и плагины. В этом уроке разделим эти обязанности и увидим, почему роль пользователя нельзя выбирать только по привычному названию должности.
WordPress принимает решение через capabilities — отдельные возможности, например редактирование или публикацию записей. Роль объединяет набор таких возможностей. Название роли является удобной организационной оболочкой, но фактический доступ зависит от её состава, типа материала и расширений. Стандартные роли и различия их прав описаны в официальном справочнике. В серии рассматриваем одну обычную установку, не Multisite, где у администратора и супер администратора существуют дополнительные особенности.
Три участника учебной редакции
Введём автора Анну, редактора Бориса и сопровождающую Веру. Это вымышленные участники, реальные аккаунты при подготовке не создавались. Для сценария статьи image-shift Анна выбирает роль Contributor — участник. Борис получает Editor — редактор. Вера остаётся Administrator для настройки системы. У каждого отдельный аккаунт. Общий пароль «редактор» разрушил бы связь действий с человеком и затруднил отзыв доступа после завершения сотрудничества.
Участник может готовить собственные записи, но не публиковать их штатной возможностью. Ограничения медиа важны: стандартный Contributor не получает загрузку файлов. Если Анне нужна иллюстрация, в нашем процессе она передаёт подготовленный исходник Борису, а он проверяет условия использования и загружает копию. Не выдавайте Administrator ради одного изображения. Если редакция действительно требует другую комбинацию прав, её нужно оформить отдельно и проверить, а не полагаться на смысл слова «автор».
Роль Author позволяет публиковать собственные записи и загружать медиа. Это подходящий вариант для человека, которому уже доверена самостоятельная публикация. В нашем сценарии обязательна проверка вторым участником, поэтому штатный Author слишком широк для Анны. WordPress сам не знает правило «все статьи должны пройти Бориса»: если пользователю разрешена публикация, он может воспользоваться этим правом. Редакционный договор и системный доступ должны согласовываться.
Редактор имеет возможности работать с чужими материалами и страницами; администратор отвечает ещё и за настройки установки. Выбор Editor для Бориса означает существенное доверие к содержимому сайта, а не только разрешение исправлять опечатки. Он сможет изменить «Контакты» и другие тексты. Поэтому доступ надо соотнести с реальной областью ответственности. Когда появится много независимых команд, стандартных ролей может стать недостаточно для изоляции разделов.
Матрица возможностей
Для одного учебного задания зафиксируем желаемые действия. Таблица описывает процесс нашей редакции, а не исчерпывающий перечень встроенных capabilities:
| Действие | Анна | Борис | Вера |
|---|---|---|---|
| Готовить собственную запись | да | да | да |
| Выпустить запись Анны | нет | да | возможно, но не основной процесс |
| Проверить и загрузить иллюстрацию | передать исходник | да | техническая помощь |
| Менять страницу Контакты | нет | да | да |
| Установить плагин | нет | нет | да |
| Изменить системные настройки | нет | нет | да |
Слово «нет» должно означать фактическую невозможность, если это требование безопасности. Скрытие кнопки с помощью CSS не запрещает серверную операцию. Для собственного плагина позднее будем проверять capability на сервере. Даже если пользователь не видит поле, он может сформировать запрос другим инструментом. Роли помогают организовать интерфейс, но защита должна находиться в месте выполнения изменения данных.
Проверьте доступ в отдельных сеансах. Сначала войдите как Анна и подготовьте черновик. Она должна иметь возможность отправить его на проверку, но не сделать публичным. Затем Борис открывает чужую запись, исправляет текст и публикует её в закрытом стенде. Вера проверяет настройки темы, не используя аккаунт Бориса. Наблюдаемое отсутствие действий записывается отдельно от ожидаемого: разные расширения могут изменить стандартные возможности.
Чужой материал и владение
Рассмотрим ошибку: Анна пытается исправить уже опубликованную запись другого автора. Право редактировать свои тексты не означает право изменять все записи. Механизм учитывает принадлежность объекта и его состояние. В собственном коде используется проверка current_user_can('edit_post', $post_id), а не условие «роль называется editor». Проверка конкретного объекта позволяет WordPress сопоставить действие с типом материала, авторством и действительными возможностями пользователя.
Это различие станет особенно важным для будущего типа курса pw_course. В нашем минимальном плагине он намеренно использует стандартные права записей, чтобы не обещать отдельную систему управления преподавателями. Создание собственных capability-наборов требует их назначения ролям и анализа переходов. Одно изменение аргумента регистрации типа не создаёт готовое разграничение редакции. Когда курсами должна управлять другая команда, расширяем модель прав самостоятельным проектным шагом.
Не путайте подтверждение намерения с полномочиями. WordPress nonce помогает защитить действие от нежелательного инициирования через чужую страницу, но не делает пользователя редактором. У серверного обработчика должны быть и проверка допустимого действия, и проверка полномочий. В этой главе мы не пишем форму изменения прав и не создаём endpoint административных операций. Разбираем ответственность, чтобы в следующих уроках не использовать nonce как универсальный пароль.
Как завершить доступ
При передаче проекта зафиксируйте, кто назначает роли и когда они пересматриваются. Человек, переставший работать над статьями, не должен сохранять административный доступ по инерции. При этом удаление автора требует решения о судьбе его материалов: записи можно передать другому пользователю, а не уничтожать вместе с аккаунтом. На учебном стенде достаточно описать этот процесс; в рабочей системе понадобятся подтверждённые правила идентификации и восстановления доступа.
Ожидаемый результат урока — три отдельных участника и матрица, которая объясняет путь записи от Анны к публикации Борисом. Операции с пользователями и сеансы в этой задаче не выполнялись. Результаты считаются ожидаемыми для стандартных ролей без сторонних изменений. Если выбранная установка позволяет Анне выпустить чужую статью, сначала найдите источник расширенных capabilities. Следующий урок продолжит тот же пример и определит, какие состояния материала и какие подтверждения связывают действия разных участников редакции.