Инструменты отладки WordPress

Отладка WordPress – поиск и исправление ошибок, сбоев и узких мест на сайте. Без неё легко получить белый экран, медленные страницы, сломанный функционал или дыры в безопасности. Ниже – рабочий набор: встроенные константы, логи, консоль браузера, Debug Bar, Query Monitor, статический анализ и Xdebug.

Коротко

• Включите WP_DEBUG и WP_DEBUG_LOG на staging; на проде – осторожно и без вывода на экран.
• Консоль браузера ловит JS/CSS и сетевые сбои.
• Debug Bar и особенно Query Monitor показывают SQL, память, хуки и загруженные скрипты.
• Для глубокого PHP – Xdebug; для качества кода – PHP_CodeSniffer / PHPCS под WordPress Coding Standards.
• Сканеры вроде WPScan помогают искать известные уязвимости, но не заменяют обновления и бэкапы.

---

Основные инструменты

На практике обычно комбинируют несколько уровней:

1. Консоль разработчика в браузере – инспектор DOM, Console, Network, Sources. Нужна для JS-ошибок, 404 по ассетам, CORS, странных стилей.
2. Плагин Debug Bar – панель в админке с запросами, памятью, временем и связанными аддонами.
3. Логи WordPress – файл wp-content/debug.log (и логи PHP/веб-сервера) с типом ошибки, файлом и строкой.
4. Query Monitor – детальный разбор SQL, HTTP API, хуков, скриптов, стилей, capability-проверок.
5. Проверка кода – PHP_CodeSniffer, PHPMD и WPCS для стиля и типичных косяков до выкладки.
6. Xdebug – breakpoints, step-by-step, просмотр переменных в IDE.
7. Безопасность – WPScan, журналы аудита (например, WP Activity Log) для известных CVE и подозрительных действий.

---

Консоль разработчика в браузере

Открывается через ПКМ – «Просмотреть код» / «Inspect» или F12. Вкладки, которые чаще всего нужны на WP-сайте:

• Console – ошибки и предупреждения JavaScript, можно гонять console.log().
• Elements / Inspector – DOM и computed-стили; удобно ловить конфликты CSS темы и плагинов.
• Network – статусы запросов, время, размер; видно, какой плагин тянет тяжёлый скрипт или падает REST/AJAX.
• Sources – breakpoints в JS, пошаговый разбор фронтенда.

Типичный маршрут: открыли проблемную страницу, смотрим красные ошибки в Console, параллельно фильтруем Network по XHR/Fetch и статусам 4xx/5xx. Если «плывёт» вёрстка – сравниваем классы в Elements с ожидаемыми стилями темы.

---

Встроенный debug и логи

Базовая среда отладки включается в wp-config.php до строки /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Что делает каждая константа:

• WP_DEBUG – режим отладки ядра, тем и плагинов (notices, warnings, deprecated).
• WP_DEBUG_LOG – пишет сообщения в wp-content/debug.log.
• WP_DEBUG_DISPLAY – вывод на экран; на проде почти всегда false, иначе посетители увидят пути и stack trace.

Смотреть лог можно так:

tail -f wp-content/debug.log
# или последние строки
tail -n 100 wp-content/debug.log

В записи обычно есть уровень (Notice, Warning, Fatal), файл, строка и иногда стек. «Undefined function» чаще всего значит: плагин или тема не загружены, опечатка в имени или вызов до plugins_loaded. После разбора на staging отключите debug на проде или оставьте только лог без display.

---

Плагин Debug Bar

Debug Bar добавляет панель отладки в админ-бар. После установки и активации появляется вкладка Debug с блоками вроде Database, Memory, Queries (набор зависит от аддонов).

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

На проде Debug Bar лучше не держать постоянно: лишняя нагрузка и риск утечки служебной информации, если кто-то получит доступ к админке. Идеальное место – локалка и staging.

---

Query Monitor

Query Monitor – один из самых полезных плагинов для разбора «почему сайт тормозит» и «кто дергает базу».

После активации в админ-баре появляется сводка. Типичные разделы:

• Database Queries – список SQL, время, caller (какой файл или функция вызвал запрос), дубликаты.
• Memory / Timing – пики памяти и время генерации.
• Scripts & Styles – что подключено, откуда, зависимости.
• Hooks & Actions – какие callbacks висят на хуках.
• HTTP API – исходящие запросы (часто виновники таймаутов).
• PHP Errors – notices и warnings на текущем запросе.

Практика: откройте медленную страницу, отсортируйте запросы по времени, найдите N+1 (десятки похожих SELECT) или тяжёлый meta_query без индексов. Параллельно смотрите, не тянет ли тема десять шрифтов и три jQuery-плагина на главной. Query Monitor видно только пользователям с правом view_query_monitor (по умолчанию администраторам) – всё равно не оставляйте его на проде без необходимости.

---

Качество кода и Xdebug

PHP_CodeSniffer с правилами WordPress Coding Standards ловит отступы, неэкранированный вывод, устаревшие функции и стиль до того, как код попадёт на сервер. PHPMD (mess detector) подсвечивает сложность, мёртвый код и слишком длинные методы.

Xdebug подключают к PHP-FPM/CLI и IDE (PhpStorm, VS Code). Ставите breakpoint, воспроизводите сценарий в браузере, смотрите стек и переменные. На проде Xdebug обычно выключен: сильно бьёт по производительности. Для профилирования отдельно смотрят trace/profiler и инструменты вроде Blackfire или Tideways, если нужна уже «боевая» метрика.

---

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

• Не включайте WP_DEBUG_DISPLAY на боевом сайте.
• Закройте debug.log от веб-доступа (права, deny в nginx/apache, или перенос лога вне document root через ini_set('error_log', ...)).
• WPScan и аудит-логи – дополнение к обновлениям ядра, тем и плагинов, а не замена.
• Отладочные плагины на проде – только временно и под админом.

---

Частые вопросы

Что такое отладка WordPress?
Поиск причин сбоев и деградации: PHP/JS ошибки, SQL, конфликт плагинов, неверная конфигурация, проблемы кэша и прав.

С чего начать, если «белый экран»?
Логи PHP и debug.log, временно WP_DEBUG на staging-копии, отключение последних плагинов или темы, проверка лимитов памяти и версии PHP.

Debug Bar или Query Monitor?
Для повседневной работы чаще хватает Query Monitor: он глубже по SQL, HTTP и ассетам. Debug Bar полезен как лёгкая панель и база для аддонов.

Можно ли отлаживать только на проде?
Технически да, но рискованно. Лучше копия сайта (staging) с теми же PHP и плагинами. На проде – точечно, с логом без display и с быстрым откатом.

---

Соберите минимум: WP_DEBUG_LOG на staging, консоль браузера и Query Monitor. Этого уже достаточно, чтобы закрывать большинство инцидентов без гадания. Xdebug и статический анализ подключайте, когда правите собственный код темы или плагина.

Источники и ссылки