После обновления темы или плагина в WordPress часто остаются куски старого PHP-кода: в functions.php, в сниппетах из плагина для кода, в дочерней теме или в самописном плагине. На первый взгляд сайт работает, но в логах уже копятся deprecated-предупреждения, часть хуков не срабатывает, а при следующем обновлении всё ломается окончательно. В этой статье разберём, как безопасно найти такой код, закрыть его и проверить, что ничего лишнего не осталось.
Когда проблема уже есть и как её распознать
Старый код обычно всплывает не сразу. Типичные признаки: в debug.log появляются сообщения о вызове устаревших функций, на страницах админки растёт число предупреждений, а после обновления темы пропадают части шаблона или настройки перестают применяться. Если код был вставлен через плагин сниппетов, он может продолжать выполняться даже после того, как вы забыли, где именно он лежит.
Проверять нужно не только фронтенд. Иногда проблема сидит в админке: старый фильтр меняет список полей, ломает REST-ответы или мешает сохранению записей. Поэтому сначала ищем источник, а потом уже удаляем.
Что смотреть в первую очередь
wp-content/debug.log, если включёнWP_DEBUG_LOG;- дочернюю тему и её
functions.php; - самописные плагины в
wp-content/plugins; - плагины для вставки PHP-сниппетов;
- файлы шаблонов, куда код был перенесён вручную.
Диагностика: где именно живёт устаревший код
Если у вас есть доступ по SSH, самый быстрый способ — поиск по проекту. Ищите не только имя функции, но и старые фильтры, классы и хук-имена, которые вы уже заменили в новой версии темы или плагина.
grep -Rni "old_function_name\|deprecated_hook\|legacy_class" wp-content/Если SSH нет, используйте поиск по файлам в панели хостинга или временно отключайте подозрительные плагины по одному. Важно делать это на копии сайта или в staging-окружении, а не на боевом проекте.
Полезно сравнить текущую версию темы с резервной копией до обновления. Часто оказывается, что старый код не удалили после переноса логики в плагин, и теперь он дублируется в двух местах.
Пошаговое решение: как убрать код без лишних рисков
Ниже рабочая последовательность, которая помогает не сломать сайт в процессе чистки.
1. Сделайте резервную копию файлов и базы
Это не формальность. Если старый код завязан на метаполя, опции или кастомные типы записей, откат может понадобиться не только для файлов, но и для базы. Минимум — архив wp-content и дамп базы.
2. Отключите источник кода, а не удаляйте всё сразу
Если код лежит в отдельном плагине, сначала деактивируйте его. Если это functions.php дочерней темы, временно закомментируйте блок и проверьте сайт. Так проще понять, что именно сломалось: сам код или зависимость от него.
3. Перенесите нужную логику в актуальное место
Если часть логики ещё нужна, лучше вынести её в небольшой собственный плагин. Тогда она не исчезнет при смене темы. Для простых задач достаточно одного файла.
<?php
/**
* Plugin Name: Site Cleanup Snippets
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
add_action( 'init', function () {
// Актуальная логика вместо старого кода из темы.
} );Такой подход удобнее, чем держать бизнес-логику в шаблоне. Шаблон отвечает за вывод, плагин — за поведение.
4. Удалите дублирующиеся хуки и фильтры
Если старый код и новый код одновременно вешаются на один и тот же хук, результат может быть непредсказуемым. Особенно это заметно на фильтрах, где каждый следующий обработчик меняет уже изменённое значение.
remove_filter( 'the_content', 'old_content_filter', 20 );
add_filter( 'the_content', 'new_content_filter', 20 );Перед удалением проверьте приоритет. Если он не совпадает, remove_filter() не сработает. Это частая причина, почему «код удалили, а он всё равно выполняется».
Сравнение подходов: плагин, код в теме или отдельный мини-плагин
| Вариант | Когда подходит | Минус |
|---|---|---|
| Код в дочерней теме | Мелкая правка, завязанная на шаблон | Пропадёт при смене темы |
| Плагин сниппетов | Быстро отключить без FTP | Сложнее контролировать зависимости |
| Собственный мини-плагин | Логика должна жить независимо от темы | Нужно один раз аккуратно оформить структуру |
Если код влияет на контент, REST API, обработку форм или админку, отдельный плагин обычно надёжнее. Если это чисто визуальная правка шаблона, можно оставить в теме, но только если вы уверены, что тема не будет меняться.
Проверка результата после внедрения
После удаления старого кода важно не ограничиваться визуальной проверкой главной страницы. Пройдитесь по тем местам, где логика реально использовалась.
- Откройте проблемную страницу и проверьте, нет ли PHP-warning в HTML-ответе.
- Посмотрите
debug.logпосле нескольких переходов по сайту. - Проверьте сохранение записи в админке, если код работал с метаполями.
- Если код влиял на REST API, сделайте запрос к нужному эндпоинту и сравните ответ.
- Очистите кеш, если он есть на сервере, в плагине или на CDN.
Для быстрой проверки можно временно включить логирование в staging-окружении:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Если после этого лог чистый, а нужные функции работают, значит старый код действительно закрыт, а не просто спрятан.
Частые ошибки и как их исправить
Код удалили, но сайт всё ещё ведёт себя по-старому
Чаще всего виноват кеш: объектный кеш, page cache, CDN или даже кеш браузера. Сначала очищайте кеш на всех уровнях, потом проверяйте результат. Ещё одна причина — код дублируется в двух местах, например в дочерней теме и в плагине сниппетов.
remove_action() не срабатывает
Почти всегда проблема в приоритете или в том, что удаление вызывается раньше, чем исходный add_action(). В таких случаях удаление нужно выполнять позже, например на after_setup_theme или init, в зависимости от того, где был добавлен хук.
После чистки сломалась часть админки
Это значит, что код был не декоративным, а функциональным. Не возвращайте его вслепую. Сначала найдите, какие данные он читал или писал, и перенесите только нужную часть в актуальный плагин или в новый обработчик.
Удалили файл, но ошибка осталась
Проверьте автозагрузку, mu-plugins и копии файлов в нестандартных директориях. На живых проектах старые куски кода часто лежат не там, где их ожидают искать.
Практические советы по безопасности и производительности
Старый PHP-код — это не только технический долг, но и лишняя нагрузка. Каждый неиспользуемый хук, фильтр и запрос к базе добавляет шум. Если вы регулярно обновляете тему или плагины, держите пользовательские правки отдельно от шаблонов и документируйте, что и зачем было изменено.
Для проектов, где много мелких правок, удобно использовать отдельный плагин для служебных сниппетов. А если задача шире и связана с чисткой сайта, дублями, отключением лишнего мусора и базовой SEO-гигиеной, имеет смысл посмотреть на инструменты вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с таким плагином логику лучше не смешивать с оформлением темы.
Главное правило простое: если код нужен для работы сайта, он должен жить в месте, которое не исчезнет при смене дизайна. Если код больше не нужен — удаляйте его полностью, а не оставляйте закомментированным «на всякий случай».