Черновик и опубликованная версия

Оглавление серии

Сохранение текста и его публикация — разные события. Редактору нужно иметь возможность подготовить исправление, не меняя страницу сразу после каждого сохранения. Draft & Publish разделяет черновую и опубликованную версии документа. В «Редакционном доме» это позволит исправить описание сетки и проверить новый текст, пока обычный сайт продолжает показывать прежний вариант.

До урока первая статья опубликована и читается через readArticles. Не создавайте второй документ с таким же slug ради черновика: Strapi связывает редакционные версии через один documentId. После урока вы сможете объяснить, почему два запроса одного документа возвращают разные тексты и почему ни один параметр состояния не заменяет проверку прав.

Две версии одного документа

Откройте «Сетку карточек CSS Grid» в Content Manager. В опубликованном тексте summary сейчас «Размещаем карточки в адаптивной сетке». Измените его на «Размещаем три карточки и меняем число столбцов». Сохраните черновые изменения, не публикуя их. Старое опубликованное описание должно оставаться доступным обычному сайту, а редактор — видеть новую подготовленную строку.

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

Запрос	Ожидаемое summary	Значение publishedAt
status=published	Размещаем карточки в адаптивной сетке	Дата опубликованной версии
status=draft	Размещаем три карточки и меняем число столбцов	null у возвращённого черновика

Это учебное ожидание, а не результат нашего запуска. publishedAt: null в draft-ответе не доказывает, что документ никогда не публиковался: у него может существовать другая, опубликованная версия. Для такого вопроса требуется рассматривать отношение версий или подходящий publicationFilter текущей версии, а не делать вывод по одному полю.

В REST выбранной версии значение status по умолчанию — published. По актуальной документации это относится также к POST и PUT. Поэтому будущий импорт явно использует status=draft, чтобы создание данных не оказалось неожиданной публикацией. Document Service API имеет другую исходную семантику и по умолчанию работает с drafts. Сопоставление описано в REST Status и Document Service Status.

Важно читать конкретную документацию используемой версии. Старая статья о publicationState=preview не является подходящим примером для выбранного REST-контракта Strapi 5. Здесь параметр называется status, а допустимые значения draft/published. Не смешивайте примеры двух поколений в одном запросе, даже если часть полей случайно продолжает работать.

Публикация как решение редактора

После проверки подготовленного описания нажмите Publish для русской версии статьи. Повторите обычное чтение. Ожидается новая строка summary в published-ответе. Сохранение черновика и публикация должны отражаться в редакционном процессе как два отдельных решения: первое говорит «изменение записано», второе — «изменение можно показать читателю».

Для небольшой лаборатории редактор и публикующий сотрудник могут быть одним человеком. При этом полезно выполнять действия раздельно, чтобы не сформировать привычку считать любое сохранение выпуском. В дальнейшем роль автора получит работу с drafts, а роль выпускающего — право публикации. Само поле draftAndPublish в schema не назначает эти роли.

Не путайте обновление с созданием новой статьи. documentId сохраняет идентичность документа, slug сохраняет адрес, а версии содержания меняются. Если при каждом исправлении создавать новый Article, обратные связи автора и каталога будут размножаться. Кроме того, читателю потребуется новый адрес, хотя предмет страницы остался прежним. Версия документа решает именно задачу изменения существующего содержания.

Снятие публикации — ещё одно самостоятельное действие. После Unpublish обычный запрос published перестаёт находить доступную версию статьи, и сайт может вернуть 404. Черновик при этом может остаться в редакции. Следовательно, отсутствие страницы для читателя не означает окончательного удаления содержания. В плане восстановления эти операции следует отличать.

Если после публикации сайт показывает старый текст, проверьте не только состояние CMS, но и cache потребителя. Наш минимальный сервер позже использует no-store и читает CMS на каждом запросе. Реальный сайт может сохранять HTML или данные; тогда publication без обновления cache не гарантирует немедленного изменения страницы. Webhook тринадцатого урока станет уведомлением об изменении, а не магическим доказательством полной синхронизации.

Черновики требуют отдельной границы доступа

Частая ошибка — открыть Public find и успокоиться тем, что без status возвращаются опубликованные документы. Значение по умолчанию описывает выбор версии, но пользователь может попытаться передать status=draft. Право чтения и состояние нужно защищать отдельно. Поэтому в нашем контракте Public и обычная Authenticated role не читают коллекции вообще; только серверный token обращается к Content API.

Read-only token ограничивает операции записи, но не следует понимать его как «только опубликованные данные». Он может читать drafts в пределах разрешённого Content API. Если такой token попадёт в браузер, архитектурная граница исчезнет. Сервер сайта не принимает произвольный status от посетителя и самостоятельно задаёт published. Предпросмотр использует отдельный вход с проверкой подписи и временем действия.

Следует также помнить о связанных документах. В актуальном REST root status распространяется на populated отношения там, где у связанных типов включён Draft & Publish. Его нельзя помещать произвольно внутрь populate, ожидая смешать published-статью и draft-категорию. В нашей модели Author и Category не используют D&P, чтобы первый редакционный процесс оставался простым. Если добавите его позже, проверьте все зависимости выпуска.

Для выпуска полезно записать одну редакционную причину изменения, например «Уточнено количество карточек в примере». Она помогает сравнить две версии и понять, что должно измениться на странице. Техническое поле updatedAt показывает время операции, но не объясняет её смысл. В небольшой лаборатории такая запись может жить в локальной заметке рядом с документом; в рабочей редакции нужен подходящий процесс истории и согласования. Не приписываем бесплатной конфигурации платные возможности audit или review workflow. Урок показывает разделение состояний, а выбор полного редакционного процесса остаётся отдельной задачей.

Для самостоятельного опыта подготовьте ошибочную строку summary, сохраните её как draft и убедитесь, что обычное чтение должно сохранить прежний текст. Затем отмените черновое изменение средствами текущего Content Manager. Такой опыт объясняет ценность разделения лучше, чем две одинаковые версии без заметной разницы. Документ, история действий и публичная страница должны быть сопоставлены по одной конкретной статье, а не по случайным данным из панели.