Редакционный процесс
В учебной редакции Анна готовит запись «Почему изображение сдвигает страницу», Борис проверяет содержание, а Вера сопровождает WordPress. Роли уже ограничивают действия участников, но ещё не объясняют, в какой момент статья готова к следующему шагу. Рассмотрим редакционный процесс: состояние материала, ответственность за переход и признаки готовности. Цель — сделать выпуск понятным человеку, который открывает запись впервые, а не только её первоначальному автору.
WordPress хранит статус записи. Среди встроенных состояний есть черновик, ожидание проверки, публикация, запланированная публикация и приватный материал. Они описаны в документации статусов. Однако «технический пример проверен», «права на изображение подтверждены» и «ссылки просмотрены» не становятся самостоятельными штатными статусами автоматически. Такие сведения нужно согласовать как часть процесса и, при необходимости, реализовать отдельно.
От черновика к проверке
Анна начинает с draft: запись существует, но не доступна обычному посетителю. Она сохраняет текст, пояснения к иллюстрации и ожидаемый результат примера. Сохранение черновика важно не только для защиты от случайного выпуска. Оно позволяет передать незавершённую работу с понятным ограничением: Борис может открыть материал, но не должен считать каждое утверждение уже подтверждённым. В первом состоянии разрешены незакрытые вопросы, если они явно обозначены и не скрыты за уверенным изложением.
Когда объяснение собрано, Анна переводит запись в ожидание проверки. Для стандартного участника это нормальный путь вместо самостоятельной публикации. Согласуем передачу: она сообщает Борису ключ материала image-shift, актуальную версию текста, ссылку на исходник схемы и конкретно непроверенную часть. Последняя может звучать так: «Пример размеров изображения подготовлен; просмотр на узком экране ещё не выполнялся». Это полезнее, чем общий комментарий «вроде всё готово».
Борис проверяет текст и возвращает его в черновик, если нужны существенные изменения. Сам возврат не объясняет причину, поэтому добавляется редакционное замечание с местом и задачей. Например: «В абзаце про width/height уточнить, что атрибуты задают пропорцию, а фактическая ширина может изменяться CSS». Автор понимает, какой механизм нужно объяснить. Если замечание связано с техническим поведением, оно должно отличать ошибку утверждения от отсутствия выполненной проверки.
Не используем комментарии публичного сайта для служебного обсуждения черновика. Встроенные средства редакционной обратной связи могут отличаться между версиями и выбранными расширениями. В нашем минимальном процессе достаточно отдельной карточки материала из архива с полями состояния, владельца следующего действия и основания перехода. Она не синхронизируется автоматически с WordPress и не обещает историю утверждения внутри движка. Для настоящей редакции место этой карточки следует выбрать явно.
Что означает публикация
Статус publish делает запись публичной согласно настройкам доступа. Он не подтверждает истинность текста и не создаёт за редактора карту внутренних ссылок. Поэтому решение Бориса должно опираться на конкретные условия: вводная объясняет задачу, код обозначен как полный файл либо фрагмент, результат не выдан за выполненный без выполнения, иллюстрация имеет допустимый источник, адрес выбран осмысленно. У короткой заметки и сложного урока условия проверки могут различаться, но их нельзя подменить цветом кнопки.
Для image-shift определим три редакционных состояния, а соответствие со штатным статусом фиксируем отдельно:
| Состояние процесса | Статус WordPress | Следующий участник | Основание перехода |
|---|---|---|---|
| Текст собирается | draft | Анна | объяснение и примеры ещё изменяются |
| Передан редактору | pending | Борис | автор указал ограничения и исходники |
| Разрешён выпуск | publish на стенде | Борис | замечания обработаны, результат сформулирован честно |
Таблица не создаёт новый автоматический workflow. Если у Бориса есть право публикации, движок не заставит его заполнить карточку. Если вашей организации требуется технически обязательное утверждение, нужны соответствующие расширения или собственная реализация с серверными проверками. Этот урок задаёт модель, относительно которой такую реализацию можно оценить. Он не обещает функцию согласования, которой в учебном наборе нет.
Запланированная дата и исправление
Запланированная публикация удобна, если статья уже прошла проверку, но должна появиться позже. Учитывайте часовой пояс сайта и способ выполнения запланированных событий. WP-Cron зависит от среды и обычных обращений к сайту; на тихом стенде выполнение может задерживаться. Поэтому «назначено на 10:00» не равняется гарантированному выпуску ровно в эту секунду. Принцип работы описан в руководстве WP-Cron. Для строгого расписания потребуется отдельная настройка окружения.
Исправление опубликованной статьи имеет другой риск. Если Анна получила право менять свою публичную запись, обновление может сразу изменить видимый текст. Наличие ревизий помогает вернуться к предыдущему содержимому, но не означает обязательную модерацию каждого исправления. Согласуйте, какие изменения редактор может вносить напрямую: опечатку, ссылку, новый пример, замену основного вывода. Последние два случая зачастую требуют повторного технического чтения, даже если адрес остаётся прежним.
Рассмотрим неправильный переход: Борис публикует запись с фразой «на нашем стенде проверено», хотя стенд ещё не открывался. Статус записи становится публичным, но качество утверждения не улучшается. Исправление — обозначить ожидаемый результат и конкретную непроверенную часть либо действительно выполнить проверку позже. В материалах этой серии все учебные исполнения отмечены not_run. Редакторская готовность текста и подтверждение работающего примера — разные факты, которые следует хранить раздельно.
Последовательность действий после замечания
В нашей карточке Анна добавляет версию «пояснение размеров уточнено», Борис перечитывает именно изменённый фрагмент и возвращает запись к согласованному состоянию. Случайный новый материал не создаётся: ключ, ID и адрес прежние. Это важно для истории изменений. Если каждый раунд правок оформлять новой записью, читатель получит несколько похожих страниц, а редакция потеряет понимание, какая является окончательной. Ревизия содержания полезна только при ясной идентичности материала.
Ожидаемый итог — путь одной записи от подготовки до разрешённой публикации, с указанным владельцем следующего действия и честным состоянием технических проверок. Аккаунты, расписание и переходы в панели здесь не выполнялись. При самостоятельном прохождении проверьте возможности каждого участника и запишите фактическое поведение. Следующий урок добавит ещё одну договорённость к моменту выпуска: постоянный адрес статьи, который нельзя менять случайно вместе с новым заголовком или рубрикой.