Университетские веб-сайты публикует практически каждый. Факультеты, кафедры, приёмная комиссия, исследовательские центры и студенческие службы — все размещают страницы в открытом доступе, обычно силами десятков авторов, для которых работа с сайтом не является основной задачей. Без чётко определённого маршрута это приводит к опечаткам, страницам, не соответствующим бренду, информации, которую никто не удосужился вовремя убрать, а иногда и к тому, что нечто чувствительное появляется в открытом доступе прежде, чем это вообще прочитал кто-либо с соответствующими полномочиями.
Рабочий процесс утверждения контента задаёт каждой странице один и тот же путь к публикации. Она начинается как черновик, ждёт назначенного рецензента и выходит в свет, как только этот рецензент даёт своё одобрение. В Drupal это реализуется двумя базовыми модулями, без каких-либо платных дополнений. В этой статье рассматривается, как эти модули работают вместе, как подогнать процесс под масштаб учреждения, что меняется на многоязычных сайтах, и какие детали настройки определяют, продолжает ли очередь на рецензирование двигаться или тихо застревает.
Почему университетской публикации нужен этап проверки
Университет — это крупный децентрализованный издатель, и именно это сочетание делает редакционный контроль сложной задачей. Авторы есть на каждом факультете и в каждом подразделении, при этом их уровень подготовки в веб-технологиях сильно различается, тогда как центральная служба коммуникаций и ИТ-отдел по-прежнему несут ответственность за точность информации, соответствие бренду, доступность, а на страницах приёмной комиссии или в разделах с политиками — ещё и за юридические и репутационные риски.
Учреждения, управляющие крупнейшими хозяйствами на базе Drupal в сфере высшего образования, изначально построены именно вокруг этой проблемы. Гарвард, Йель, Стэнфорд и Дьюк — каждый из них эксплуатирует собственную, поимённо обозначенную институциональную платформу Drupal, куда публикуют материалы кафедры и исследовательские группы, вместо разрозненного набора несвязанных между собой сайтов, а собственная документация платформы Гарварда перечисляет публикацию контента и управление пользователями в одном ряду как ключевые функции. Как только сотни подразделений начинают пользоваться одной платформой, вопрос о том, кто вправе публиковать материалы, перестаёт быть деталью и становится центральным вопросом управления платформой в целом.
Смысл не в том, чтобы замедлить работу авторов. А в том, чтобы дать возможность автору с факультета, публикующему материал впервые, свободно писать черновик, пока обученный сотрудник подтверждает соответствие страницы стандартам, прежде чем её увидит кто-либо за пределами учреждения.
Как это работает: Workflows и Content Moderation
По умолчанию страница в Drupal может находиться в одном из двух состояний — опубликована или не опубликована, чего недостаточно для описания процесса проверки. Два базовых модуля расширяют эти возможности.
Workflows определяет состояния, которые может занимать контент, и переходы между ними. Это абстрактная форма вашего процесса, и ничего больше. Сам по себе он вообще ничего не делает, а если установить только его, появится экран с сообщением о том, что нет доступных типов рабочих процессов.
Content Moderation предоставляет этот тип рабочего процесса. Он привязывает рабочий процесс к реальному контенту, например к определённым типам контента, и связывает каждый переход с собственным разрешением, чтобы продвигать страницу дальше могли только предусмотренные роли.
Оба модуля являются базовыми (core), и их историю стабилизации стоит знать, поскольку её часто излагают неточно. Content Moderation вошёл в ядро как экспериментальный модуль в Drupal 8.2, а Workflows последовал за ним в версии 8.3. Workflows был отмечен как стабильный в версии 8.4, тогда как Content Moderation всё ещё находился в статусе бета-версии, и Content Moderation достиг стабильного статуса в Drupal 8.5.0. Content Moderation требует Drupal версии 8.4 или новее. В Drupal 10 и 11 оба модуля являются просто частью ядра и включаются со страницы «Extend» (Расширить). Официальная документация по Content Moderation шаг за шагом описывает настройку.
Состояния, переходы и разрешения, которые их обеспечивают
В основе любого рабочего процесса Drupal лежат три понятия. Состояния (States) — это условия, в которых может находиться контент. Переходы (Transitions) — это разрешённые перемещения между ними, и они направленные, поэтому страница не может перескочить из черновика сразу в архив, если вы это явно не разрешите. Ревизии (Revisions) — это лежащая в основе версионированная история. Drupal поддерживает ожидающие ревизии (pending revisions), а это значит, что редактор может подготовить новую версию уже опубликованной страницы, при этом никакая часть этой работы не станет видна публично, пока она не будет одобрена.
Именно разрешения превращают всё это из простой схемы в реальный механизм контроля. Drupal создаёт отдельное разрешение для каждого перехода, поэтому право использовать переход «Опубликовать» можно предоставить рецензентам и не давать авторам. Этот единственный механизм и составляет всю цепочку утверждения.
Активация Content Moderation создаёт стандартный редакционный (Editorial) рабочий процесс, содержащий состояния «Черновик», «Опубликовано» и «Архивировано». Одна деталь застаёт многих врасплох: этот рабочий процесс по умолчанию создаётся автоматически только в том случае, если сайт был установлен из стандартного (standard) профиля установки. При минимальном (minimal) или пользовательском профиле его придётся выстраивать самостоятельно.
Работоспособный набор состояний для университета обычно немного расширяет стандартный набор.
| Состояние | Что оно означает | Переводит в это состояние |
|---|---|---|
| Черновик | Пишется или редактируется, не видно публике | Любой автор |
| Требует проверки | Отправлено и ожидает рецензента | Любой автор |
| Требует доработки | Возвращено автору с замечаниями | Рецензенты |
| Опубликовано | Находится в открытом доступе на сайте | Рецензенты и администраторы |
| Архивировано | Снято с сайта, но сохранено | Администраторы |
Одно из следствий стандартного рабочего процесса удивляет большинство новых редакторов: кнопки «снять с публикации» не существует. Чтобы снять опубликованную страницу с сайта, нужно перевести опубликованную ревизию в состояние «Архивировано».
Подгонка рабочего процесса под масштаб университета
На практике университет сопоставляет это с небольшим набором ролей, а не с обширным.
| Роль | Что может делать | Обычно принадлежит |
|---|---|---|
| Автор | Создаёт и редактирует черновики, отправляет контент на проверку. Без права на переход «Опубликовать». | Сотрудники факультетов и кафедр |
| Рецензент | Проверяет, редактирует, публикует или возвращает контент. Нуждается в разрешении просматривать неопубликованный контент и последнюю версию. | Обученные редакторы факультета или центральная веб-команда |
| Администратор | Всё, что может рецензент, плюс назначение ролей и настройка рабочих процессов. | Центральный ИТ-отдел или служба коммуникаций |
Руководящий принцип — минимально необходимые привилегии. Тому, кто поддерживает страницы курсов, не нужны настройки сайта или управление пользователями, и удержание этой роли в узких рамках защищает платформу в целом.
Drupal позволяет иметь на одном сайте несколько рабочих процессов, каждый из которых применяется к разным типам контента, и именно здесь модель становится по-настоящему полезной в университетском масштабе. Обычные страницы кафедр проходят по короткому маршруту. Правила приёма, пресс-релизы и юридические уведомления проходят через дополнительное состояние утверждения, которое обычные страницы минуют. Так вы применяете столько контроля, сколько действительно оправдано для каждого вида контента, вместо того чтобы пропускать всё через один и тот же процесс.
Это редакционный аналог архитектурного управления, и на крупных хозяйствах эти два подхода работают вместе. Наше руководство по управлению университетскими веб-сайтами с помощью Drupal multisite охватывает архитектурную половину вопроса.
Многоязычные сайты: раздельная проверка каждого перевода
Drupal 8.5 добавил поддержку независимого модерирования переводов, и на двуязычном университетском сайте это меняет форму процесса.
Каждый перевод имеет собственное состояние модерации. Английская версия страницы может быть опубликована, пока другая языковая версия ещё находится на проверке, или наоборот. Это важно, потому что один-единственный рецензент редко обладает языковой компетенцией, достаточной для утверждения каждой версии, а рецензент, утверждающий контент, который он не может полностью прочитать, ставит формальную печать, а не осуществляет реальный контроль.
Определите зоны ответственности по языкам прежде, чем что-либо настраивать. Решите, кто проверяет какой язык, и решите, что должны видеть посетители, когда один перевод утверждён, а другой — нет. Независимая модерация означает, что страница может на законных основаниях быть опубликована на одном языке и отсутствовать на другом, поэтому убедитесь, что поведение при отсутствии перевода (fallback) соответствует тому, что вы намеревались получить.
Детали настройки, из-за которых очередь на проверку застревает
Большинство рабочих процессов утверждения, которые не работают, проваливаются не из-за проекта самого процесса. Они проваливаются из-за мелких деталей настройки, из-за которых очередь становится невидимой или непригодной для использования.
- Рецензенты не видят, что им нужно проверять. Одних только разрешений на переходы недостаточно. Рецензентам также нужно разрешение просматривать последнюю версию и просматривать любой неопубликованный контент. Без этого очередь на проверку просто выглядит пустой.
- Черновики накапливаются и публикуются все вместе. Ревизии черновиков накопительные, то есть каждая строится на предыдущей, а не существует отдельно. Если несколько человек сохраняют черновики одной и той же страницы прежде, чем кто-либо её проверит, публикация не выпускает только одно из этих изменений. Она выпускает их все сразу, что легко упустить из виду на странице с несколькими авторами.
- Контент не может напрямую перейти в проверку. Переходы направленные, поэтому, если вы явно не определите переход из состояния «Опубликовано» в ваше состояние проверки, автору, обновляющему опубликованную страницу, придётся сначала сохранить её как черновик, а затем отправить на проверку. Этот переход легко упустить, когда рабочий процесс выстроен вокруг новых страниц, а не редактирования уже существующих.
- Никто не знает, что настала его очередь. При ручной проверке контент застревает на этапе проверки, потому что никто не заметил его появления. Content Moderation Notifications отправляет письмо выбранной роли или автору контента при каждом переходе элемента между состояниями и настраивается на странице /admin/config/workflow/notifications. Панель, отображающая всё, что в данный момент находится в процессе, покрывает остальное.
- Рецензентам всё равно нужно входить в систему. Drupal показывает неопубликованные ревизии только авторизованным пользователям, обладающим нужными разрешениями, поэтому рабочий процесс, рассчитанный на то, что занятой декан мельком взглянет на страницу, не будет работать так, как задумано.
Когда рабочий процесс утверждения того не стоит
Модерация существует для того, чтобы отделить людей, создающих контент, от людей, которые его утверждают. Там, где это одни и те же люди, она добавляет трение, не добавляя контроля.
Сайту, которым управляют один или два доверенных редактора, у которых у всех есть права на публикацию, модерация не нужна, потому что пропускать собственную работу через собственную же очередь — значит замедлять публикацию без всякой пользы. Рабочий процесс также становится обузой, когда цепочка длиннее, чем учреждение способно обеспечить кадрами. Если страница должна пройти через нескольких занятых утверждающих, очередь превращается в узкое место, а авторы начинают искать способы её обойти, в итоге оставляя учреждение с меньшим контролем, чем было раньше.
Совет, который остаётся актуальным для крупных учреждений: держите модерацию настолько простой, насколько это действительно оправдано риском. Начните с состояний, которые вам реально нужны, и добавляйте новое только тогда, когда возникает реальная редакционная потребность, а не выстраивайте процесс ради самого процесса. Рабочий процесс, который люди научились обходить, хуже, чем полное его отсутствие.
Прежде чем брать на себя обязательства, стоит знать о двух ограничениях. Модерация применяется только к сущностям, поддерживающим ревизии, что охватывает узлы (nodes), пользовательские типы блоков и термины таксономии, но не всё на сайте. Кроме того, в основе всего этого лежит решение о платформе; если этот вопрос всё ещё открыт, наше сравнение Drupal и WordPress для университетов рассказывает, где каждый из них уместен.
Настроенное с такой дисциплиной, утверждение контента перестаёт быть дополнительным слоем и становится частью того, как работает платформа. Факультеты и кафедры широко участвуют в создании контента, а перед всем, что доходит до публики, стоит надёжная проверка. В компании Drupart команда Drupal4edu строит платформы на базе Drupal для таких университетов, как Университет Сабанджи, Ближневосточный технический университет (METU) и Йылдызский технический университет, где редакционное утверждение опирается на тот же базовый фундамент, что описан здесь. Наш обзор Drupal в образовании подробнее рассказывает о том, почему этот фундамент подходит для высшего образования.
Часто задаваемые вопросы о модерации контента в Drupal
Является ли модерация контента частью ядра Drupal?
Да. Workflows и Content Moderation — оба базовые (core) модули, включаются со страницы «Extend» (Расширить), и покупать или скачивать ничего не нужно. Workflows был отмечен как стабильный в Drupal 8.4, а Content Moderation — в версии 8.5.0, при этом Content Moderation требует Drupal версии 8.4 или новее. Дополнительные опциональные возможности, такие как уведомления по электронной почте и панели модерации, поступают из contributed-модулей, но сама механика утверждения встроена непосредственно в Drupal.
В чём разница между состоянием и переходом?
Состояние — это условие, в котором может находиться контент, например «Черновик», «Требует проверки», «Опубликовано» или «Архивировано». Переход — это разрешённое перемещение из одного состояния в другое, например «Опубликовать» или «Архивировать». Это различие важно, потому что разрешения привязаны к переходам, а не к состояниям. Вы контролируете, кто может продвигать страницу дальше, предоставляя или отзывая каждый переход, поэтому состояния описывают, где сейчас находится контент, а переходы определяют, как и кем он попадает на следующий шаг.
Могут ли разные типы контента использовать разные рабочие процессы?
Да, и на университетском сайте это одна из самых полезных вещей, которую можно настроить. Вы можете создать несколько рабочих процессов и применить каждый к разным типам контента. Новость кафедры может использовать простой маршрут «черновик — опубликовано», в то время как правило приёма проходит через дополнительное состояние утверждения. Тогда каждый тип контента несёт ровно столько контроля, сколько ему реально требуется.
Как снять страницу с публикации после включения модерации?
В стандартном редакционном (Editorial) рабочем процессе нет отдельного действия для снятия с публикации. Вместо этого вы переводите опубликованную ревизию в состояние «Архивировано», что убирает страницу с публичного сайта, сохраняя при этом её историю ревизий нетронутой. Редакторам, привыкшим к простому переключателю «опубликовано / не опубликовано», обычно достаточно один раз на это указать, после чего это становится привычным делом.
Как рецензенты узнают, что их что-то ждёт?
Через модуль Content Moderation Notifications — contributed-модуль, который отправляет письмо по электронной почте, когда контент переходит между состояниями. Он может уведомлять всех, кто обладает ролью рецензента, или автора контента, настраивается на странице /admin/config/workflow/notifications и работает вместе с базовым модулем Content Moderation. В сочетании с панелью, показывающей всё, что в данный момент находится в процессе, он предотвращает ситуацию, когда контент незаметно застревает на проверке.