Коротко: включить отладку WordPress: если вы не можете попасть в админку WordPress, откройте файл wp-config.php через FTP, файловый менеджер хостинга или SSH. Добавьте в него константы WP_DEBUG и WP_DEBUG_LOG, чтобы ошибки сохранялись в debug.log внутри папки wp-content, а не выводились на экран. После воспроизведения проблемы в логе появится детальное описание сбоя, которое укажет на неисправный плагин, тему или PHP-фатальную ошибку.
Когда сайт на WordPress перестаёт открываться, а стандартный вход в панель управления недоступен, включить отладку WordPress становится единственным способом понять, что случилось. Ошибка может проявляться «белым экраном смерти» или сообщением о критической ошибке, при этом привычный интерфейс wp-admin не грузится. В этой ситуации единственный путь — активировать режим отладки напрямую через файлы сайта, чтобы записать технические сообщения в лог и выяснить причину сбоя.
Что понадобится
- Доступ к файловой системе хостинга: FTP-клиент, SSH-консоль или файловый менеджер в панели управления (cPanel, ISPmanager и т. п.)
- Права на редактирование файла wp-config.php (обычно chmod 644)
- Резервная копия wp-config.php перед внесением изменений
- Возможность повторно зайти на сайт или обратиться к файлам через тот же канал, чтобы просмотреть wp-content/debug.log
Почему отладку приходится включать в обход админки
Обычно параметры отладки WordPress можно менять через плагины в консоли, но если сайт «лёг», панель администратора недоступна. Причиной могут быть фатальные ошибки PHP, конфликты плагинов, несовместимость темы или исчерпание лимита памяти. Без возможности открыть wp-admin остаётся только прямое редактирование файлов на сервере.
Режим отладки даёт детальный лог ошибок, по которому можно точно определить, какой именно компонент вызывает сбой. Это намного эффективнее, чем гадать и последовательно отключать расширения.
Где взять доступ к wp-config.php
Файл wp-config.php находится в корневой папке установки WordPress. Чтобы его отредактировать, нужны учётные данные FTP или доступ к файловому менеджеру в панели хостинга. Если сайт размещён на управляемом хостинге, зайдите в cPanel, DirectAdmin или ISPmanager, откройте «Диспетчер файлов» и перейдите в директорию public_html или ту, что указана как корневая для сайта.
Для серверов с SSH-доступом можно подключиться по протоколу SFTP через любой клиент, например FileZilla или WinSCP, и сразу перейти к редактированию. Убедитесь, что у файла стоят корректные права — обычно достаточно 644.
Важно: Перед редактированием обязательно скачайте резервную копию wp-config.php — она позволит откатить изменения, если вы случайно допустите синтаксическую ошибку.
Добавление констант отладки в wp-config.php
Чтобы активировать запись ошибок, нужно определить три константы. Откройте wp-config.php в любом текстовом редакторе, найдите строку /* That's all, stop editing! Happy blogging. */ и добавьте код перед ней.
- Константа WP_DEBUG включает режим отладки.
- WP_DEBUG_LOG указывает, что ошибки нужно писать в файл debug.log внутри wp-content.
- WP_DEBUG_DISPLAY отключает показ ошибок на экране — это важно для безопасности и сохранения внешнего вида сайта.
- Войдите на сервер любым удобным способом и откройте wp-config.php для редактирования.
- Найдите строку require_once ABSPATH . 'wp-settings.php'; или комментарий /* That's all, stop editing! Happy blogging. */ — код отладки вставляется до неё.
- Добавьте три строки: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);
- Проследите, чтобы каждая константа была на отдельной строке, не было лишних символов и все кавычки прямые.
- Сохраните файл и загрузите его обратно на сервер, заменив оригинал.
Важно: Если в вашем wp-config.php отсутствует строка-ориентир, вставьте константы сразу после открывающего тега
Как найти и прочитать файл debug.log
После загрузки обновлённого wp-config.php перейдите на любую страницу сайта — это воспроизведёт ошибку. Затем вернитесь к файловому менеджеру или FTP-клиенту и откройте папку wp-content. Там должен появиться файл debug.log. Он содержит текстовые записи о возникших ошибках с указанием точного файла, строки и описания причины.
Чаще всего в логе будет запись вида Fatal error: … in /home/user/public_html/wp-content/plugins/plugin-name/plugin-file.php on line X. Эта информация прямо указывает на проблемный плагин или тему.
Важно: Если debug.log не появился, возможно, у веб-сервера нет права на запись в wp-content. Установите на папку права 755, а при необходимости и 777 (с последующим возвратом 755 после завершения диагностики) — тогда файл создастся.
Проверка работы отладки и первые действия с логом
Убедиться, что режим работает, можно, временно вставив в конец functions.php активной темы строку trigger_error('Test debug', E_USER_NOTICE); и обновив сайт. Если после этого в debug.log появилась тестовая запись, всё настроено верно. Затем сразу удалите тестовый код, иначе ошибка будет мешать чтению основного лога.
- Откройте debug.log через текстовый редактор или файловый менеджер, прокрутите до последних записей.
- Обратите внимание на тип ошибки — Fatal error, Warning, Parse error — и на путь к файлу.
- По идентификатору плагина или темы в пути определите, какой компонент нужно временно деактивировать.
- Не редактируйте файлы ядра WordPress напрямую; начните с переименования папки проблемного плагина, например, добавьте к названию суффикс _disabled.
Важно: Если ошибка ссылается на ядро WordPress, чаще всего корень в нехватке памяти PHP или повреждённых файлах. Попробуйте перезагрузить обновление ядра вручную, залив свежие файлы wp-admin и wp-includes.
Отключение отладки и наведение порядка
Как только причина сбоя найдена и устранена, режим отладки необходимо выключить и удалить следы диагностики. Оставленный включённым WP_DEBUG замедляет сайт, а файл debug.log со временем может занять много места и раскрыть структуру каталогов посторонним.
- Снова откройте wp-config.php и замените define('WP_DEBUG', true); на define('WP_DEBUG', false); или закомментируйте все три добавленные строки.
- Удалите файл wp-content/debug.log через файловый менеджер или FTP.
- Если вы временно переименовывали папки плагинов, восстановите их обратно и зайдите в здоровую админку для активации только нужных расширений.
- Проверьте, что сайт открывается без ошибок и админка доступна.
Важно: Никогда не оставляйте активными WP_DEBUG и WP_DEBUG_LOG на боевом сайте — для постоянного мониторинга используйте специальные решения, которые записывают ошибки без прямой раздачи debug.log.
Проверка результата
- Убедитесь, что файл wp-config.php редактируется без синтаксических ошибок: отсутствуют лишние символы до
- Проверьте права доступа к папке wp-content — веб-сервер должен иметь возможность создавать в ней файлы (разрешения 755, при необходимости временно 777).
- Если debug.log пуст или не создаётся, загляните в основной лог ошибок PHP (error_log) в корне сайта или в панели хостинга — возможно, блокировка стоит на уровне php.ini.
Частые ошибки и нюансы
- Добавление констант после закрывающего тега ?> — они должны находиться до вызова wp-settings.php, иначе не будут обработаны.
- Включение только WP_DEBUG без WP_DEBUG_LOG — ошибки выводятся на экран, уродуют вёрстку и раскрывают конфиденциальные пути.
- Использование редактирования через встроенные редакторы cPanel без создания резервной копии — одна опечатка может полностью убить сайт.
- Удаление проблемного плагина через файловую систему без анализа лога — это не устраняет первопричину и может сломать зависимости.
- Оставление debug.log доступным для скачивания — злоумышленник может узнать структуру каталогов и уязвимые компоненты.
Проверить ошибку WordPress
Введите ошибку WordPress, PHP, плагина, темы, REST API или кратко опишите проблему сайта.
FAQ
Что делать, если у меня нет доступа к файлам сайта?
Без FTP, файлового менеджера или SSH включить отладку не получится, так как константы прописываются в wp-config.php. Обратитесь в техподдержку хостинга — у них обычно есть доступ к файловой системе, и они могут внести нужные правки или предоставить вам временные учётные данные.
Можно ли включить WP_DEBUG через .htaccess или php.ini?
Нет, константы WP_DEBUG, WP_DEBUG_LOG и WP_DEBUG_DISPLAY определяются исключительно в коде PHP до загрузки ядра. Директивы .htaccess и настройки php.ini влияют на общие параметры PHP, но не на механизмы отладки WordPress.
Чем отличаются WP_DEBUG_LOG и WP_DEBUG_DISPLAY?
WP_DEBUG_LOG отвечает за запись ошибок в файл wp-content/debug.log, не показывая их посетителям. WP_DEBUG_DISPLAY управляет отображением ошибок прямо на страницах сайта. Безопаснее всегда устанавливать WP_DEBUG_DISPLAY в false и пользоваться логом.
Нужно ли удалять debug.log после решения проблемы?
Обязательно. Файл debug.log может содержать информацию о структуре каталогов и уязвимостях. После отключения отладки его необходимо удалить, чтобы потенциальный злоумышленник не мог его загрузить.
Что делать, если файл debug.log не создаётся даже после верного добавления констант?
Проверьте права на папку wp-content — сервер должен иметь возможность писать в неё. Если права 755 не помогают, временно поставьте 777, воспроизведите ошибку, а затем верните 755. Также убедитесь, что на уровне сервера не запрещена функция error_log.
Как отключить отладку после восстановления сайта?
Откройте wp-config.php и либо замените true на false у всех трёх констант, либо закомментируйте или удалите добавленные строки. После этого удалите файл debug.log из wp-content и проверьте работу сайта.
Итог
Режим отладки WordPress, активируемый через wp-config.php, — это незаменимый инструмент, когда админка недоступна. Аккуратное добавление констант, запись ошибок в закрытый лог вместо вывода на экран и своевременное отключение позволяют безопасно найти корень проблемы и вернуть сайт к жизни.