Рефакторинг старой темы WordPress: что внутри и что ломается

Пять лет правок превращают тему WordPress в систему скрытых зависимостей: один шаблон выводит данные, другой меняет запрос, а подключённый плагин рассчитывает на конкретный CSS-класс. Если переписать всё сразу, ошибка может затронуть не только внешний вид, но и меню, архивы, метаданные и редактор. Для WordPress 6.x безопаснее сначала построить карту связей, затем менять один слой за раз и сравнивать поведение до и после.

Сначала выясните, что именно вы называете темой

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

Это различие важно при рефакторинге. Если код отвечает за конкретный сайт и должен работать даже после смены оформления, держать его в теме рискованно: смена темы отключит этот код. Но переносить всё в плагин тоже не стоит. Разметка карточки товара или настройка ширины контента относятся к представлению и обычно должны оставаться на стороне темы.

Тема WordPress — набор файлов, который определяет представление сайта и может регистрировать поддерживаемые WordPress возможности. В этой статье речь о классической теме и смешанных проектах на WordPress 6.x; для блочной темы с шаблонами в HTML и каталогом блоков план работ будет отличаться.

Как устроен клубок зависимостей

Шаблоны и иерархия запросов

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

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

Хуки, запросы и вывод данных

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

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

Рефакторинг старой темы начинается не с удаления лишних файлов, а с ответа на вопрос: кто заметит, если этот файл исчезнет?

Что измерять до изменений

Если в проекте нет зафиксированных замеров, не придумывайте «ускорение на 30%». Сначала выберите несколько типичных страниц и измерьте их в одинаковых условиях: одна и та же версия WordPress и PHP, одинаковые плагины, сопоставимый кеш и одинаковое состояние базы данных. Зафиксируйте время ответа сервера, количество запросов к базе, размер HTML и ошибки в журнале. Сравнение имеет смысл только при неизменных условиях.

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

Как разбирать тему без переписывания вслепую

1. Зафиксируйте исходное состояние. Сохраните копию файлов и базы, запишите версии WordPress и PHP, список активных плагинов и настройки постоянных ссылок. Проверьте, что копию можно развернуть на тестовом окружении. Проверка: сайт на копии открывается и повторяет ключевые страницы.
2. Составьте карту шаблонов. Перечислите типы страниц, соответствующие им файлы и общие части разметки. Не предполагайте назначение файла только по имени — сверьте его с реальным выводом на сайте. Проверка: для каждого важного типа страницы понятен путь от запроса до шаблона.
3. Отделите представление от поведения. Отметьте в шаблонах запросы к данным, обработку настроек и регистрацию функций. Решите, что относится к отображению, а что должно пережить смену темы. Проверка: у каждой найденной функции есть владелец — тема, плагин или иной слой проекта.
4. Выберите один ограниченный участок. Например, общий вывод карточек записей или повторяющуюся шапку. Перенесите его без одновременной смены стилей, запроса данных и поведения редактора. Проверка: контрольные страницы показывают те же данные и не теряют нужные элементы.
5. Сравните результат и только потом продолжайте. Проверьте ошибки PHP, консоль браузера, выбранные метрики и чек-лист страниц. Если изменилось время ответа, повторите замер при тех же условиях. Проверка: изменение объяснимо, а неожиданных отличий в поведении нет.

Где рефакторинг обычно ломается

В теме спрятана логика сайта

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

Новый шаблон выглядит похоже, но ведёт себя иначе

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

Обновление WordPress меняет контекст проверки

Результат теста зависит от версии WordPress, PHP, активных плагинов и используемых редакторов. Запишите эти версии перед работой и повторяйте тестирование в том же окружении. Не переносите выводы о блочной теме на классическую: расположение шаблонов и способ формирования разметки у них различаются.

Когда выбирать каждый подход

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

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

Что делать дальше

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