Инструменты отладки WordPress, без которых поиск ошибки превращается в угадайку
Если сайт «ломается», не начинайте с переустановки темы. Сначала включите WP_DEBUG и посмотрите error log: там обычно видно, какой файл, функция или плагин падает. Это экономит часы, особенно когда на экране только белая страница или 500 ошибка.
Дальше держите под рукой три инструмента: • Query Monitor — показывает медленные запросы, хуки и PHP-ошибки • Health Check — помогает проверить конфликт плагинов без влияния на посетителей • Browser DevTools — ловит проблемы фронтенда, 404 по ассетам, JS-ошибки и лишние запросы.
Для сложных случаев используйте логирование на уровне сервера: nginx/apache error log и access log. Они полезны, когда WordPress молчит, а проблема лежит в лимите памяти, таймауте, правам на файлы или в стороннем прокси. Если ошибка плавающая, включайте лог только на время проверки, чтобы не засорять диск.
Правило простое: сначала фиксируйте симптомы, потом отключайте лишнее, затем сравнивайте поведение в чистой среде. Так вы быстрее поймёте, виноват код, база, кэш или сервер.
Если сайт «ломается», не начинайте с переустановки темы. Сначала включите WP_DEBUG и посмотрите error log: там обычно видно, какой файл, функция или плагин падает. Это экономит часы, особенно когда на экране только белая страница или 500 ошибка.
Дальше держите под рукой три инструмента: • Query Monitor — показывает медленные запросы, хуки и PHP-ошибки • Health Check — помогает проверить конфликт плагинов без влияния на посетителей • Browser DevTools — ловит проблемы фронтенда, 404 по ассетам, JS-ошибки и лишние запросы.
Для сложных случаев используйте логирование на уровне сервера: nginx/apache error log и access log. Они полезны, когда WordPress молчит, а проблема лежит в лимите памяти, таймауте, правам на файлы или в стороннем прокси. Если ошибка плавающая, включайте лог только на время проверки, чтобы не засорять диск.
Правило простое: сначала фиксируйте симптомы, потом отключайте лишнее, затем сравнивайте поведение в чистой среде. Так вы быстрее поймёте, виноват код, база, кэш или сервер.
WP_DEBUG включают не для «диагностики на глаз», а чтобы ловить ошибки до продакшена
В wp-config.php достаточно поставить:
Но этого мало. Если просто включить вывод ошибок на живом сайте, можно показать посетителям путь к файлам, названия плагинов и детали PHP-сбоев. Для проверки на локалке это нормально, для боевого сайта — нет.
Нормальная связка обычно такая:
• WP_DEBUG — включает режим отладки
• WP_DEBUG_LOG — пишет ошибки в debug.log
• WP_DEBUG_DISPLAY — скрывает вывод на экран
• @ini_set('display_errors', 0); — дополнительно прячет ошибки PHP
Если сайт «падает» после правки темы или плагина, первым делом смотрят debug.log. Там видно, какой файл, строка и тип ошибки сломали страницу. Это быстрее, чем перебирать всё вручную и гадать, где конфликт.
Ещё один важный момент: держать WP_DEBUG включённым постоянно на рабочем сайте не стоит. Лог разрастается, а лишние записи мешают искать реальную причину. Включайте его точечно: перед заменой шаблона, после установки плагина, при проверке формы или AJAX-запроса.
Если нужен чистый и безопасный разбор ошибок, включайте логирование, а вывод на экран прячьте. Так WordPress помогает чинить сайт, а не подставляет его.
В wp-config.php достаточно поставить:
define('WP_DEBUG', true);Но этого мало. Если просто включить вывод ошибок на живом сайте, можно показать посетителям путь к файлам, названия плагинов и детали PHP-сбоев. Для проверки на локалке это нормально, для боевого сайта — нет.
Нормальная связка обычно такая:
• WP_DEBUG — включает режим отладки
• WP_DEBUG_LOG — пишет ошибки в debug.log
• WP_DEBUG_DISPLAY — скрывает вывод на экран
• @ini_set('display_errors', 0); — дополнительно прячет ошибки PHP
Если сайт «падает» после правки темы или плагина, первым делом смотрят debug.log. Там видно, какой файл, строка и тип ошибки сломали страницу. Это быстрее, чем перебирать всё вручную и гадать, где конфликт.
Ещё один важный момент: держать WP_DEBUG включённым постоянно на рабочем сайте не стоит. Лог разрастается, а лишние записи мешают искать реальную причину. Включайте его точечно: перед заменой шаблона, после установки плагина, при проверке формы или AJAX-запроса.
Если нужен чистый и безопасный разбор ошибок, включайте логирование, а вывод на экран прячьте. Так WordPress помогает чинить сайт, а не подставляет его.