WordPress як Headless CMS 🧠 | практично з REST API

WordPress роками був неперевершеним “монолітом”: він відповідав і за зручну адмін-панель, і за збереження даних, і за їх відображення на сайті через теми та шаблони. Але веб не стоїть на місці. З появою потужних JS-фреймворків (React, Vue, Svelte) та мобільних додатків виникла потреба “відв’язати” фронт-енд від бек-енду.

Цей підхід називається Headless CMS (або “безголова” CMS). Ідея полягає в тому, що WordPress використовується лише як зручний інтерфейс для керування контентом, а сам контент він віддає не у вигляді HTML-сторінок, а у вигляді “чистих” даних у форматі JSON. А вже інший, абсолютно незалежний додаток (фронт-енд), ці дані забирає та відображає.

 

Чому це взагалі потрібно? Переваги Headless-підходу

Навіщо ускладнювати, запитаєте ви? Зі свого досвіду можу сказати, що для багатьох проєктів переваги просто колосальні:

• 🚀 Неймовірна швидкість: Фронт-енд можна побудувати як статичний сайт (SSG) або SPA. Такі сайти завантажуються миттєво, оскільки не потребують генерації сторінок на боці сервера при кожному запиті.
• 🔧 Технологічна гнучкість: Ви не прив’язані до PHP та екосистеми тем WordPress. Хочете фронт-енд на React/Next.js, Vue/NuxtJS, чи Svelte? Будь ласка.
• 📱 Омніканальність: Ви керуєте контентом в одному місці (адмінка WP), а віддаєте його одночасно на веб-сайт, в мобільний додаток (iOS/Android) та на розумний годинник.
• 🔒 Підвищена безпека: Ваш фронт-енд може бути просто набором статичних файлів, які майже неможливо зламати. Адмінка WP при цьому може бути захована на окремому піддомені та закрита від сторонніх.
• 🧑‍💻 Комфорт для розробників: Сучасні JS-розробники обожнюють свої інструменти, і Headless-підхід дозволяє їм працювати у звичному середовищі, не занурюючись у тонкощі WP Theme Development.

 

Зворотний бік медалі: Про що варто знати?

Звісно, цей підхід не є “срібною кулею” і має свої складнощі:

1. Втрата “WYSIWYG”: Ви більше не можете просто встановити тему, налаштувати її в кастомайзері і побачити результат. Функція “Попередній перегляд” перестає працювати.
2. Складність для клієнта: Клієнту доведеться звикнути, що зміни в адмінці не завжди миттєво відображаються на сайті (якщо використовується статична генерація, потрібен час на “перезбірку” сайту).
3. Плагіни: Багато плагінів WP, особливо ті, що працюють з фронт-ендом (форми, слайдери), стають марними. Вам доведеться реалізовувати цей функціонал на боці фронт-енду.
4. SEO: Якщо ви будуєте SPA, вам потрібно подбати про серверний рендеринг (SSR) або статичну генерацію (SSG), інакше пошукові роботи не побачать ваш контент.

 

Ключ до всього: вбудований WordPress REST API

З версії 4.7 WordPress має вбудований REST API. Це і є той самий “чорний хід”, який дозволяє нам отримувати дані. Просто додайте /wp-json/wp/v2/ до адреси вашого сайту, і ви побачите його в дії.

Наприклад, щоб отримати список ваших останніх постів у форматі JSON, просто перейдіть за адресою:

https://example.com/wp-json/wp/v2/posts

Щоб отримати конкретний пост з ID 123:

https://example.com/wp-json/wp/v2/posts/123

А щоб отримати сторінки:

https://example.com/wp-json/wp/v2/pages

 

Ви отримаєте структуровані дані, готові для використання у будь-якому додатку.

 

Практичний крок: витягуємо кастомні поля (ACF)

Стандартні поля (заголовок, контент) — це добре, але справжня магія WP як CMS — це кастомні поля, наприклад, створені за допомогою плагіна Advanced Custom Fields (ACF). Проблема в тому, що за замовчуванням ACF не показує свої дані в REST API.

Це дуже легко виправити. Є два шляхи:

1. Встановити плагін “ACF to REST API”.
2. (Мій улюблений спосіб) Додати кілька рядків коду у файл functions.php вашої теми. Це дає більше контролю.

Наприклад, щоб додати всі поля ACF до REST API для постів:

function add_acf_to_posts_api( $data, $post, $request ) {
    $data->data['acf'] = get_fields( $post->ID );
    return $data;
}
add_filter( 'rest_prepare_post', 'add_acf_to_posts_api', 10, 3 );

Цей простий хук каже: “Коли готуєш пост для API, додай до нього поле acf, в яке поклади всі значення з get_fields()“.

 

Приклад на боці фронт-енду (React/Next.js)

Тепер на боці вашого фронт-енд додатку (наприклад, написаного на Next.js) ви можете легко отримати ці дані:

// Приклад коду на JavaScript для отримання постів
import fetch from 'isomorphic-unfetch';
export async function getStaticProps() {
  // Робимо запит до нашого WP REST API
  const res = await fetch('https://your-wp-site.com/wp-json/wp/v2/posts');
  const posts = await res.json();
  // Повертаємо пости як props для нашої сторінки
  return {
    props: {
      posts,
    },
  };
}
// Компонент сторінки, який відображає пости
function Blog({ posts }) {
  return (
    <div>
      <h1>Мій блог</h1>
      <ul>
        {posts.map(post => (
          <li key={post.id}>
            <h2>{post.title.rendered}</h2>
            {/* А ось і наші кастомні поля ACF! */}
            <p>{post.acf.short_description}</p>
          </li>
        ))}
      </ul>
    </div>
  );
}
export default Blog;

Цей код згенерує статичну HTML-сторінку з вашими постами, яка буде завантажуватися миттєво.

 

А що з GraphQL?

Альтернативою REST API є GraphQL. Це мова запитів, яка дозволяє фронт-енду запросити тільки ті дані, які йому потрібні, одним запитом.

Для WP існує чудовий плагін WPGraphQL (також WPGraphQL for ACF), який надає потужне API на GraphQL. Це часто є навіть кращим рішенням для складних додатків, оскільки зменшує кількість запитів до сервера.

 

Висновок: це не заміна, а розширення можливостей