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

Откройте папку темы. Есть каталог templates с index.html внутри и theme.json в корне — у вас блочная тема. Есть index.php рядом с header.php и footer.php, а в боковом меню админки — «Внешний вид → Настройщик» — классическая.

Эта единственная разница в структуре определяет, кто и что может менять на сайте, где эти изменения хранятся и какая половина экосистемы плагинов WordPress будет вести себя нормально.

Опознание за 30 секунд

Признак	Классическая тема	Блочная тема
Корневой файл шаблона	index.php	templates/index.html
Шапка и подвал	header.php, footer.php	parts/header.html, parts/footer.html
Глобальная конфигурация	functions.php	theme.json (плюс необязательный functions.php)
Меню админки	Внешний вид → Настройщик	Внешний вид → Редактор
Где сохраняются правки	В файлах на диске	В базе данных, как записи wp_template
Экран виджетов	Есть	Нет

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

Если есть доступ к консоли, вопрос закрывает одна команда:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI — самая быстрая проверка на чужом сайте, особенно когда конструктор страниц спрятал привычные пункты меню.

Что меняется для того, кто правит сайт

В классической теме шапка, подвал, сайдбар, цвета и логотип живут в настройщике, и вам доступны только те элементы управления, которые решил сделать автор темы. Не завёл он поле для текста копирайта в подвале — поля нет. Либо правите PHP-файл, либо смиряетесь.

В блочной теме редактор сайта открывает всю страницу целиком. Шапка, подвал, цикл вывода записей, страница 404, вёрстка результатов поиска — всё это блоки, и всё это может править человек, который никогда не видел PHP. Это и есть главная возможность, и она действительно большая.

Плата за неё в том, что всё это может править человек, который никогда не видел PHP. Клиент способен удалить название сайта из шапки в два часа ночи, и восстанавливать будет не из чего — истории версий на диске нет, есть только ревизии самого редактора сайта. Закрутить гайки можно: есть блокировка блоков и ограничение доступа к редактору, но это работа, которую нужно не забыть сделать.

Две потери поменьше, но заметные на практике: у блочных тем нет экрана виджетов (области виджетов заменены частями шаблонов и блоками), а классические меню заменены блоком «Навигация», который хранит пункты как отдельный тип содержимого, а не на привычном экране меню.

Что меняется для разработчика

Классические темы используют иерархию 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 по-прежнему срабатывают, поэтому подключение скриптов и стилей в основном выживает, а вот хуки, специфичные для шапки, — нет.

База данных сильнее ваших файлов. Как только кто-то сохранил шаблон в редакторе сайта, WordPress хранит эту версию как запись wp_template и отдаёт её вместо вашего файла. Можно править HTML-файл весь день и не увидеть на сайте ни малейшего изменения. Сброс пользовательских изменений для этого шаблона возвращает версию из файла. Это самое частое сообщение «блочная тема сломалась», и это не баг.

Оформление переезжает в theme.json. Цвета, шкала отступов, типографика и значения по умолчанию для блоков объявляются как данные, а не как CSS, и CSS генерирует WordPress. Так чище и заметно последовательнее — ровно до момента, когда вам нужно то, чего схема не выражает: тогда вы всё равно пишете 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-шаблонов. У многих уже есть блочные аналоги, у многих — нет.
• Сайт готов и работает. У темы с пятью годами накопленных доработок нет пути обновления до блочной — есть только пересборка. «Это более современный подход» — не бизнес-аргумент.
• Кроме вас его никто не правит. Главная польза редактора сайта — передать контроль людям без навыков разработки. Если таких людей нет, вы платите издержки за возможность, которой никто не пользуется.

Гибридная середина

Классическая тема может добавить theme.json и получить систему глобальных стилей, пресеты цветов и отступов и единообразное оформление в редакторе — сохранив при этом PHP-шаблоны и настройщик. Блочной темой WordPress её не считает, редактор сайта останется недоступен, но большую часть выгоды от дизайн-системы вы получите малой кровью.

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