Чтобы создать собственную блочную тему WordPress, достаточно начать с корректных метаданных style.css и шаблона templates/index.html, а затем подключить theme.json, папки parts и другие шаблоны по мере необходимости. Это техническое руководство по разработке, а не инструкция по использованию готовой темы через админку.
Когда действительно нужна собственная тема
Пишите собственную тему, если проекту нужны управляемая дизайн-система, повторяемые шаблоны и предсказуемая поддержка. Если нужен обычный сайт услуг, быстрее и безопаснее сначала попробовать готовую тему и её редактор. Как выбрать тему.
Перед работой создайте локальную тестовую среду. Для разработки и проверок можно использовать wp-env. Не экспериментируйте с шаблонами на рабочем сайте без резервной копии и отката.
Минимальная структура каталогов
my-block-theme/
├── style.css
├── theme.json
├── templates/
│ ├── index.html
│ ├── page.html
│ └── single.html
└── parts/
├── header.html
└── footer.html
В данном примере theme.json, дополнительные шаблоны и части шаблонов не обязательны для самого минимального распознавания темы. Нужные минимальные файлы — style.css и templates/index.html; остальные добавляются по мере развития проекта.
Шаг 1. Метаданные темы
Создайте style.css в корне темы. В начале укажите заголовок темы в комментарии:
/*
Theme Name: My Block Theme
Author: Example Team
Description: Пример минимальной блочной темы для тестовой установки.
Version: 0.1.0
Text Domain: my-block-theme
*/
Не пишите в метаданных неподтверждённые требования совместимости и не используйте имя существующего продукта без разрешения. CSS можно добавлять позже; сама шапка — прежде всего идентификатор темы в WordPress.
Шаг 2. Создайте базовый шаблон
Путь — templates/index.html. Блочный шаблон хранит разметку блоков WordPress, а не произвольную HTML-страницу с нераспознанными компонентами.
<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">
<!-- wp:site-title /-->
<!-- wp:post-title /-->
<!-- wp:post-content /-->
</div>
<!-- /wp:group -->
Это минимальная учебная конструкция; для реального сайта понадобятся другие шаблоны, части Header/Footer, стили и проверка того, как блоки интерпретируются установленным WordPress. Не используйте этот пример как универсальный производственный шаблон.
Шаг 3. Добавьте theme.json
theme.json задаёт настройки редактора и стили. Ниже пример для учебного проекта:
{
"$schema": "https://schemas.wp.org/wp/6.6/theme.json",
"version": 3,
"settings": {
"color": {
"palette": [
{"slug": "ink", "name": "Основной", "color": "#202938"},
{"slug": "surface", "name": "Фон", "color": "#ffffff"}
]
}
},
"styles": {
"color": {"text": "#202938", "background": "#ffffff"}
}
}
Здесь версия схемы привязана к примеру для WordPress 6.6. Для другого окружения перепроверьте совместимость и актуальную JSON Schema, а не копируйте поле $schema наугад. Фактическую совместимость нашей учебной темы на разных релизах мы не испытывали.
В интерфейсе блочной темы пользовательские изменения глобальных стилей могут переопределять значения файла; при отладке учитывайте настройки, сохранённые в БД. Подробности — введение в блочные темы.
Шаг 4. Части шаблона и остальные шаблоны
Шапку и подвал обычно выносят в parts/header.html и parts/footer.html, подключая через блок template-part. Для отдельных типов контента существуют page.html, single.html, archive.html, 404.html и другие шаблоны. Отсутствующие специализированные шаблоны разрешаются механизмом иерархии шаблонов WordPress.
Если редактор меняет шаблон через Site Editor, эти изменения могут сохраняться в БД и иметь приоритет перед файлом в репозитории. Поэтому при разработке распространяемой темы недостаточно показать предпросмотр: нужно синхронизировать проверенный исходный код темы с нужными файлами.
Шаг 5. Что тестировать
- Активируется ли тема на чистой тестовой установке без предупреждений.
- Корректно ли работают
index, обычные страницы, записи, архив, поиск, 404. - Поддерживаются ли новые блоки и пользовательские шаблоны без сломанной разметки.
- Не пропадают ли шапка и подвал при редактировании и обновлении.
- Доступна ли навигация с клавиатуры и в мобильной версии.
- Остаются ли редактор и фронтенд визуально согласованными.
- Корректно ли проходит обновление версии темы с сохранением контента.
Отделяйте тему от функциональности: формы, роли, интеграции и бизнес-данные не стоит жёстко встраивать в тему, если ими должны управлять отдельные плагины. Для продвинутых задач используйте разработку Gutenberg-блоков и архитектуру CPT.
Безопасность и поддержка
Не публикуйте в теме секреты, API-ключи и учётные данные. Все динамические данные выводите с нужным экранированием и проверяйте права перед изменениями. Не редактируйте сторонний плагин ради внешнего вида страницы.
Критерий готовности: исходники темы хранятся в системе контроля версий, проходят проверки на чистом WordPress и не зависят от скрытых пользовательских настроек одной локальной установки.
Источник: https://developer.wordpress.org/themes/core-concepts/theme-structure/
Материал был полезен?
Помогите нам сделать материалы точнее и понятнее.