Блокова тема WordPress проти класичної: чесне порівняння

Відкрийте теку своєї теми. Якщо в ній є каталог templates з файлом index.html усередині плюс theme.json у корені — у вас блокова тема. Якщо там index.php поруч із файлами на кшталт header.php і footer.php, а бічна панель адмінки показує Appearance, а далі Customizer — у вас класична тема.

Ця єдина структурна різниця вирішує, хто і що може змінювати на сайті, де ці зміни зберігаються і яка половина екосистеми плагінів WordPress поводитиметься нормально.

Визначення за 30 секунд

Ознака	Класична тема	Блокова тема
Кореневий файл шаблону	index.php	templates/index.html
Шапка й підвал	header.php, footer.php	parts/header.html, parts/footer.html
Глобальна конфігурація	functions.php	theme.json (плюс необов’язковий functions.php)
Меню адмінки	Appearance > Customizer	Appearance > Editor
Де зберігаються правки	Файли на диску	База даних, як записи wp_template
Екран віджетів	Є	Немає

WordPress ухвалює рішення, шукаючи templates/index.html. Тема, яка постачає theme.json, але лишає свої PHP-шаблони, усе одно вважається класичною — цей проміжний стан поширений і має свою назву, про неї нижче.

Якщо у вас є доступ до консолі, усе вирішує одна команда:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI — найшвидша перевірка на сайті, який будували не ви, особливо коли конструктор сторінок сховав звичні пункти меню адмінки.

Що змінюється для того, хто редагує сайт

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

У блоковій темі Site Editor відкриває всю сторінку. Шапка, підвал, стрічка записів, сторінка 404, макет результатів пошуку — усе це блоки, і все це може редагувати людина, яка ніколи не бачила PHP. Це і є справжня головна перевага, і вона справді велика.

Ціна в тому, що все це може редагувати людина, яка ніколи не бачила PHP. Клієнт може видалити назву сайту з шапки о другій ночі, і на диску не буде історії версій, з якої це відновити, — лише власні ревізії Site Editor. Обмежити доступ можна: є блокування блоків і контроль над тим, хто взагалі потрапляє до редактора, але це робота, яку треба свідомо зробити.

Дві менші втрати, які болять на практиці: у блокових темах немає екрана Widgets (зони віджетів замінені частинами шаблонів і блоками), а класичні меню замінено блоком Navigation, який зберігає свої пункти як окремий тип вмісту, а не на звичному екрані меню.

Що змінюється для розробника

Класичні теми працюють на ієрархії PHP-шаблонів. WordPress розв’язує запит уздовж відомого ланцюжка — single-{post-type}.php, потім single.php, потім singular.php, потім index.php — і ваш файл виконується, викликає get_header(), проганяє цикл і друкує розмітку, яку ви контролюєте до символу.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Блокові теми використовують ті самі назви ієрархії, але з розширенням .html, а всередині файлу лежить блокова розмітка — HTML із роздільниками блоків у коментарях — і жодних шаблонних тегів:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Три наслідки, з якими розробники стикаються одразу:

get_header() і get_footer() не виконуються ніколи. Усе, що причеплено до цих дій у плагіні чи старій дочірній темі, мовчки не робить нічого. wp_head і wp_footer спрацьовують, тож більшість підключень скриптів виживає, а от специфічні для шапки хуки — ні.

База даних перемагає ваші файли. Щойно хтось зберігає шаблон у Site Editor, WordPress записує цю версію як запис wp_template і віддає її замість вашого файлу. Можна редагувати HTML-файл цілий день і не побачити на сайті жодної зміни. Скидання налаштувань для цього шаблону повертає версію з файлу. Це найпоширеніша скарга «моя блокова тема зламалася», і це не баг.

Стилізація переїжджає в theme.json. Кольори, шкала відступів, типографіка й значення за замовчуванням для окремих блоків оголошуються як дані, а не як CSS, і WordPress генерує CSS сам. Це чистіше й значно послідовніше — доки вам не знадобиться щось, чого схема не виражає, і тоді ви все одно пишете CSS і воюєте зі специфічністю згенерованих правил.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Звіряйте значення version із випуском WordPress, на якому ви працюєте: схему переглядали не раз, і скопійований зі старого посібника номер версії дає налаштування, які тихо ігноруються.

Зверніть увагу: functions.php нікуди не зникає. Блокові теми досі використовують його для підключення ресурсів, реєстрації записів add_image_size, власних типів записів і всього іншого на PHP. Просто шаблонів ви пишете там значно менше.

Що ви справді отримуєте і що справді втрачаєте

Перехід на блоки дає: контроль над усією сторінкою прямо з редактора, узгодженість дизайну, яку тримає theme.json, менше файлів у супроводі й стилі, які збігаються між редактором і сайтом набагато частіше, ніж це вдавалося класичним темам.

Перехід на блоки забирає: прямий контроль над вихідною розміткою, просту кастомізацію через хуки, сумісність із усім, що розраховує на PHP-шаблони, і впевненість у тому, що зовнішній вигляд сайту лежить у системі контролю версій.

Останній пункт заслуговує наголосу. У класичній темі git log каже вам, що змінилося. У блоковій відчутна частка вигляду сайту живе в базі даних, куди ваш деплой-пайплайн навіть не заглядає.

Коли класична тема — досі правильна відповідь

• Сайтом керує конструктор сторінок. Elementor, Divi, Beaver Builder і подібні інструменти беруть шаблонізацію на себе. Блокова тема під ними — це друга система шаблонів, яка не робить нічого.
• Розмітка має бути точною. Власні бібліотеки компонентів, сувора розмітка для доступності, нетипові вимоги до мікророзмітки — вивід блоків обмежений тим, що блоки вміють видавати, і боротьба з цим коштує дорожче, ніж написати PHP.
• Багато шаблонів від плагінів. Плагіни для членства, LMS, каталогів і старіші комерційні розширення часто постачають перевизначення PHP-шаблонів. Багато з них уже мають блокові аналоги, багато — ні.
• Сайт готовий і працює. У теми з п’ятьма роками накопичених доробок немає шляху оновлення до блокової — тільки перебудова. «Це новіший підхід» не є бізнес-аргументом.
• Крім вас, його ніхто не редагуватиме. Головна користь Site Editor — передати контроль людям без досвіду розробки. Якщо таких людей немає, ви платите за перевагу, якою ніхто не користується.

Гібридна золота середина

Класична тема може додати theme.json і отримати систему глобальних стилів, пресети кольорів та відступів і узгоджену стилізацію в редакторі — зберігши при цьому свої PHP-шаблони й Customizer. WordPress не вважатиме таку тему блоковою, і Site Editor лишиться недоступним, але більшість користі від дизайн-системи ви отримаєте за частку зусиль.

Для наявного сайту, який здебільшого працює, це зазвичай і є правильний перший крок. Додайте theme.json, опишіть палітру й відступи, видаліть CSS, який вони замінюють, — і подивіться, чи захочеться вам решта.