В современных фреймворках Astro и Next.js часто используется маршрутизация по файлам (file-based routing): адрес страницы определяется структурой файлов в проекте. Это удобно для разработки, потому что связь между адресом, кодом и содержимым страницы становится предсказуемой.
В WordPress похожий подход можно использовать без полного перехода на блочную тему и редактор сайта (Full Site Editing, FSE). Для этого достаточно добавить отдельный шаблон страницы и подключать к нему файлы с разметкой из темы.
Суть подхода:
- создается специальный шаблон страницы
Code Driven; - для страниц с этим шаблоном WordPress ищет файл с содержимым в каталоге
patterns/pages/...; - адрес страницы сопоставляется с путем к файлу по заранее заданным правилам;
- если подходящий файл не найден, WordPress показывает обычное содержимое страницы через
the_content().
Так появляется управляемый слой разработки страниц из кода. Он работает поверх классической темы и не меняет поведение остальных страниц сайта.
Назначение и цели
Такой способ полезен, когда страницу сначала удобнее собрать как технический прототип в файлах, а уже после стабилизации передать в обычное редактирование через WordPress.
Типовой сценарий:
- разработчик или ИИ-агент быстро собирает первую версию страницы в файлах темы;
- структура, блоки, секции и маршруты проходят несколько итераций;
- изменения проверяются через систему контроля версий;
- неудачные версии можно быстро откатить;
- после утверждения страница переносится в режим обычного редактирования через админку WordPress;
- редакторы дальше меняют текст и простое содержимое без участия разработчика.
Для быстрой сборки и верстки страниц можно использовать Tailwind CSS и библиотеку готовых компонентов DaisyUI. Все это вместе с ИИ агентами типа Claude Code, OpenAI Codex, OpenCode, OpenClaw и т д
Составляющие и особенности
1. Четкая область применения
Механика работает только на страницах, где выбран шаблон Code Driven. Остальные страницы, записи, архивы и шаблоны темы не затрагиваются.
Это снижает риск скрытых изменений на сайте: новая логика включается только там, где ее явно выбрали.
2. Отдельный шаблон страницы
В теме создается отдельный шаблон страницы:
wp/wp-content/themes/app/templates/code-driven.php
Он определяет, когда нужно брать содержимое из файла, а когда оставить стандартный вывод WordPress через the_content().
3. Роутер файлов страниц
За поиск подходящего файла отвечает отдельный роутер:
wp/wp-content/themes/app/includes/PagePatternRouter.php
Он сопоставляет адрес страницы с файлом в теме и возвращает найденный вариант. Благодаря этому правила поиска можно отдельно тестировать, логировать и дорабатывать.
4. Файлы с содержимым страниц
Сами страницы хранятся в каталоге:
wp/wp-content/themes/app/patterns/pages/**/*.php
В этих файлах можно держать разметку блоков WordPress, секции лендингов, промо-страницы и другие элементы, которые удобнее сначала собрать в коде.
5. Маршрутизация по файлам
Адрес страницы можно сопоставлять с файлом в теме. Например, страница /hello-world/ может брать содержимое из файла:
patterns/pages/hello-world.php
А вложенная страница /hello-world/test/ — из файла:
patterns/pages/hello-world/test.php
Такой подход напоминает маршрутизацию по файлам (file-based routing) в Astro и Next.js, но остается внутри архитектуры WordPress.
6. Безопасный резервный вариант
Если файл не найден, страница не ломается. WordPress просто выводит обычное содержимое страницы из редактора.
Это важно для продакшена: отсутствие файла не должно приводить к пустой странице или критической ошибке.
7. Явная архитектура без скрытых подмен
Ключевой принцип: логика поиска и вывода файла находится в отдельном подключаемом файле, а решение о применении этой логики остается в шаблоне страницы.
Так поведение проще читать, тестировать и отключать. При этом не требуется глобально подменять содержимое через фильтр the_content.
Как работает поиск файла
Для страницы с шаблоном Code Driven можно использовать такой порядок поиска:
patterns/pages/<uri>.phppatterns/pages/<uri>/index.phppatterns/pages/<slug>.phppatterns/pages/home.php— для главной страницыpatterns/pages/default.php— общий файл по умолчанию
Где:
<uri>— путь страницы без домена;<slug>— короткое имя текущей страницы;home.php— отдельный файл для главной;default.php— резервный файл, если точного совпадения нет.
Такой порядок дает гибкость: можно описывать как простые страницы, так и вложенные разделы.
Реализация по шагам
Шаг 1. Создать шаблон страницы
Файл:
templates/code-driven.php
<?php
/**
* Template Name: Code Driven
* Template Post Type: page
*/
if ( ! is_page() ) {
wp_die( 'This template is only available for pages.', 'Template Error', [ 'response' => 404 ] );
}
get_header();
?>
<main class="site-main">
<?php
while ( have_posts() ) :
the_post();
$pattern_content = function_exists( 'app_render_page_pattern' )
? app_render_page_pattern()
: null;
if ( null !== $pattern_content ) {
echo $pattern_content;
} else {
the_content();
}
endwhile;
?>
</main>
<?php
get_footer();
Этот шаблон делает три вещи:
- Проверяет, что он применяется именно к странице WordPress.
- Пытается получить содержимое из файла темы.
- Если файла нет, выводит обычное содержимое страницы.
Главное преимущество такого варианта — явность. Нет глобальной подмены содержимого через фильтр the_content, поэтому поведение не распространяется на весь сайт.
Шаг 2. Добавить резолвер файлов
Файл:
includes/PagePatternRouter.php
function app_resolve_page_pattern_file() {
if ( ! is_page() || ! is_page_template( 'templates/code-driven.php' ) ) {
return null;
}
// ... сбор возможных файлов и проверка их существования ...
}
function app_render_page_pattern() {
$file = app_resolve_page_pattern_file();
if ( null === $file ) {
return null;
}
ob_start();
include $file;
$markup = trim( (string) ob_get_clean() );
if ( '' === $markup ) {
return null;
}
return do_blocks( $markup );
}
Функция app_resolve_page_pattern_file() отвечает только за поиск подходящего файла. Функция app_render_page_pattern() отвечает за вывод найденного файла.
Разделение полезно: поиск файла можно отдельно тестировать, логировать и дорабатывать.
Шаг 3. Создать файлы страниц
Примеры файлов:
patterns/pages/hello-world.phppatterns/pages/hello-world/test.php
Пример простого файла hello-world.php:
<!-- wp:heading {"textAlign":"center","level":1} -->
<h1 class="wp-block-heading has-text-align-center">Hello World</h1>
<!-- /wp:heading -->
<!-- wp:paragraph {"align":"center"} -->
<p class="has-text-align-center">Этот контент загружен из patterns/pages/hello-world.php.</p>
<!-- /wp:paragraph -->
В этих файлах можно хранить разметку блоков WordPress. После подключения файла функция do_blocks() обработает блоки и вернет готовую разметку для вывода.
Как пользоваться
Для редактора и разработчика процесс выглядит так:
- Создать страницу в WordPress.
- Назначить ей шаблон
Code Driven. - Создать соответствующий файл в каталоге
patterns/pages. - Открыть страницу на сайте и проверить результат.
Для вложенных адресов, например /hello-world/test/, нужна соответствующая структура файлов и иерархия страниц в WordPress.
Чем это отличается от Astro и Next.js
Похоже:
- адрес страницы связан со структурой файлов;
- содержимое удобно хранить рядом с кодом;
- новую страницу часто можно добавить созданием нового файла.
Отличается:
- WordPress все равно требует страницу в базе данных;
- это не заменяет иерархию шаблонов WordPress (template hierarchy), а добавляет отдельный слой поверх нее;
- динамические сегменты адреса, например
[slug], нужно реализовывать отдельно через сопоставитель маршрутов (matcher) или карту маршрутов (route map).
Где подход особенно полезен
- посадочные страницы;
- промо-страницы и спецпроекты;
- прототипирование страниц до передачи редакторам;
- страницы со сложной структурой блоков;
- маркетинговые страницы, где важны точная верстка и быстрые итерации;
- гибридные темы, где не хочется полностью переходить на блочные шаблоны.
Ограничения и риски
- Содержимое в файлах требует процесса разработки: ветки, коммиты, проверка и деплой. Для разработчика это плюс, но для редактора без доступа к коду — ограничение.
- Если часть содержимого живет в файлах, а часть — в редакторе WordPress, нужно заранее определить источник истины. Иначе команда быстро запутается, где именно править страницу.
- Нужно аккуратно настроить правила поиска файлов. Слишком широкие правила могут привести к неожиданному выводу не того файла.
- Желательно добавить логирование: какой адрес страницы был сопоставлен с каким файлом. Это упростит отладку.
Вывод
Разработка страниц WordPress из файлов по подходу Astro и Next.js — это практичный гибрид. WordPress сохраняет свои сильные стороны: админку, редактор, роли пользователей и экосистему. При этом команда получает более предсказуемый процесс первичной разработки страниц.
Оптимальная схема — использовать отдельный шаблон Code Driven, явный поиск файла и безопасный возврат к обычному содержимому WordPress. Тогда решение остается понятным, управляемым и безопасным для рабочей темы.
