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.
Зворотний бік медалі: Про що варто знати?
Звісно, цей підхід не є “срібною кулею” і має свої складнощі:
- Втрата “WYSIWYG”: Ви більше не можете просто встановити тему, налаштувати її в кастомайзері і побачити результат. Функція “Попередній перегляд” перестає працювати.
- Складність для клієнта: Клієнту доведеться звикнути, що зміни в адмінці не завжди миттєво відображаються на сайті (якщо використовується статична генерація, потрібен час на “перезбірку” сайту).
- Плагіни: Багато плагінів WP, особливо ті, що працюють з фронт-ендом (форми, слайдери), стають марними. Вам доведеться реалізовувати цей функціонал на боці фронт-енду.
- 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.
Це дуже легко виправити. Є два шляхи:
- Встановити плагін “ACF to REST API”.
- (Мій улюблений спосіб) Додати кілька рядків коду у файл
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. Це часто є навіть кращим рішенням для складних додатків, оскільки зменшує кількість запитів до сервера.
Висновок: це не заміна, а розширення можливостей
На мою думку, Headless WP — це не “вбивця” традиційних тем. Це паралельна гілка еволюції. Це потужний професійний інструмент, який перетворює WordPress зі “системи для блогів” на повноцінний, гнучкий бек-енд для сучасних веб-додатків.
Якщо ваш клієнт хоче просто сайт-візитку, традиційна тема — ваш вибір. Але якщо вам потрібен блискавичний статичний сайт, мобільний додаток та гнучкість у виборі технологій — подивіться в бік Headless WP. Це може бути саме тим рішенням, яке ви шукали.