Получить название текущего шаблона страницы в эпоху Гутенберга

Вопрос или проблема

В блоковой теме я хотел бы иметь возможность вносить некоторые изменения в мета-данные заголовка в зависимости от используемого шаблона страниц (на основе блоков). Традиционная функция get_page_template() не работает так, как ожидалось в этом случае (я получаю возврат wp-includes/template-canvas.php). У нас сейчас есть способ узнать, какой блоковый шаблон страниц может быть назначен записи/странице? (Или мне нужно делать что-то вроде парсинга классов тела или что-то в этом роде?)

Думаю, я немного опоздал, но get_page_template_slug() может дать вам то, что вы ищете. Он возвращает строку, содержащую имя шаблона страницы, а не его URL. При работе с полным редактированием сайта файл может не существовать, но он все равно возвращает slug.

К сожалению, прошло уже 3 года, и этот вопрос все еще не имеет удовлетворительного ответа.

На момент написания, 2025-03-16, последняя версия WordPress — 6.7.2.

Лучшее, что мы можем сделать, это использовать глобальную переменную PHP $_wp_current_template_id, которая содержит значение, похожее на <название темы>//<slug шаблона>.

Будем надеяться, что в будущих версиях WP будет предоставлена надлежащая функция для получения этой информации, но до тех пор это то, с чем нам нужно работать.

Ответ или решение

В эпоху Гутенберга и полной редакции сайта вопросы, связанные с определением текущего шаблона страницы, становятся все более актуальными, особенно для разработчиков, стремящихся реализовать специфические изменения в meta-данных заголовка на основе используемого шаблона. Итак, давайте разберемся, как можно получить название текущего шаблона страницы в контексте блочных тем и полной редакции сайта.

Теория

С появлением редактора Гутенберг и переходом к полной редакции сайта подход к структуре и обработке шаблонов страниц претерпел значительные изменения. В традиционной архитектуре WordPress функции, такие как get_page_template(), позволяли легко определить путь к файлу шаблона, использованного для отображения страницы. Однако, в новом блоковом подходе, эта функция может вернуть путь к wp-includes/template-canvas.php, поскольку оказывается, что фактическое управление шаблонами переместилось из статических PHP-файлов в JSON-файлы конфигурации внутри тем.

Сегодня WordPress предоставляет несколько методов и способов для анализа текущих шаблонов, но большинство из них ориентированы больше на разработчиков и требуют знания внутренней структуры CMS.

Примеры

Использование get_page_template_slug():
Эта функция возвращает слаг шаблона страницы. Это важно, поскольку в условиях полной редакции сайта файловое представление шаблона может и не существовать, однако слаг будет указан. Это позволяет разработчику получать идентификатор шаблона и использовать его в логике приложения.
Глобальная переменная $_wp_current_template_id:
Это текущее лучшее решение для определения ID текущего шаблона в контексте блоковых тем. Оно возвращает строку вида "<название темы>//<слаг шаблона>", которая помогает узнать, какой именно шаблон используется в данный момент. Хотя это может не быть идеальным решением, этот метод позволяет получить нужные данные и адаптировать работу сайта на их основе.
Анализ классов тела страницы:
В экстренных случаях можно провести парсинг классов тела страницы (body classes), чтобы попытаться идентифицировать используемый шаблон. Этот способ требует дополнительных усилий по обработке HTML и может быть менее производительным.

Применение

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

global $_wp_current_template_id;

if ($_wp_current_template_id) {
    list($theme, $template_slug) = explode('//', $_wp_current_template_id);

    // Ваш код для изменения meta-заголовков или других данных
    if ($template_slug === 'custom-template') {
        // Применить специфичные meta или скрипты
    }
}

Это позволяет создавать более адаптивные и контекстуальные сайты, которые реагируют соответствующим образом на используемый шаблон.

Заключение

Сложность работы с шаблонами в условии полной редакции сайта требует глубокого понимания как старой, так и новой архитектуры WordPress. Переход к блочным темам безусловно вынуждает разработчиков пересматривать устоявшиеся методы, но также открывает широкие горизонты для создания более динамичных и персонализированных веб-сайтов. В конечном итоге, совершенствование CMS в будущем должно привести к появлению более прямолинейных методов определения текущего шаблона, что лишь укрепит возможности и удобство работы с WordPress в эпоху Гутенберг.