Обобщённый технический кейс
WordPress как API для отдельного frontend
В нескольких новых контентных проектах frontend создавался отдельно на Next.js, а редакторам требовалась привычная WordPress-админка. Нужно было сделать так, чтобы контент, каталоги и страницы редактировались без кода, а frontend получал предсказуемые структурированные данные.
Контекст
Это обобщённый технический кейс на основе нескольких новых контентных проектов. Frontend разрабатывался отдельными специалистами на Next.js, а я отвечал за WordPress-админку, структуру контента, REST API и взаимодействие с frontend-командой.
Моя роль
Я проектировал CMS-часть: типы контента, блоки ACF, правила редактирования и API-выдачу. Также реализовал JWT-авторизацию для защищённых сценариев и подготовил описание endpoint, параметров запросов и примеров ответов.
Требования к платформе
- 01
Редакторы должны были собирать и обновлять страницы в админке, не меняя код frontend-приложения.
- 02
Страницы состояли из самостоятельных секций, поэтому модель «отдельное поле для каждого фрагмента» была неудобной и плохо масштабировалась.
- 03
Стандартная отдача ACF не всегда возвращала связанные сущности в пригодном для frontend виде: в некоторых сценариях приходили только идентификаторы.
- 04
Frontend-команде требовался стабильный и документированный формат данных, чтобы интерфейс не зависел от внутренних особенностей WordPress и ACF.
Ключевые решения
Вместо того чтобы приспосабливать отдельный frontend к сырой выдаче CMS, я сделал WordPress источником заранее структурированных данных: контент строится из блоков, а API возвращает их в согласованном формате.
WordPress как контентный backend
WordPress использовался не для вывода страниц посетителю, а как удобная административная система. Редакторы работают с привычной CMS, а Next.js отвечает за интерфейс, анимации и скорость отдельного frontend.
Контентная модель на ACF Blocks
Каждая визуальная секция страницы оформлялась как отдельный блок. Из готовых блоков можно быстро собирать разные страницы, сохраняя единый дизайн и не создавая набор полей заново для каждого сценария.
Структурированная выдача в REST API
В стандартные WordPress endpoint был добавлен отдельный ключ с подготовленным списком блоков и их содержимым. Связанные данные приводились к объектной структуре, удобной для использования во frontend.
JWT для защищённых сценариев
Для сценариев с авторизацией — например, доступа к личному кабинету или покупкам — было реализовано отдельное JWT-решение, которое позволяло frontend-приложению работать с защищёнными запросами.
Документация для команды
Frontend-команда получила описание endpoint, параметров запросов и примеры ответов. Это снижало количество ручных уточнений и позволяло согласованно развивать CMS и интерфейс.
Главная техническая сложность
Главная сложность состояла в том, чтобы превратить гибкие редакторские блоки WordPress в предсказуемый JSON-контракт. Стандартная выдача ACF не всегда содержала связанные сущности в нужном виде, поэтому данные блоков и связей пришлось целенаправленно преобразовывать для REST API.
Результат
Редакторы управляют страницами и контентом через WordPress, а отдельный frontend получает понятный API-контракт с готовой структурой блоков и данных.
Что изменилось
- Редакторы получили гибкую блочную систему: страницы можно собирать и обновлять в WordPress без правки frontend-кода.
- Frontend-команда получила единый документированный формат данных вместо необходимости разбираться с внутренним устройством ACF и WordPress.
- Контентные разделы, каталоги и страницы можно развивать независимо от визуальной реализации отдельного frontend.
- Защищённые пользовательские сценарии можно подключать через JWT-авторизацию без отказа от WordPress как CMS.
Связанные услуги
В этом проекте пересеклись несколько направлений работы.
Описание кейса обезличено: не содержит названий компаний, ссылок на закрытые системы, доступов и внутренних коммерческих данных.