Редакционная CMS
Newsroom CMS
Редакционная CMS — программная система, в которой сотрудники редакции создают, хранят, редактируют, согласуют и публикуют материалы, распределяя действия между участниками работы.
CMS расшифровывается как Content Management System — система управления содержанием. Определение опирается на исследование редакционных систем Торстена Бисселя и соавторов: они рассматривают совместную подготовку веб-материалов, хранение содержания, редакционные роли и выпуск страниц. Современный пример согласования до публикации описан в документации Drupal. [1] [3]
Кратко
- Сохранить исправление и показать его читателям — разные действия.
- Права сотрудника определяются настройками, а не только названием роли.
- Удобство для авторов, доступность содержания и безопасность требуют разных проверок.
- Статус материала помогает организовать работу, но не доказывает достоверность текста.
Происхождение и история термина
В докладе конференции WebNet 1999 редакционные CMS описаны как особый класс средств управления сайтами. Авторы исследовали системы для крупной немецкой газеты в сентябре–октябре 1998 года. Задачей была согласованная работа редакторов над постоянно обновляемым веб-изданием: отдельных файлов и программ редактирования для этого было недостаточно. [1]
Это свидетельство существования явления, а не дата его изобретения. Уже тогда обсуждались черновики, возврат текста на доработку, права участников и отделение содержания от оформления. [1] В современной документации Drupal эти задачи выражены через настраиваемые состояния, переходы и отдельную рабочую версию опубликованного материала. [3] Так прослеживается преемственность: меняются способы реализации, но остаётся задача управлять совместной подготовкой публикации.
Суть и механизм
Разобраться в CMS помогает разделение трёх понятий. Материал — содержание, с которым работает редакция. Версия — его сохранённый вариант. Состояние показывает, на каком этапе работы находится этот вариант: например, черновик или опубликованный текст. Переходом называют разрешённое изменение состояния. Такая организация предусмотрена, в частности, модулем Content Moderation — средством согласования содержания в Drupal. [3]
Рассмотрим учебный пример городской редакции. Журналист готовит новость об изменении автобусного маршрута. Для этой новости редакция выбрала отдельные поля: заголовок, основной текст, имя автора, дату и иллюстрацию. Поле — место для определённого вида сведений. Такое разделение удобно проверить на простом вопросе: может ли редактор изменить заголовок, не переписывая весь материал?
После проверки выпускающий редактор разрешает публикацию. Позже журналист исправляет время начала движения. В модели Drupal новая рабочая версия может оставаться черновиком, пока посетители видят прежнюю публикацию. [3] Следовательно, сотруднику нужно понимать, какой вариант он редактирует и какой уже доступен снаружи. Иначе сообщение «я всё исправил» окажется верным для рабочего окна и неверным для читателя.
Роль объединяет разрешённые действия пользователя. В стандартных ролях WordPress Author может публиковать собственные записи, а Contributor — готовить их, но не выпускать. В примере настройки Drupal роль Author тоже создаёт материалы, однако публикация поручена Editor. [2] [3] Поэтому при переносе процесса между системами следует сопоставлять действия, а не переводить названия должностей буквально.
Виды и классификации
Для объяснения используем редакционную классификацию по числу ступеней согласования. Она описывает организацию работы, а не официальный рейтинг программ.
| Организация работы | Как принимается решение |
|---|---|
| Прямая публикация | Автор сам выпускает подготовленный материал |
| Одно согласование | Автор передаёт материал выпускающему редактору |
| Несколько согласований | До выпуска последовательно проверяются разные стороны материала |
Например, в учебной редакции краткая афиша проходит одну приёмку, а расследование — редакционную и юридическую. Дополнительный этап имеет смысл, если ясно, кто принимает решение и что именно проверяет. Два одинаково названных статуса без разных задач только затруднят ответ на вопрос, почему текст остановился.
Отдельно можно сравнивать способы получения страницы. В историческом исследовании различались системы, заранее создающие готовые страницы, и системы, собирающие их при запросе посетителя. [1] Это техническое различие не определяет, сколько людей должно одобрить текст: правила редакции и устройство выдачи страницы решают разные задачи.
Как применяется на практике
Внедрение удобно начать с небольшого законченного сценария. Для учебной российской редакции таким сценарием будет выпуск новости о ремонте дороги. Журналист заполняет материал, редактор проверяет адрес и даты, выпускающий открывает итоговую страницу. Затем команда намеренно вносит исправление и повторяет путь до читателя.
В этом упражнении полезно заранее записать ожидаемый результат каждого действия. После сохранения черновика посетитель не должен увидеть непроверенную дату. После одобренного исправления посетитель должен увидеть новую дату. Если оба сотрудника проверяют только свои рабочие окна, ошибка в публичном результате может остаться незамеченной.
Перед выбором продукта стоит дать будущим пользователям выполнить такой сценарий. В исследовании Бисселя и соавторов подчёркивалась необходимость практической оценки с редакторами; при этом авторы честно отмечали, что в их собственном испытании полноценной пользовательской группы не было. [1] Это существенное ограничение: богатый перечень возможностей ещё не показывает, насколько легко конкретная команда выпустит и исправит новость.
Как измерить или проверить
Предлагаемая редакционная процедура начинается с таблицы «действие — пользователь — ожидаемый результат». Проверяют и разрешённые действия, и запреты. Например, журналист сохраняет свой черновик, но не публикует чужой; редактор выпускает принятую версию; посетитель видит только предназначенное ему содержание. Это учебная схема приёмки, которую нужно приспособить к выбранным правам.
Для контроля выполнения плана можно посчитать долю успешных сценариев:
Доля успешных сценариев = число сценариев с ожидаемым результатом / число выполненных сценариев × 100%.
Учебный пример: команда выполнила 12 сценариев, из них 10 дали ожидаемый результат. Получается 10 / 12 × 100% ≈ 83,3%. Знаменатель включает все выполненные сценарии, в том числе неудачные. Для запрещённого действия успехом считается корректный отказ системы. Если проверок не было, доля не определена, а не равна нулю.
Этот показатель характеризует только выбранный набор проверок. Он не измеряет общую надёжность CMS: один провал, позволяющий постороннему выпустить материал, может быть важнее нескольких удачных сохранений черновика. Поэтому рядом с долей нужны описание каждой ошибки и её последствия.
Доступность означает возможность пользоваться инструментом или содержанием, в том числе людям с инвалидностью. Рекомендации W3C ATAG 2.0 разделяют эти два направления. Например, проверка работы редактора с клавиатуры относится к инструменту, а возможность задать текстовую альтернативу изображению — к подготовке доступного содержания. [4] Для учебной новости можно проверить, удаётся ли без мыши сохранить текст и добавить осмысленное описание фотографии.
Безопасность проверяют отдельно. OWASP ASVS — стандарт требований к безопасности веб-приложений — даёт основу такой проверки; текущая стабильная версия на дату обращения — 5.0.0. [5] Упоминание стандарта в документации продукта само по себе не является результатом испытания конкретной установки.
Ошибки, ограничения и спорные вопросы
Главная ошибка — считать статус «проверено» свидетельством проверки фактов. В учебном примере редактор может нажать нужную кнопку, но не заметить ошибочный адрес. Поэтому редакционный регламент должен объяснять содержание проверки; программное разрешение перейти дальше решает только вопрос доступа к действию.
Другая ошибка — оценивать систему исключительно по числу функций. Для небольшой команды сложная цепочка согласований может оказаться неудобной, а прямой выпуск — неприемлемым для материала, требующего отдельной экспертизы. Выбор зависит от задач и распределения ответственности, а не от количества статусов.
Наконец, сохранённый материал, его предварительный просмотр и страница для посетителя нужно различать. Учебный сценарий исправления завершается проверкой публичного результата. Без неё команда знает только о выполненных внутренних действиях, но не о том, что увидел читатель.
Правовой аспект
Если в CMS обрабатываются персональные данные, применяются соответствующие требования закона. Части 2, 4 и 5 статьи 5 Федерального закона от 27.07.2006 № 152-ФЗ, в редакции закона от 26.07.2026, связывают обработку с заранее определёнными законными целями и запрещают избыточность данных относительно этих целей. [6]
Для учебной редакции это повод отдельно рассмотреть сведения в учётной записи сотрудника и сведения, предназначенные для публикации: одинаковое место хранения не делает их назначение одинаковым. Настройка прав доступа не отвечает сама по себе на вопрос о правовом основании обработки. Этот раздел обозначает общий принцип; правомерность конкретной обработки требует самостоятельной юридической оценки.
Частые вопросы
Любой автор может публиковать?
Новый черновик сразу заменяет публикацию?
В рассмотренной настройке Drupal — нет. Рабочая и опубликованная версии могут существовать отдельно. [3]
Достаточно проверить кнопку публикации?
В предлагаемой процедуре нет: нужно проверить ограничения доступа и итоговую страницу для посетителя.
CMS заменяет редактора?
Распределение действий в программе не заменяет профессионального решения о точности, значимости и допустимости материала.
Решить с помощью сервиса
Медиатрон — программное обеспечение для автоматизации работы редакции интернет-СМИ: сбора и мониторинга источников, организации рабочего места редакции и контроля публикаций. По внутренней справке разработчика сервис работает в изданиях холдинга altai.news и barnaul-altai.ru.
Связанные термины
Источники
- Bissel, T., Bogen, M., Borowski, M., Karajannis, A., & Löffler, J. (1999). Content management systems for editors—In search of quality. In P. De Bra & J. Leggett (Eds.), WebNet 99 world conference on the WWW and Internet proceedings (pp. 106–111). Association for the Advancement of Computing in Education. https://files.eric.ed.gov/fulltext/ED448691.pdf (дата обращения: 30.10.2026; страницы PDF 141–146). ↑ а б в г д
- WordPress. (n.d.). Roles and capabilities. https://wordpress.org/documentation/article/roles-and-capabilities/ (дата обращения: 30.10.2026). ↑ а б
- Drupal. (2026, August 18). Overview: Content moderation module. https://www.drupal.org/docs/8/core/modules/content-moderation/overview (дата обращения: 30.10.2026). ↑ а б в г д е ж
- World Wide Web Consortium. (2015, September 24). Authoring tool accessibility guidelines (ATAG) 2.0. https://www.w3.org/TR/ATAG20/ (дата обращения: 30.10.2026). ↑
- OWASP Foundation. (n.d.). OWASP application security verification standard: Overview. https://asvs.owasp.org/ (дата обращения: 30.10.2026). ↑
- О персональных данных : Федеральный закон от 27.07.2006 № 152-ФЗ : ред. от 26.07.2026 : ст. 5, ч. 2, 4, 5 // КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_61801/96fbc469f91f57235cc842a85e0516a99f23dc85/ (дата обращения: 30.10.2026). ↑
Служебный блок
- Версия
- 2.0
- Факты проверены
- Подготовка
- Редакция Медиатрона
- Публикация
- утверждена владельцем издания 4 ноября 2026 г.
Редакция Медиатрона. Факты сверены с первоисточниками на дату проверки, публикация утверждена владельцем издания.
Нашли ошибку? info@mediatrone.ru