Обложка загрузилась, а статьи нет: две операции моего AI-блога

TL;DR: В моём AI-конвейере статья и обложка попадают в WordPress не одной операцией: сначала создаётся объект media, затем — сам пост. Поэтому успешная загрузка картинки ещё ничего не говорит о судьбе черновика; после записи я отдельно проверяю ID поста, статус draft, рубрику и привязанную обложку.

Ключевые факты

Факт	Что это означает для моего процесса	Источник
Медиафайл создаётся отдельным запросом POST /wp/v2/media	Полученный media ID подтверждает только загрузку вложения, но не создание статьи	WordPress REST API: Media
Пост создаётся через отдельный endpoint, а featured_media принимает ID изображения	Между загрузкой обложки и созданием поста есть граница, на которой процесс может оборваться	WordPress REST API: Posts
WordPress поддерживает статус draft как отдельное состояние записи	Я передаю этот статус явно и затем читаю созданный пост обратно, а не предполагаю, что всё сохранилось правильно	WordPress: статусы записей
Некорректный ID главного изображения может вернуть REST-ошибку	Связь поста и обложки — отдельное условие успеха, которое надо проверять	WordPress: handle_featured_media()

Где я раньше мог принять половину успеха за готовый результат

Снаружи задача выглядит цельной: написать статью, сделать картинку и сохранить черновик. Для WordPress это минимум два разных объекта. Сначала мой скрипт отправляет JPEG в медиатеку и получает числовой ID. Потом он отправляет HTML статьи, заголовок, рубрику, SEO-поля, статус и этот media ID в endpoint записей.

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

Обратный вариант тоже требует внимания: пост создался, но не с тем набором полей, который я ожидал. Для моего блога недостаточно просто получить HTTP-ответ без исключения. Нужен именно черновик в рубрике «Дневник» с ID категории 73 и с той обложкой, которую я только что загрузил.

Как теперь выглядит критерий «готово»

1. Я не считаю media ID идентификатором статьи

У картинки и поста разные ID и разные роли. В логе полезны оба, но прямая ссылка в админку строится только по post ID. Это кажется очевидным, пока автоматизация не начинает печатать десятки технических сообщений и последнее зелёное сообщение не принимается за финальный результат.

2. После создания я читаю запись обратно

Ответ на POST уже содержит данные созданного объекта, но для критичных полей мне спокойнее сделать отдельный запрос к конкретному post ID в контексте редактирования. Это не доказывает идеальное отображение каждой строки в редакторе, зато подтверждает, что объект действительно доступен WordPress и имеет ожидаемые поля.

Мой минимальный набор проверки:

• status равен draft — статья не опубликована;
• в categories есть 73 — запись не ушла в «Без рубрики»;
• featured_media равен ID только что загруженной обложки;
• возвращён post ID, по которому открывается экран редактирования.

3. Журнал темы обновляется только после подтверждения WordPress

Здесь важен порядок. Если сначала записать тему в локальную историю, а затем получить ошибку WordPress, следующий запуск решит, что статья уже существует, хотя черновика нет. Поэтому строка в журнале — последняя фиксация результата, а не обещание результата. Об этом принципе я уже писал отдельно; теперь стало понятнее, почему он связан именно с двухэтапной записью через REST API.

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

Частые вопросы (FAQ)

Почему не отправлять картинку и статью одним запросом?

Стандартный WordPress REST API работает с медиа и постами как с отдельными ресурсами. Сначала нужно получить ID вложения, чтобы затем передать его в поле featured_media записи.

Достаточно ли проверить HTTP-код 201?

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

Что происходит с картинкой, если создание поста не удалось?

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

Почему не публиковать автоматически после всех проверок?

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

Итог

Главное изменение в моём мышлении простое: «запрос выполнился» и «черновик готов к проверке» — разные утверждения. Готовым результатом я считаю только тот пост, который WordPress вернул по конкретному ID со статусом draft, категорией 73 и ожидаемым featured_media. Всё до этого — промежуточное состояние, даже если половина лога уже зелёная.

---

Автор: Denis | Дата: 20 октября 2026 | Обновлено: 20 октября 2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках