Headless WordPress: зв'язка із зовнішнім фронтендом

Headless WordPress — це схема, за якої WordPress лишається лише сховищем контенту і панеллю для редакторів, а сторінки відвідувачам показує окремий фронтенд-застосунок на React, Vue чи Next.js. WordPress віддає дані через API, фронтенд їх запитує і малює за власними шаблонами. Розберемо, коли така схема виправдана і як зібрати зв'язку без втрати швидкості.

Коли потрібен headless, а коли — звичайна тема

Headless-схема виправдана, якщо у проєкту вже є команда фронтенд-розробників, потрібна єдина кодова база для сайту і мобільного застосунку, або контент потрібно показувати в кількох каналах одразу — на сайті, у застосунку, у віджеті партнера. Якщо завдання — звичайний сайт-візитка чи блог, класична тема WordPress із кешуванням обійдеться дешевше і надійніше.

Мінус headless-підходу — подвійна інфраструктура: потрібно підтримувати і WordPress, і окремий фронтенд-сервер чи статичний хостинг для збірки.

Як WordPress віддає дані фронтенду

Основний канал — вбудований REST API WordPress, який віддає записи і сторінки за адресами виду /wp-json/wp/v2/posts. Для складних вибірок із вкладеними зв'язками (запис, автор, категорії і медіа одним запитом) багато проєктів ставлять плагін WPGraphQL — він додає ендпоінт /graphql із гнучкими запитами замість десятка окремих REST-викликів.

curl -s https://site.example/wp-json/wp/v2/posts?per_page=5&_embed=1

Параметр _embed=1 підвантажує автора, категорії і обкладинку запису в одній відповіді — без нього фронтенду довелося б робити окремий запит на кожну пов'язану сутність.

Приклад запиту даних у фронтенд-застосунку

З боку Next.js запит до REST API виглядає як звичайний fetch на етапі збірки сторінки.

export async function getStaticProps() {
  const res = await fetch('https://site.example/wp-json/wp/v2/posts?_embed=1');
  const posts = await res.json();
  return { props: { posts }, revalidate: 60 };
}

Опція revalidate: 60 вмикає інкрементальну регенерацію: сторінка перезбирається не частіше разу в 60 секунд, а не при кожному заході відвідувача.

Як оновлювати фронтенд після публікації запису

Чекати планову перезбірку не завжди зручно — редактор чекає, що матеріал з'явиться одразу після натискання «Опублікувати». Рішення — вебхук: хук WordPress publish_post смикає URL перезбірки на боці фронтенда.

<?php
add_action('publish_post', function ($post_id) {
    wp_remote_post('https://frontend.example/api/revalidate', array(
        'body' => array('secret' => 'REPLACE_WITH_TOKEN', 'post_id' => $post_id),
        'timeout' => 5,
    ));
});

Секретний токен у тілі запиту потрібен, щоб сторонні не могли викликати перезбірку за власним бажанням і створювати зайве навантаження.

Headless і класичний WordPress: порівняння

Часті проблеми зв'язки

CORS-помилки в консолі браузера означають, що REST API не дозволяє запити з домену фронтенда — додайте заголовок Access-Control-Allow-Origin через фільтр rest_pre_serve_request. Довгі відповіді API на сайті з великою кількістю записів зазвичай лікує об'єктний кеш — подробиці в статті про Redis-кеш для WordPress. Автоматизувати перевірку і очищення кешу під час деплою зручно скриптом на базі WP-CLI.

Чек-лист перед запуском headless-проєкту

• Визначено зв'язку API: чистий REST API або додатково WPGraphQL для складних вибірок.
• Налаштовано вебхук перезбірки фронтенда під час публікації і оновлення записів.
• Додано режим попереднього перегляду чернеток для редакторів до публікації.
• Налаштовано заголовки CORS для домену фронтенда.
• Об'єктний кеш на боці WordPress знижує навантаження від частих запитів API.