Роли WordPress: какой доступ дать автору, маркетологу и подрядчику

Какой доступ нужен человеку для его работы

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

Разберём отдельный сайт компании на WordPress с блогом и страницами услуг, без объединения сайтов в сеть Multisite. Автор готовит материалы, маркетолог отвечает за публикацию, технический подрядчик сопровождает сайт. Это разные задачи, поэтому одинаковая административная учётная запись для всех создаёт лишние возможности без понятной пользы.

Я рекомендую сначала выписать действия сотрудника и лишь затем выбирать роль, потому что знакомые названия «Автор» и «Редактор» не всегда совпадают с внутренними должностями компании и могут дать человеку больше или меньше прав, чем требуется в конкретном процессе подготовки материалов. Должность описывает место в команде. Роль определяет действия в системе. Один маркетолог только передаёт черновики на согласование, другой ведёт содержание всего сайта. Их потребности отличаются, даже если в штатном расписании они называются одинаково.

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

Участник, автор, редактор и администратор

По документации WordPress, редактор может управлять и публиковать материалы других пользователей, автор — собственные записи, участник — готовить свои записи без публикации. У участника по умолчанию нет права загрузки файлов; у автора оно есть. Администратор получает возможности управления сайтом.

Эта разница важна при выборе рабочего процесса: если внештатный автор присылает текст, а сотрудник компании принимает содержание и выпускает его, возможность самостоятельной публикации создаст дополнительный путь обхода принятого согласования и не поможет выполнению самой задачи автора. Для этой задачи я советую роль участника. Черновик остаётся черновиком. Ответственный за выпуск видит материал перед публикацией. При необходимости загрузки изображений отдельно решают, кто это делает и какие права действительно требуются.

Записи и страницы — разные типы содержания. В нашем разборе статьи блога оформлены как записи, услуги — как страницы: автор управляет первыми, а для вторых подходит стандартный редактор. Отсюда практический вопрос к подрядчику: какими типами содержания в вашей сборке являются услуги, кейсы и новости?

Для конструктора, магазина и специальных типов материалов подрядчик отдельно показывает доступные сотруднику операции. Их права могут отличаться от базовых, поэтому задания по приёмке составляют для тех разделов, которые команда действительно ведёт на сайте.

Почему редактору не всегда нужен администратор

Для замены текста и фотографии не требуется автоматически выдавать возможность устанавливать расширения или менять технические параметры проекта. Сначала стоит понять, почему нужное действие недоступно текущему сотруднику.

У административного доступа другая ответственность. Он полезен человеку, который сопровождает конфигурацию сайта и понимает последствия изменения темы, расширений и пользователей. Повседневную редактуру удобнее отделить от этих задач.

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

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

Собственная роль для постоянной задачи

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

В WordPress можно создавать собственные роли. В учебном материале Learn WordPress о собственных ролях разбирается настройка через плагин Members: изменения стандартной роли сохраняются, поэтому автор урока советует сначала скопировать роль и доработать копию. Это полезный повод обсудить с разработчиком явную роль для проекта вместо незаметной переделки привычного «Редактора».

Я рекомендую собственный набор прав только при понятной постоянной задаче, когда компания может назвать разрешённые действия и ограничения, а исполнитель готов поддерживать их после обновления используемых расширений и изменения устройства сайта в течение дальнейшего сопровождения. Иначе настройка быстро превращается в набор исключений. Сотрудник получает одну дополнительную возможность, затем ещё одну. Через некоторое время никто не может объяснить, что именно ему разрешено. Короткое описание роли и набор испытаний сохраняют эту границу понятной.

Отдельный вопрос — содержание одного раздела. Простого названия роли может оказаться недостаточно для ограничения материалов по рубрике или подразделению. Если это требование важно, его принимают как самостоятельную функцию: сотрудник изменяет разрешённую страницу и получает отказ для другой.

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

Доступ подрядчика и границы работ

Работа с текстами, настройка формы и обновление темы требуют разного доступа. Поэтому запрос «дайте администратора» полезно дополнить перечнем операций и сроком работ.

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

Доступ к WordPress и доступ к серверу — разные вещи. Возможность изменить статью через CMS не требует сама по себе подключения к файлам хостинга. Если техническая задача затрагивает сервер, её объём и способ работы обсуждают отдельно с ответственным за инфраструктуру.

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

Как принять выданные права на практике

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

Затем нужны действия за пределами роли: изменение чужого материала для автора, работа с неподходящим разделом для ограниченного редактора или установка расширения для человека, который отвечает только за содержание. Ожидаемый отказ так же важен для приёмки, как удачное сохранение текста.

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

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

Что делать с доступом после завершения работы

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

При удалении пользователя в WordPress возникает отдельный вопрос о его содержании. В описании экрана пользователей предусмотрен выбор: удалить принадлежащие пользователю материалы либо передать их другому пользователю. Решение о сохранении статей и страниц требуется принять до удаления записи, чтобы завершение доступа не превратилось в потерю содержания сайта.

Я рекомендую отделять прекращение доступа от решения о судьбе опубликованных материалов, потому что авторство статьи, её дальнейшее сопровождение и возможность входа бывшего сотрудника решают разные задачи и не обязаны прекращаться одновременно после окончания его участия в проекте. Сначала определяют владельца материалов. Затем выбирают действие с учётной записью. После изменения смотрят, что публикации сохранились и доступны читателям. Такой порядок особенно полезен для блога, где часть текстов подготовили внешние авторы, а содержание продолжает работать на компанию.

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

Если подрядчик использовал другие подключения, их учитывают отдельно. Удаление пользователя CMS нельзя считать подтверждением отзыва доступа к хостингу, домену или сторонним сервисам. Этот разбор остаётся у ответственного за проект и не требует выдавать маркетологу все технические пароли.

Какой вопрос задать до выдачи учётной записи

Первый вопрос подрядчику: «Какие действия этот человек сможет выполнить и какие действия вы покажете как недоступные?» Ответ сразу связывает настройку с работой сотрудника.

Для небольшого сайта можно начать со стандартных ролей и нескольких испытаний, а отдельные ограничения добавлять по мере появления подтверждённой потребности, чтобы сопровождение прав не стало сложнее самой редакционной работы и не требовало постоянных исключений для каждого нового материала компании. Такой подход оставляет систему понятной. Маркетолог знает свой порядок публикации. Подрядчик видит границы задачи. Руководитель понимает, кому поручено управление содержанием и у кого есть технические возможности.

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