Четыре CMS - один интерфейс публикации: WordPress, 1С-Битрикс, InSales и Joomla
Полгода назад я разрабатывал сервис автоматического наполнения сайта контентом: система генерировала статьи и размещала их на ресурсах клиентов. Изначально казалось, что самое трудное - подготовить качественный текст. Публикация представлялась простой технической операцией: отправить данные через REST API и получить готовую страницу.
На практике всё оказалось наоборот. Генерация статьи сводится к вызову языковой модели и обработке её ответа. А корректное размещение материала требует учитывать изображения, категории, статусы, SEO-поля, форматы запросов и особенности конкретной CMS. В результате интеграция WordPress 1С-Битрикс InSales Joomla превратилась в отдельное исследование.
Главный вывод оказался простым: три системы позволяют передавать публикации по HTTP, а для 1С-Битрикс приходится добавлять на сайт собственный код. При этом внешний интерфейс можно сохранить единым - если заранее принять, что у разных CMS различаются не только названия полей, но и сама логика публикации.
Общая модель публикации
Все четыре платформы скрыты за единым абстрактным классом. Сервис генерации не должен знать, куда именно отправляется статья: в WordPress, интернет-магазин InSales или сайт на Joomla. Он работает с общей моделью материала - заголовком, содержимым, категорией, SEO-мета-данными и изображением.
Однако полностью одинаковым такой контракт быть не может. Например, обложка в WordPress сначала загружается в медиабиблиотеку отдельным запросом. После этого в запись передаётся идентификатор изображения. В Битриксе аналогичного REST-хранилища медиафайлов нет, поэтому изображение приходится отправлять байтами одновременно с материалом.
Поэтому в общей модели разумно предусмотреть два поля: `featured_media_id` для систем, где картинка уже существует в медиабиблиотеке, и `cover_image_bytes` для CMS, принимающих файл непосредственно вместе со статьёй. Попытка скрыть это различие за одним универсальным параметром только усложняет реализацию.
Та же проблема возникает со статусами. В WordPress черновик обозначается значением `status: "draft"`, в Joomla используется `state: 0`, а в InSales отдельной сущности черновика нет. Это не мелкие различия синтаксиса, а разные подходы к жизненному циклу публикации.
WordPress: наиболее предсказуемый вариант
WordPress можно считать эталоном для такой интеграции. Публикационный модуль получается компактным: по сути, это тонкая оболочка над HTTP-клиентом. Авторизация выполняется через Application Password - пользователь создаёт специальный пароль в профиле, после чего запросы отправляются с обычной Basic Auth поверх HTTPS.
Создание записи выполняется POST-запросом к `/wp-json/wp/v2/posts`. В ответ API возвращает идентификатор публикации и ссылку на страницу. Черновик задаётся стандартным параметром:
```json
{
"status": "draft"
}
```
Сложности начинаются при работе с SEO. Yoast SEO, Rank Math и SEOPress используют разные мета-ключи для заголовка и описания, а заранее определить установленный плагин удаётся не всегда. Практичным решением становится передача сразу нескольких вариантов ключей. Неизвестные поля WordPress обычно игнорирует, поэтому поддерживаемые расширением значения применяются, а остальные не мешают созданию записи.
Именно на примере WordPress хорошо видно, каким должен быть API публикации контента для CMS: понятная авторизация, предсказуемая структура ответа и отдельные операции для медиафайлов и записей.
InSales: публикация через дату
InSales создавалась прежде всего как платформа для интернет-магазинов, поэтому блоговые возможности здесь вторичны. API в целом работает последовательно, но модель статусов отличается от привычной.
У статьи нет отдельного состояния "черновик". При этом параметр `published_at` обязателен. Документация описывает следующее поведение: материал остаётся невидимым для пользователей, если дата публикации находится в будущем.
Следовательно, для имитации черновика необходимо передать дату, которая наступит значительно позже текущего момента. Это выглядит как обходной путь, но именно так устроена штатная логика InSales. Если же отправить текущую дату и рассчитывать на несуществующий флаг черновика, статья станет доступна посетителям сразу после сохранения.
Обложка также загружается отдельно. Сначала файл передаётся на `/admin/files.json` в формате Base64 внутри JSON. Сервер возвращает `absolute_url`, после чего полученный адрес добавляется в тело статьи. Таким образом, публикационный сценарий состоит минимум из двух последовательных операций: загрузки изображения и создания материала.
Joomla: успешный запрос с неуспешным результатом
Начиная с четвёртой версии Joomla предоставляет полноценный REST API с токенами. На бумаге это удобная схема, однако в реальной эксплуатации система оказалась самой капризной из четырёх.
Одна из первых проблем связана с маршрутом API. В документации часто указан короткий путь, который работает на локальной установке или сервере с определённой конфигурацией. На виртуальном хостинге запрос может завершаться ошибкой, если сервер не настроен на соответствующую маршрутизацию. Иногда приходится использовать полный путь с дополнительным префиксом, зависящим от настроек Joomla и веб-сервера.
Отдельная неприятность - несоответствие между HTTP-ошибкой и фактическим результатом операции. Joomla может вернуть ошибку, хотя запись уже создана. Если клиент автоматически повторит запрос, появляется дубль. Поэтому после неоднозначного ответа важно не только повторять операцию, но и проверять, существует ли материал с тем же `alias`, заголовком или другим уникальным признаком.
Сложности вызывает и `alias`. Joomla требует уникального адресного идентификатора статьи. Кириллический заголовок может быть преобразован в транслитерацию, а повторная публикация материала с тем же названием приведёт к коллизии. Надёжнее формировать alias самостоятельно, нормализовать символы и добавлять суффикс при совпадении.
Ещё одна особенность - разделение API на разные способы работы. В одном сценарии данные передаются как JSON, в другом требуется форма с multipart-кодированием. Внешне операции похожи, но поля и формат тела запроса отличаются. Универсальный клиент приходится настраивать отдельно для каждого действия.
1С-Битрикс: публикация без штатного API
Самая сложная часть интеграции связана с 1С-Битрикс. У платформы есть обширный API для внутреннего PHP-кода, но полноценного публичного REST-интерфейса для создания обычных элементов инфоблока в нужном виде фактически нет.
Поэтому стандартная архитектура здесь не работает. Чтобы добавить публикацию, на сайте приходится разместить собственный обработчик. Сервис отправляет ему структурированные данные и изображение, а PHP-код уже вызывает внутренние классы Битрикса, создаёт элемент инфоблока, сохраняет файл и возвращает результат.
Есть и дополнительная проблема: после создания элемента API может не вернуть идентификатор так, как ожидает клиент. В ряде сценариев запись создаётся, но ответ содержит пустое или неоднозначное значение. Это вынуждает проверять результат отдельным запросом - например, искать элемент по символьному коду или заголовку.
Особое внимание необходимо уделить полю `CODE`. Битрикс способен автоматически генерировать символьный код из названия, менять его при сохранении и учитывать настройки транслитерации. Если код формируется на стороне клиента, его следует явно передавать и затем проверять в базе.
SEO-поля тоже не всегда ведут себя очевидно. Один участок кода записывает значения в пользовательские поля, другой читает их из настроек инфоблока или шаблона. Поэтому интеграцию нельзя строить только вокруг названий полей: нужно заранее определить, где именно шаблон сайта получает SEO-заголовок и описание.
Для проектов на Битриксе такой подход фактически превращает собственный обработчик в промежуточный шлюз. Это повышает объём сопровождения, зато позволяет сохранить единый интерфейс управления публикациями CMS для всех подключённых платформ.
Надёжность важнее количества запросов
Автоматическая публикация статей на сайт должна учитывать не только успешный ответ сервера, но и идемпотентность операций. Если соединение оборвалось после создания записи, повторная отправка не должна создавать дубликат. Для этого полезно передавать внешний идентификатор материала или заранее рассчитывать уникальный alias.
Желательно разделять этапы публикации: сначала загрузить изображение, затем создать запись, после этого проверить итоговый URL и состояние материала. При ошибке на последнем этапе не нужно бездумно повторять всю цепочку - сначала следует выяснить, какая операция уже завершилась.
Также стоит вести журнал публикаций. В нём полезно сохранять CMS, внешний идентификатор, статус, сформированный alias, URL изображения и текст ответа сервера. Такая информация значительно сокращает время диагностики, особенно когда ошибка появляется уже после фактического создания статьи.
В перспективе сервис можно дополнить очередью задач и повторными попытками с увеличивающейся задержкой. Однако повторять следует только безопасные операции. Для Joomla и Битрикса обязательна дополнительная проверка результата, поскольку сервер может сообщить об ошибке после успешной записи.
В итоге единый публикационный слой вполне реален, но он не должен притворяться, будто все CMS одинаковы. WordPress предлагает прямой и понятный REST-сценарий, InSales заменяет черновики датой, Joomla требует осторожной проверки результатов, а 1С-Битрикс вынуждает устанавливать собственный серверный обработчик. Именно учёт этих различий делает интеграцию устойчивой, а не просто работоспособной в демонстрационном примере.