Дочерняя тема WordPress: как сохранить изменения при обновлении

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

Сначала найдите настоящий источник оформления

Составьте карту изменений: логотип, типографика, шапка, карточка услуги, форма, дополнительные поля. Для каждого пункта запишите источник: настройка темы, файл, дополнительный CSS, редактор сайта, плагин или конструктор. Сделайте снимки ключевых страниц и сохраните конфигурацию. Нельзя надёжно переносить то, что существует только в памяти прежнего исполнителя.

В классической теме шаблоны обычно написаны на PHP. В блочной теме используются блочные шаблоны и настройки theme.json. При этом сохранённые через редактор сайта пользовательские изменения могут находиться в базе данных и перекрывать файлы темы. Поэтому отсутствие эффекта после правки файла ещё не доказывает, что дочерняя тема подключена неправильно. Проверьте, нет ли у данного шаблона сохранённой пользовательской версии. Иерархия и основные правила описаны в руководстве WordPress по дочерним темам.

Выберите границу между темой и функциональностью

• Цвета, интервалы, оформление карточки и её шаблон относятся к представлению и могут жить в дочерней теме.
• Регистрация раздела «Объекты», правила расчёта, интеграция с внешней системой и права доступа должны переживать смену оформления. Для них лучше отдельный проектный плагин.
• Небольшая настройка, уже поддерживаемая интерфейсом темы, не обязательно требует копирования файла.
• Если приходится переписывать почти каждый шаблон, оцените поддержку самостоятельной темы: зависимость от родителя может перестать приносить пользу.

Например, у вымышленного производителя на карточке объекта появился блок «Оборудование». Его данные нельзя хранить только внутри шаблона: при следующем редизайне исчезнет способ их редактирования. Раздел и поля остаются в проектном плагине, а дочерняя тема отвечает лишь за вывод. Это проектный пример, а не описание результатов клиента.

Переносите только собственную разницу

1. На тестовой копии сохраните текущую тему и получите чистую поставку той же версии. Сравните файлы, чтобы отделить собственные изменения от исходного кода.
2. Создайте дочернюю тему. Поле Template в заголовке style.css должно точно соответствовать имени папки родителя. Проверьте, что родитель действительно установлен.
3. Перенесите необходимое переопределение, сохранив ожидаемый путь. Для каждой копии запишите исходную версию файла и причину изменения.
4. Проверьте подключение стилей в конкретной родительской теме. Универсальная вставка двух stylesheet может дать двойную загрузку; некоторые блочные темы вообще не используют style.css для основного оформления.
5. Не копируйте functions.php целиком: загружаются оба файла функций, а повторное объявление функции способно остановить сайт. Добавляйте только собственные обработчики с уникальными именами; назначение этого слоя разобрано в руководстве по функциональности темы.
6. После активации проверьте назначения меню, логотип, области виджетов и настройки оформления: их поведение зависит от темы и способа хранения.

Что делать с правками редактора сайта

Допустим, файл шапки уже обновлён, но посетитель видит старую кнопку. Сначала откройте соответствующий шаблон или часть шаблона в редакторе и установите, существует ли пользовательская версия. Экспортируйте или иным проверенным способом сохраните её перед сбросом. Затем на копии решите, что станет источником истины: версионируемый файл либо управляемая редакторами запись в базе. Модель файлов и пользовательских версий следует сверить с документацией по шаблонам.

Не сбрасывайте все пользовательские шаблоны ради одной кнопки. Вместе с проблемным фрагментом можно потерять согласованные изменения подвала или страницы контактов. Если оформление редактирует несколько человек, договоритесь, какие области меняются через код и какие через интерфейс; иначе следующая выгрузка снова создаст расхождение.

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

Проверка состоит не в том, что тема активировалась. Выберите по одному образцу каждого изменённого шаблона, включая пустое состояние и длинный заголовок. Откройте их без авторизации на узком и широком экране; сравните с редактором. Проверьте ссылки, форму, меню, ошибки PHP и отсутствующие файлы. Для CSS убедитесь, что собственные правила реально загружены и не маскируются старым кэшем.

Затем установите новую версию родителя на копии и сравните именно переопределённые файлы с новой поставкой. Успех означает, что собственная правка сохранилась, нужные исправления родителя учтены, а бизнес-функции не зависят от активной темы. Если конфликт связан с одной копией шаблона, исправляют эту копию, а не бессрочно замораживают всё оформление.

Граница отката должна быть явной. Возврат файлов дочерней темы не возвращает изменения редактора сайта в базе; переключение на родителя временно убирает собственные переопределения. Полное восстановление базы поверх новых заявок или публикаций недопустимо без плана их сохранения. До переноса подготовьте отдельные версии файлов и затронутых настроек, чтобы возвращать только изменённый слой.

Короткая памятка владельцу

• Есть список переопределений с назначением и ответственным.
• Известно, какие шаблоны хранятся в базе и какие в файлах.
• Смена темы не удаляет доступ к важным бизнес-данным.
• Обновление родителя проверяется по конкретным изменённым экранам.
• Возврат оформления отрепетирован без потери нового содержимого.