Натягивание вёрстки на WordPress: от HTML до темы

Подготовка проекта и структура темы WordPress

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

Что значит натянуть вёрстку на WordPress

Под натягиванием обычно понимают процесс, в котором:

Статические HTML-страницы разбиваются на повторно используемые части (шапка, подвал, сайдбар, секции).

Эти части превращаются в шаблоны WordPress (файлы темы).

Контент (заголовки, тексты, изображения, списки постов) начинает приходить из админки WordPress.

Подключаются стили и скрипты так, как требует WordPress (через функции темы).

Результат — тема, которую можно активировать в админке, и сайт, который редактируется через WordPress.

Минимальные требования к инструментам

Чтобы работать комфортно, вам понадобятся:

Локальный сервер и база данных.

Редактор кода.

Браузер и инструменты разработчика.

Рекомендуемый минимум:

Локальная среда: Local или Docker.

WordPress (последняя стабильная версия): WordPress.org

Редактор: VS Code.

Если планируете использовать сборку фронтенда (Sass, минификация, сборка JS), пригодится Node.js:

Node.js

Как организовать проект локально

Цель — иметь понятную структуру, в которой легко найти:

файлы WordPress

базу данных (если используется менеджер окружения)

файлы темы

исходники вёрстки (если они есть отдельно)

Практичный вариант структуры (пример):

project/

project/wp/ — ядро WordPress

project/wp-content/themes/my-theme/ — ваша тема

project/layout/ — исходная HTML-вёрстка (как архивный эталон)

Почему полезно хранить layout/ отдельно:

проще сравнивать «как было в HTML» и «как стало в теме»

меньше риск случайно сломать эталонную версию

Что такое тема WordPress

Тема WordPress — это набор файлов, которые управляют тем, как отображается сайт:

какие шаблоны используются для страниц и записей

где выводится контент

какие стили и скрипты подключаются

Тема находится по пути:

wp-content/themes/имя-темы/

Официальная документация по темам:

WordPress Theme Handbook

Минимальный набор файлов темы

Чтобы WordPress признал папку темой, обычно достаточно двух файлов:

style.css

index.php

Файл style.css

Это не просто стили. В начале файла находится заголовок темы (метаданные), по которым WordPress показывает тему в админке.

Пример минимального заголовка:

Важно:

Название темы берётся из Theme Name.

Даже если вы вынесете стили в другие файлы, style.css всё равно нужен как «паспорт» темы.

Файл index.php

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

На старте он может быть простым, но в рабочей теме index.php обычно становится запасным вариантом, а основные страницы обслуживаются специализированными шаблонами.

Обязательные файлы, которые появятся очень быстро

Почти в любой теме уже на ранних шагах добавляются:

functions.php — функции темы: подключение стилей и скриптов, регистрация меню, поддержка возможностей темы

header.php — шапка сайта

footer.php — подвал сайта

sidebar.php — сайдбар (если он нужен)

Почему важно выделять header.php и footer.php:

они повторяются на большинстве страниц

в WordPress есть стандартные функции подключения этих частей

Иерархия шаблонов и ключевые шаблонные файлы

WordPress выбирает, какой шаблон использовать, по иерархии шаблонов: от самого специфичного к самому общему.

Официальная схема:

Template Hierarchy

Шаблоны, которые чаще всего нужны при натягивании вёрстки:

front-page.php — главная страница сайта (если в настройках выбрана статическая главная)

home.php — главная лента записей (блог)

page.php — отдельная страница

single.php — отдельная запись

archive.php — архивы (категории, теги, даты)

category.php — архив категории (частный случай архива)

tag.php — архив тега

search.php — результаты поиска

404.php — страница «не найдено»

Практическая логика для старта:

Если вы делаете корпоративный сайт с уникальной главной — чаще всего понадобятся front-page.php и page.php.

Если вы делаете блог — почти всегда нужны home.php, single.php, archive.php.

Шаблонные части и переиспользование блоков

Кроме header.php и footer.php, в теме часто появляются повторяющиеся секции:

карточка поста в списке

блок «хлебные крошки»

секция героя на страницах

форма подписки

Для таких элементов удобно использовать шаблонные части.

Современный подход — хранить их в папке:

template-parts/

Например:

template-parts/content/content-post.php

template-parts/content/content-page.php

Это помогает:

не дублировать разметку

менять компонент в одном месте

Подключение стилей и скриптов: куда класть ассеты

Типичная структура внутри темы:

assets/css/

assets/js/

assets/img/

assets/fonts/

Даже если у вас один файл стилей и один файл скриптов, привычка держать их в assets/ экономит время, когда проект вырастет.

Важно: в WordPress стили и скрипты корректно подключать через functions.php (мы сделаем это в следующих статьях), а не «вставлять ссылкой» в шаблон.

Рекомендуемая структура темы на старте

Ниже пример структуры, с которой удобно натягивать вёрстку и расширять тему:

my-theme/

assets/

assets/css/

assets/js/

assets/img/

template-parts/

template-parts/content/

style.css

functions.php

index.php

header.php

footer.php

page.php

single.php

archive.php

search.php

404.php

Если главная страница у проекта особенная, сразу добавьте:

front-page.php

!Схема, как обычно устроена тема и где лежат ассеты и шаблонные части

Дочерняя тема и почему новичкам чаще не нужна

Дочерняя тема — это тема, которая наследует шаблоны и стили родительской темы и переопределяет только то, что вам нужно.

Она полезна, когда:

вы кастомизируете чужую тему и хотите сохранять возможность обновления

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

Документация:

Child Themes

Качество и стандарты кода

С первого дня полезно привыкать к базовым стандартам, чтобы тема была поддерживаемой:

единый стиль кода

понятные имена файлов и функций

аккуратная структура папок

Официальные стандарты WordPress:

WordPress Coding Standards

Что должно быть готово перед началом натягивания

К концу подготовки у вас должно быть:

Установленный WordPress локально.

Пустая тема в wp-content/themes/.

Минимум: style.css с заголовком и index.php.

Запланированная структура папок assets/ и template-parts/.

Понимание, какие шаблоны вам нужны: front-page.php, page.php, single.php, archive.php.

В следующей статье мы начнём превращать HTML-вёрстку в шаблоны: разрежем страницы на части и подключим header.php и footer.php правильным способом.

Разбиение вёрстки на шаблоны: header, footer, index

После подготовки структуры темы из предыдущей статьи следующий шаг в натягивании вёрстки — превратить одну или несколько HTML-страниц в набор шаблонов WordPress. Начинаем с базового разбиения на три опорные части:

header.php — всё, что повторяется сверху на большинстве страниц

footer.php — всё, что повторяется снизу

index.php — запасной шаблон, который WordPress использует по умолчанию

Главная цель этого шага — убрать дублирование и подключить обязательные хуки WordPress, без которых плагины, редактор и часть функциональности будут работать неправильно.

!Наглядно показывает, какие части страницы выносятся в отдельные файлы и как они подключаются

Принцип разбиения: ищем повторяемые зоны

В статической вёрстке обычно есть элементы, которые повторяются на каждой странице:

верхняя часть: логотип, меню, контакты, шапка

нижняя часть: копирайт, ссылки, скрипты, футер-меню

общие подключения: стили, скрипты, мета-информация

В WordPress эти зоны нужно вынести в отдельные файлы и подключать стандартными функциями. Так вы получаете:

единое место для правок шапки и подвала

корректную работу плагинов, которым нужны wp_head() и wp_footer()

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

Создаём header.php

header.php содержит верхнюю часть страницы. Но для WordPress важно не только визуальное содержимое: здесь должен быть вызов wp_head().

Зачем нужен wp_head()

wp_head() — это точка, куда WordPress и плагины добавляют важные вещи:

подключение стилей и скриптов

мета-теги и данные для SEO-плагинов

данные для редактора и REST-интеграций

Если забыть wp_head(), часть подключений просто не появится.

Минимальный каркас header.php

Полезные функции, которые часто используются в шапке

language_attributes() — добавляет языковые атрибуты документа

bloginfo('charset') — кодировка сайта

bloginfo('name') — название сайта

home_url('/') — корректная ссылка на главную

body_class() — классы для тега страницы, удобно для стилизации разных типов страниц

wp_body_open() — хук для вставок сразу после открытия области страницы (важно для аналитики и некоторых плагинов)

Документация:

wp_head

wp_body_open

body_class

Создаём footer.php

footer.php — нижняя часть страницы. Ключевой элемент здесь — wp_footer().

Зачем нужен wp_footer()

wp_footer() — место, куда WordPress и плагины добавляют код перед завершением страницы:

скрипты, которые должны грузиться в конце

код аналитики

служебные блоки плагинов

Если забыть wp_footer(), часто «ломаются» скрипты и функциональность плагинов.

Минимальный каркас footer.php

Документация:

wp_footer

Подключаем шапку и подвал из index.php

Теперь нужно научиться собирать страницу из частей.

Как подключать header.php и footer.php

WordPress предоставляет стандартные функции:

get_header() — подключает header.php

get_footer() — подключает footer.php

Документация:

get_header

get_footer

Минимальный index.php как «склейка» шаблонов

На этом этапе тема уже становится похожей на WordPress-тему: верх и низ подключаются централизованно.

Добавляем базовую динамику в index.php: цикл WordPress

Статическая вёрстка показывает фиксированный текст. WordPress же чаще всего выводит записи через цикл.

Цикл — это стандартный способ пройтись по найденным записям и вывести их данные. Основные функции:

have_posts() — проверяет, есть ли записи в текущем запросе

the_post() — подготавливает текущую запись

the_title() — выводит заголовок

the_excerpt() — выводит краткое описание

the_content() — выводит полный контент

Документация:

The Loop

Пример простого цикла в index.php

Важно понимать: этот код показывает принцип. На практике вы будете вставлять функции вывода контента в нужные места вашей вёрстки.

Шаблонные части: когда одного index.php становится мало

Как только вы начнёте выводить список записей, у вас появятся повторяющиеся элементы внутри контента:

карточка поста в списке

превью, заголовок, мета-информация

блок «ничего не найдено»

Чтобы не раздувать index.php, в WordPress принято выносить такие куски в шаблонные части и подключать их через get_template_part().

Документация:

get_template_part

Пример подключения шаблонной части

Это будет искать файл template-parts/content/content-post.php. Подход удобен тем, что вы собираете страницу как конструктор из компонентов.

Частые ошибки при разбиении вёрстки

Перенос подключений стилей и скриптов напрямую в шаблоны вместо подключения через functions.php.

Отсутствие wp_head() в header.php.

Отсутствие wp_footer() в footer.php.

Смешивание логики и разметки в одном огромном index.php вместо template-parts/.

Попытка сделать всё динамическим сразу вместо постепенной замены статического контента на функции WordPress.

Что должно получиться после этого шага

К концу этого этапа у вас в теме должно быть:

header.php с wp_head()

footer.php с wp_footer()

index.php, который подключает шапку и подвал через get_header() и get_footer()

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

В следующем материале логично перейти к правильному подключению стилей и скриптов через functions.php, чтобы ваша вёрстка отображалась так же, как в HTML-эталоне, и чтобы WordPress мог управлять ассетами корректно.

Подключение стилей и скриптов: enqueue, зависимости, оптимизация

После того как вы разрезали HTML-вёрстку на header.php, footer.php и index.php, следующий критически важный шаг — подключить CSS и JavaScript по правилам WordPress. Это нужно не только «чтобы работали стили», но и чтобы:

плагины могли корректно добавлять свои файлы

WordPress правильно управлял зависимостями и порядком загрузки

можно было управлять загрузкой ассетов на разных страницах

не ломались wp_head() и wp_footer(), которые мы добавили в предыдущей статье

!Схема того, как enqueue приводит к появлению CSS/JS в head и footer

Почему нельзя подключать CSS и JS как в чистом HTML

В статической вёрстке вы обычно добавляете файлы напрямую (например, в шапке страницы). В WordPress так делать не стоит, потому что:

WordPress и плагины рассчитывают, что файлы будут добавляться через очередь подключений

система зависимостей (например, «этот скрипт требует jQuery») работает только через enqueue

управление версиями для кэширования и корректный порядок загрузки проще поддерживать централизованно

Правильный способ — подключать ассеты из functions.php через хуки.

Документация:

wp_enqueue_style

wp_enqueue_script

wp_enqueue_scripts

Где и когда WordPress выводит подключенные файлы

Когда вы вызываете wp_enqueue_style() и wp_enqueue_script(), WordPress не печатает теги сразу. Он добавляет файлы в очередь.

Дальше:

стили обычно выводятся там, где стоит wp_head() (в header.php)

скрипты могут выводиться в wp_head() или в wp_footer() (в footer.php) — зависит от параметров подключения

Это одна из причин, почему в предыдущей статье мы так настаивали на wp_head() и wp_footer().

Базовая настройка: подключаем CSS и JS в functions.php

Создадим функцию, которая подключит ваши файлы темы, и повесим её на хук wp_enqueue_scripts.

Пример структуры (как в предыдущей статье):

my-theme/assets/css/main.css

my-theme/assets/js/main.js

Пример кода подключения

Разбираем параметры enqueue: что означает каждый

wp_enqueue_style( src, ver, handle — уникальное имя подключения (идентификатор). Например, mytheme-main.

deps — зависимости: массив хэндлов, которые должны быть подключены раньше.

media — для каких устройств/типов вывода стиль, чаще всего all (если не указывать, будет стандартное значение).

Документация:

wp_enqueue_style

wp_enqueue_script( src, ver, handle — уникальное имя.

deps — зависимости.

in_footer — если true, скрипт будет выведен ближе к концу страницы, в месте wp_footer().

Документация:

wp_enqueue_script

Как правильно формировать пути к файлам темы

Частая ошибка новичков — собирать URL руками или использовать относительные пути.

Используйте функции WordPress:

get_theme_file_uri( 'assets/css/main.css' ) — безопасно и удобно, возвращает URL

get_theme_file_path( 'assets/css/main.css' ) — возвращает путь на диске (полезно для filemtime)

get_template_directory_uri() — URL папки темы (обычно используют для более ручной сборки путей)

Документация:

get_theme_file_uri

get_theme_file_path

Зависимости: как управлять порядком загрузки

Зависимости задаются массивом хэндлов в параметре ver при изменении файла. Практичный подход в разработке темы — использовать время изменения файла.

php function mytheme_enqueue_assets() { wp_enqueue_script( 'mytheme-main', get_theme_file_uri( 'assets/js/main.js' ), array(), mytheme_asset_version( 'assets/js/main.js' ), true );

wp_localize_script( 'mytheme-main', 'MYTHEME', array( 'ajaxUrl' => admin_url( 'admin-ajax.php' ), ) ); } add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_assets' ); php function mytheme_defer_scripts( handle ) { if ( 'mytheme-main' === tag ); } return deps, и только потом оптимизируйте

Документация:

script_loader_tag

Частые ошибки при подключении ассетов

Подключать CSS и JS напрямую в header.php или footer.php.

Забыть про wp_head() и wp_footer() (и потом искать, почему не работают стили/скрипты плагинов).

Использовать один и тот же is not defined».

Не управлять версиями и сталкиваться с тем, что обновления «не применяются» из-за кэша.

Что должно получиться после этого шага

К этому моменту у вас должно быть:

functions.php, который подключает CSS и JS через wp_enqueue_scripts

ассеты темы лежат в assets/ и подключаются через get_theme_file_uri()

при необходимости настроены зависимости (например, array( 'jquery' ))

скрипты темы грузятся в футере, а версии файлов обновляются автоматически через filemtime()`

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

Вывод контента: Loop, меню, виджеты, шаблоны страниц

После того как тема получила базовую структуру (header.php, footer.php, index.php) и вы подключили CSS/JS через enqueue в functions.php, следующий шаг в натягивании вёрстки — заменить статические фрагменты на динамику WordPress.

В этой статье мы разберём четыре опорные вещи, без которых тема остаётся «почти HTML»:

Loop (цикл) — вывод записей и страниц из базы данных

Меню — подключение навигации из админки

Виджеты (сайдбары) — управляемые зоны (например, в подвале или боковой колонке)

Шаблоны страниц — как WordPress выбирает файлы темы, и как делать отдельные шаблоны под макеты

!Схема процесса выбора шаблона и вывода контента через цикл

Loop

Loop — это стандартный механизм WordPress для вывода результата текущего запроса: список записей, одну запись, страницу, архив категории и так далее.

Ключевая идея:

WordPress заранее формирует текущий запрос (какие записи нужно вывести)

В шаблоне вы проходите по найденным записям через Loop

Документация:

The Loop

Базовый Loop для списка записей

Ниже типичный каркас, который вы будете вставлять в index.php, home.php, archive.php и другие шаблоны списков.

Что здесь происходит:

have_posts() проверяет, есть ли что выводить

while ( have_posts() ) перебирает записи

the_post() подготавливает текущую запись (после этого работают the_title(), the_excerpt() и другие)

the_permalink() даёт ссылку на запись

the_posts_pagination() выводит пагинацию на архивах и в лентах

Документация по функциям:

have_posts

the_post

the_title

the_excerpt

the_permalink

the_posts_pagination

Loop для одиночной записи и страницы

Для single.php и page.php Loop обычно «одиночный», но структура похожая.

Пример для single.php:

Ключевая разница:

на одиночной сущности обычно используют the_content(), а не the_excerpt()

Документация:

the_content

Почему Loop важно выносить в шаблонные части

Если вы начнёте вставлять всю разметку карточки поста прямо в index.php, archive.php и home.php, очень быстро появится дублирование.

Практика WordPress — вынести повторяемые элементы в template-parts/.

Пример структуры:

template-parts/content/content-post.php

template-parts/content/content-page.php

Подключение:

Так WordPress попытается найти файл по типу записи, например content-post.php.

Документация:

get_template_part

Меню

В статической вёрстке меню обычно «захардкожено» в HTML. В WordPress меню должно управляться из админки:

вы регистрируете места меню в теме

редактор сайта назначает конкретное меню в нужное место

в шаблоне вы выводите меню функцией wp_nav_menu()

Документация:

Navigation Menus

wp_nav_menu

Регистрация мест меню в functions.php

Что важно:

ключи header_menu и footer_menu — это идентификаторы, по которым вы будете выводить меню в шаблонах

хук after_setup_theme подходит для настройки возможностей темы

Документация:

register_nav_menus

after_setup_theme

Вывод меню в header.php

В нужном месте вашей разметки:

Практические замечания:

theme_location связывает вывод с зарегистрированным местом

menu_class даёт класс списку меню (полезно, чтобы «натянуть» ваши CSS-классы)

container => false отключает лишнюю обёртку, если она не нужна вашей вёрстке

Логотип и ссылка на главную рядом с меню

Частая часть шапки — логотип. Чтобы логотип управлялся из админки, включают поддержку custom-logo.

В functions.php:

В header.php:

Документация:

add_theme_support

the_custom_logo

Виджеты и сайдбары

В WordPress виджеты живут в зонах виджетов (их ещё называют сайдбары), которые вы регистрируете в теме. Это не обязательно «боковая колонка»: часто виджеты используют для подвала, шапки, шторки меню.

Документация:

Sidebars

register_sidebar

dynamic_sidebar

Регистрация зоны виджетов

В functions.php:

Что важно:

id используется при выводе виджетов

before_widget, after_widget, before_title, after_title помогают «срастить» виджеты с вашей вёрсткой

Вывод виджетов в sidebar.php

Создайте sidebar.php и добавьте:

И подключайте сайдбар там, где он нужен:

Документация:

is_active_sidebar

get_sidebar

Шаблоны страниц

Чтобы корректно натянуть разные макеты, нужно понимать два уровня:

иерархия шаблонов — как WordPress автоматически выбирает файл темы

кастомные шаблоны страниц — когда вы вручную создаёте шаблон для конкретного макета

Документация:

Template Hierarchy

Базовый набор шаблонов для натягивания вёрстки

Чаще всего достаточно такого старта:

front-page.php — главная (если в настройках выбрана статическая главная)

home.php — лента записей (страница блога)

page.php — обычная страница

single.php — запись

archive.php — архивы (категории, теги, даты)

search.php — поиск

404.php — не найдено

index.php — запасной вариант, если ничего более подходящего нет

Когда делать front-page.php, а когда home.php

Это частая путаница:

front-page.php отвечает за «лицевую» главную страницу сайта

home.php отвечает за страницу, где выводится лента записей

Если в настройках WordPress:

выбрана «последние записи», то главная часто обслуживается home.php

выбрана «статическая страница», то главная — это front-page.php, а блог-лента уходит на отдельную страницу и обслуживается home.php

Кастомный шаблон для страницы под отдельный макет

Иногда дизайнер даёт несколько разных макетов страниц: например, «О компании», «Контакты», «Лендинг». Можно сделать отдельный шаблон страницы.

Создайте файл, например page-landing.php, и добавьте вверху специальный комментарий.

После этого в админке у страницы появится выбор шаблона.

Документация:

Custom Templates

Шаблоны по слагу и по ID

WordPress умеет автоматически подхватывать специальные файлы страницы:

page-about.php — для страницы со слагом about

page-42.php — для страницы с ID 42

Это удобно, если у вас есть «фиксированные» страницы проекта, но чаще в командной разработке предпочтительнее явные кастомные шаблоны с Template Name, чтобы было проще поддерживать.

Практический маршрут «натягивания» динамики

Если вы переносите готовую HTML-вёрстку в тему, удобный порядок такой:

Соберите каркас шаблонов: header.php, footer.php, нужные page.php, single.php, archive.php.

Вставьте Loop в каждый шаблон и временно выведите the_title() и the_content(), чтобы проверить, что всё работает.

Вынесите повторяемую разметку карточек и секций в template-parts/.

Зарегистрируйте меню и замените статическое меню на wp_nav_menu().

Зарегистрируйте виджетные зоны и перенесите «динамические» места (например, колонку и подвал) на dynamic_sidebar().

На этом этапе тема становится действительно управляемой: контент редактируется из админки, а ваша вёрстка сохраняет структуру благодаря шаблонам и шаблонным частям.

Кастомизация и финальная сборка: ACF, CPT, адаптация и деплой

На предыдущих этапах вы:

подготовили структуру темы

разрезали вёрстку на header.php, footer.php, index.php

подключили ассеты через enqueue

научились выводить контент через Loop, подключили меню и виджеты

Теперь задача финального этапа — довести тему до состояния проектной: добавить управляемые поля, завести нужные типы контента, аккуратно адаптировать вёрстку под WordPress-реалии и корректно выкатить сайт на сервер.

!Общая карта финального этапа: от динамики к структуре данных и деплою

ACF

ACF (Advanced Custom Fields) — плагин, который позволяет добавлять к записям, страницам и другим сущностям WordPress дополнительные поля (например: цена, кнопка, галерея, характеристики), а затем выводить их в шаблонах темы.

Зачем ACF при натягивании вёрстки:

в дизайне часто есть блоки, которые неудобно редактировать через обычный редактор (например, таблица характеристик)

дизайнерские секции часто требуют структурированных данных, а не «вставьте текст куда-нибудь»

ACF помогает сохранить вашу вёрстку и дать редактору понятные поля

Официальные материалы:

Advanced Custom Fields

Документация ACF

Типовые сценарии для натягивания

Герой (hero) на главной: заголовок, подзаголовок, кнопка, фоновая картинка

Секция преимуществ: повторяющиеся элементы (иконка, заголовок, текст)

Контакты: адрес, телефон, карта, ссылки на соцсети

Карточка услуги/проекта: галерея, характеристики, файлы для скачивания

Настройка полей в админке

Общий алгоритм работы с ACF обычно такой:

Создаёте группу полей.

Добавляете поля нужных типов.

Настраиваете условие показа (например, только для страницы со слагом home или для типа записи project).

Заполняете поля в редакторе.

Выводите значения в шаблоне.

Вывод значений ACF в шаблоне

В теме значения полей обычно получают функцией get_field().

Пример: поле hero_title для главной страницы.

Где хранить «настройки сайта»

Часть данных относится не к странице, а ко всему сайту:

телефоны и мессенджеры

адрес

ссылки на соцсети

копирайт в футере

Это можно решить несколькими способами:

через обычную страницу «Контакты» и вывод данных оттуда

через «Настройщик» (Customizer) или Site Editor в современных подходах

через ACF Options Page (функция доступна в ACF PRO)

Если используете ACF Options Page, убедитесь, что проект действительно предполагает ACF PRO и это согласовано.

CPT

CPT (Custom Post Type) — пользовательский тип записи. Он нужен, когда контент проекта не укладывается в стандартные «Записи» и «Страницы». Например:

портфолио (проекты)

услуги

команда

отзывы

вакансии

Официальная документация:

register_post_type

Когда CPT оправдан

CPT стоит заводить, если верно хотя бы одно:

нужен отдельный раздел в админке

нужны отдельные архивы и одиночные страницы по своей структуре

у сущности есть свой набор полей (и вы не хотите всё хранить в контенте страницы)

Регистрация CPT в functions.php

Пример: тип записи project.

Пояснение ключевых параметров:

public — тип записи виден на сайте

has_archive — включить страницу-архив (список)

rewrite — человекопонятный URL

supports — какие стандартные поля включены

show_in_rest — важно для современного редактора и REST API

Таксономии для структуры

Если проектам нужна классификация (например, «Веб», «Мобильные», «Брендинг»), добавляют таксономию.

Официальная документация:

register_taxonomy

Пример: таксономия project_category для project.

Какие шаблоны нужны под CPT

Под project обычно добавляют:

single-project.php — одиночная страница проекта

archive-project.php — архив проектов

Это часть иерархии шаблонов WordPress:

Template Hierarchy

Связка CPT и ACF

Типовой проектный набор выглядит так:

CPT project задаёт сущность

таксономия project_category даёт структуру

ACF добавляет поля (галерея, клиент, дата, ссылка на проект)

!Как CPT, таксономии, ACF и шаблоны складываются в единую модель

Адаптация вёрстки под WordPress

Когда HTML превращается в тему, появляются «реалии» CMS:

админка может отдавать длинные заголовки

изображения могут быть разных пропорций

списки и таблицы в the_content() могут ломать дизайн, если не учесть стили

редактор может вставлять дополнительные блоки

Ниже набор практик, которые помогают сделать тему устойчивой.

Контейнер для контента и стили редактора

Страница и запись обычно выводят контент через the_content(). Чтобы типографика совпала с дизайном, почти всегда делают отдельные стили для контентной зоны.

Практика:

выделите контейнер (например, класс content)

опишите стили для заголовков, списков, цитат, таблиц, изображений внутри контейнера

Это защищает общий UI сайта от «контентных» стилей.

Изображения: миниатюры и размеры

Если вы используете превью в карточках, включите поддержку миниатюр.

Документация:

add_theme_support

Дальше в карточках используйте миниатюру, а не «любую картинку».

Документация:

the_post_thumbnail

Навигация и активные состояния

wp_nav_menu() отдаёт классы вроде current-menu-item. Это удобно для подсветки активного пункта меню в CSS.

Документация:

wp_nav_menu

Переводы и текстовые строки

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

Документация:

Internationalization

Пример:

Безопасный вывод данных

Короткое правило:

всё, что приходит из админки, базы, ACF, URL-параметров, нужно экранировать при выводе

Самые частые функции:

esc_html() — для текста

esc_attr() — для атрибутов

esc_url() — для ссылок

Документация:

Data Sanitization and Escaping

Финальная сборка темы

На этом этапе вы приводите проект к виду, который можно передать на поддержку или выкатить в прод.

Чеклист перед деплоем

Проверить, что wp_head() и wp_footer() на месте и ничего не подключено «в лоб» в шаблонах.

Проверить, что ассеты подключены через enqueue, а версии обновляются (например, через filemtime()).

Пройтись по страницам и проверить устойчивость верстки:

- очень длинные заголовки - пустые поля ACF - отсутствие картинок - пустые списки (нет записей в CPT)

Проверить 404, поиск, архивы.

Проверить адаптив:

- меню на мобильных - сетки карточек - таблицы и изображения внутри the_content()

Проверить базовую производительность:

- нет ли лишних ассетов на страницах, где они не нужны - грузятся ли скрипты в футере

Проверить SEO-базу:

- включена поддержка title-tag - корректные заголовки на страницах

Документация по title-tag:

Title Tag

Экспорт структуры ACF

Если вы разворачиваете проект на другой среде (или отдаёте тему), важно переносить не только файлы темы, но и структуру полей ACF.

Варианты:

экспортировать группы полей через инструменты ACF (в админке)

хранить поля как JSON (ACF JSON), чтобы структура синхронизировалась через файлы в репозитории

Документация:

Local JSON

Деплой

Деплой — это перенос проекта на сервер. В WordPress-проектах важно помнить: сайт состоит не только из темы.

Что обычно переносится:

файлы WordPress (ядро)

wp-content (тема, плагины, загрузки)

база данных

конфигурация окружения (доступы, домены, кэш)

Стейджинг и прод

Практика, которая сильно экономит нервы: иметь стейджинг (тестовый домен/сервер), где вы проверяете обновления перед продом.

!Простая схема безопасного деплоя через промежуточный стейдж

Что обязательно сделать перед переносом

Сделать резервную копию файлов и базы данных на сервере.

Зафиксировать список активных плагинов и версию PHP на хостинге.

Подготовить перенос домена и ссылок (если меняется домен).

Перенос базы и замена домена

При смене домена недостаточно заменить строки в настройках: ссылки часто лежат в базе.

Чаще всего используют:

миграционный плагин

инструменты хостинга

WP-CLI (если доступен на сервере)

Официальный сайт WP-CLI:

WP-CLI

В WP-CLI есть команда для замены URL по базе, но применять её нужно аккуратно и только понимая последствия.

Как выкатывают тему в реальных проектах

Популярные сценарии:

вы деплоите только тему (и, возможно, mu-plugins), а остальное управляется на сервере

деплоите весь wp-content (тема + плагины), если проект «под ключ»

Ключевое правило: не храните в репозитории папку uploads и не переносите её как часть темы.

После деплоя

Минимальный набор проверок:

сайт открывается, нет фатальных ошибок

меню назначены (внешне часто ломается именно это)

виджеты на месте

постоянные ссылки работают (иногда нужно «пересохранить» структуру)

ACF-поля отображаются и не потерялись

Итог

На этом этапе вы превращаете тему из «натянутой вёрстки» в полноценное решение:

ACF даёт управляемые поля под дизайн

CPT и таксономии создают правильную модель контента

адаптация делает тему устойчивой к реальным данным из админки

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

Если вы хотите усилить следующий уровень качества, то логичное продолжение — внедрить сборку фронтенда (минификация, разделение CSS/JS по страницам), настроить линтеры и организовать обновления через Git-процесс и стейджинг.