ворд-пресс.рф
Разработка

Как создать блочную тему WordPress с нуля: файлы, templates, parts и theme.json

Минимальная структура собственной блок-темы WordPress и безопасный старт разработки без копирования чужой темы.

Чтобы создать собственную блочную тему 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. Что тестировать

  1. Активируется ли тема на чистой тестовой установке без предупреждений.
  2. Корректно ли работают index, обычные страницы, записи, архив, поиск, 404.
  3. Поддерживаются ли новые блоки и пользовательские шаблоны без сломанной разметки.
  4. Не пропадают ли шапка и подвал при редактировании и обновлении.
  5. Доступна ли навигация с клавиатуры и в мобильной версии.
  6. Остаются ли редактор и фронтенд визуально согласованными.
  7. Корректно ли проходит обновление версии темы с сохранением контента.

Отделяйте тему от функциональности: формы, роли, интеграции и бизнес-данные не стоит жёстко встраивать в тему, если ими должны управлять отдельные плагины. Для продвинутых задач используйте разработку Gutenberg-блоков и архитектуру CPT.

Безопасность и поддержка

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

Критерий готовности: исходники темы хранятся в системе контроля версий, проходят проверки на чистом WordPress и не зависят от скрытых пользовательских настроек одной локальной установки.

Источник: https://developer.wordpress.org/themes/core-concepts/theme-structure/

Материал был полезен?

Помогите нам сделать материалы точнее и понятнее.