Инструменты отладки 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 достаточно поставить:
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 помогает чинить сайт, а не подставляет его.

Ошибки базы данных в WordPress: 6 причин, которые ломают сайт чаще всего

Если вместо сайта видите “Error establishing a database connection”, не начинайте с паники. Сначала проверьте три вещи: имя базы, логин и пароль в wp-config.php; доступность MySQL-сервера; совпадает ли префикс таблиц с тем, что есть в базе.

Частые причины сбоя:
• База удалена или повреждена после миграции
• Неверный пароль пользователя БД
• Закончились права на чтение таблиц
• Сломана одна из таблиц, обычно после некорректного выключения сервера

Если ошибка появляется не на всем сайте, а только в админке или при входе, часто проблема в одной таблице или в поврежденном кэше соединения. В таком случае помогает проверка через phpMyAdmin или запуск ремонта базы через define('WP_ALLOW_REPAIR', true); с последующим удалением строки из конфигурации.

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

Начинайте диагностику с wp-config.php и состояния MySQL: в 80% случаев ошибка базы данных находится именно там, а не в “сломавшемся WordPress”.

—
Соседний канал в сети: @affcareers_almaty