Коротко: логи ошибок WordPress: Для проверки логов ошибок WordPress добавьте константы WP_DEBUG и WP_DEBUG_LOG в wp-config.php, после чего записи появятся в /wp-content/debug.log. Ошибки уровня PHP или веб-сервера смотрите в error_log (корень сайта или раздел «Журнал ошибок» в панели хостинга). Используйте Query Monitor для быстрого анализа на лету и всегда отключайте вывод ошибок на экран на боевом сайте.
Логи ошибок WordPress — это первый инструмент диагностики, если сайт падает, выдаёт белый экран или работает нестабильно. Правильно настроенный доступ к файлам debug.log и серверному error_log позволяет быстро найти источник проблемы без гадания. Рассказываем, как включить, найти и интерпретировать записи, даже если нет опыта администрирования.
Основные причины
| Причина | Что это значит |
|---|---|
| Конфликт плагинов или темы после обновлений | Новое обновление может содержать код, несовместимый с другими плагинами или текущей версией WordPress, вызывая фатальные ошибки в момент загрузки. |
| Исчерпание лимита памяти PHP | Если скрипт запрашивает больше памяти, чем выделено в php.ini или wp-config.php, PHP аварийно завершается с ошибкой allowed memory size exhausted. |
| Синтаксические ошибки в .htaccess или wp-config.php | Опечатка, лишний пробел или неправильная директива в этих файлах приводят к ошибкам 500, которые фиксируются в серверном логе. |
| Несовместимость версии PHP | Старая тема или плагин могут использовать функции, удалённые в более новой версии PHP, вызывая критические сбои класса 'undefined function'. |
| Ошибки подключения к базе данных | Неверные учётные данные MySQL, перегрузка сервера БД или повреждение таблиц порождают записи о невозможности установить соединение. |
| Проблемы с правами доступа (chmod) и владельцем файлов | Если веб-сервер не может записать файл лога или временные данные из-за неправильных разрешений, ошибки остаются незафиксированными, а сам сайт выдаёт предупреждения. |
| Вредоносный код или некорректные редиректы | Зловредное ПО, вставленное через уязвимость, может создавать бесконечные циклы или изменять заголовки, что отражается как warning и notice в логах. |
Что проверить сначала
- Убедитесь, что в wp-config.php константы WP_DEBUG и WP_DEBUG_LOG установлены в true, а WP_DEBUG_DISPLAY в false.
- Проверьте наличие файла /wp-content/debug.log и его размер; если файла нет, ищите ошибки в правах записи.
- Проверьте права на папку wp-content: они должны быть 755 или 775, а владелец — пользователь, от которого работает веб-сервер (например, www-data).
- Осмотрите error_log в корне сайта, а также в подпапках — некоторые хостинги кладут отдельный лог в /wp-admin/.
- В панели управления хостингом откройте раздел «Журналы ошибок» или «Error Log» — там видны проблемы уровня сервера, не доходящие до WordPress.
- Временно активируйте плагин Query Monitor и перейдите на проблемную страницу, чтобы увидеть ошибки PHP и запросы в реальном времени.
- Просмотрите файл .htaccess на предмет синтаксических ошибок — одна неверная строка может вызвать ошибку 500.
- С помощью функции phpinfo() проверьте актуальный лимит memory_limit и при необходимости увеличьте его в php.ini или wp-config.php.
Пошаговое решение
- Подключитесь к серверу по FTP, SFTP или через файловый менеджер хостинга.
- В корневой директории WordPress откройте файл 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);
- Сохраните изменения и загрузите файл обратно на сервер.
- Воспроизведите ошибку — обновите страницу, где наблюдается сбой, или выполните действие, вызывающее проблему.
- Через FTP или файловый менеджер перейдите в папку /wp-content/ и найдите файл debug.log.
- Скачайте или откройте debug.log в текстовом редакторе; записи отсортированы по дате — последние события внизу.
- Анализируйте сообщение: обратите внимание на тип ошибки (Fatal error, Warning, Notice) и путь к файлу, где она возникла.
- Если debug.log пуст, проверьте права на запись — папка wp-content должна принадлежать пользователю веб-сервера с маской 755.
- Для ошибок вне WordPress откройте error_log сервера: в cPanel через раздел «Метрики → Ошибки», либо найдите файл error_log в корне сайта.
- При поиске причины сравните временные метки лога с моментом активации плагинов; временно деактивируйте подозрительные расширения через админку или переименовав папку плагинов.
- После диагностики на боевом сайте сразу верните WP_DEBUG в false или удалите отладочные константы, чтобы избежать замедления и утечки данных.
Проверить ошибку WordPress
Введите ошибку WordPress, PHP, плагина, темы, REST API или кратко опишите проблему сайта.
FAQ
Где WordPress хранит файл с ошибками по умолчанию?
После включения WP_DEBUG_LOG записи сохраняются в /wp-content/debug.log. Вы можете задать произвольный путь, указав абсолютный путь в define('WP_DEBUG_LOG', '/полный/путь/к/файлу.log').
Чем отличаются логи ошибок WordPress и серверные логи PHP?
WordPress-лог фиксирует ошибки уровня PHP, возникающие при обработке запросов к самой CMS: конфликты плагинов, проблемы с памятью, синтаксические ошибки в коде тем. Серверный error_log включает также ошибки веб-сервера (Apache/Nginx), например, некорректные правила .htaccess, проблемы с модулями PHP, превышение времени выполнения.
Включение WP_DEBUG замедляет сайт?
Сама запись в лог создаёт небольшую дополнительную нагрузку на диск. Однако на высоконагруженном проекте постоянная запись всех предупреждений и уведомлений может снизить производительность, поэтому отладку рекомендуется включать временно и отключать после решения проблемы.
Как прочитать большой debug.log, если он перегружен повторяющимися ошибками?
Используйте поиск по ключевым словам (в текстовом редакторе или через grep в SSH): grep 'Fatal error' /wp-content/debug.log, чтобы отфильтровать только критические сбои, или удалите старый лог, воспроизведите ошибку заново и читайте «свежие» данные.
Безопасно ли оставлять WP_DEBUG включённым на боевом сайте?
Нет. Вывод ошибок на экран (WP_DEBUG_DISPLAY = true) раскрывает пути файловой системы и может использоваться злоумышленниками. Даже при отключённом выводе постоянная запись в debug.log расходует дисковое пространство и может замедлить запись при большом количестве уведомлений. Всегда отключайте отладку после диагностики.
Что делать, если ошибка возникает только при определённых действиях, но не попадает в debug.log?
Проверьте, не отключён ли вывод ошибок на уровне сервера (display_errors и error_reporting в php.ini). Попробуйте явно указать define('WP_DEBUG_LOG', dirname(__FILE__) . '/wp-content/debug.log') и убедитесь, что в wp-config.php нет дублирующихся определений констант. Дополнительно включите расширенный режим define('WP_DEBUG', true); define('SCRIPT_DEBUG', true); и повторите проблемное действие.
Итог
Регулярный мониторинг логов ошибок WordPress и PHP — залог быстрой диагностики и стабильной работы сайта. Научившись включать отладку и читать записи, вы сможете самостоятельно выявлять конфликты плагинов, проблемы с памятью и серверные ограничения. Даже если файл debug.log пуст, проверьте журнал ошибок хостинга — часто критический сбой фиксируется именно там. Используйте полученные данные для дальнейшего анализа или передайте их специалисту, но не забывайте отключать отладку после завершения работ.