WordPress: Как проверить причину критической ошибки WordPress по журналу PHP

#Признаки проблемы и применимость

Сообщение «На сайте возникла критическая ошибка» само по себе не называет виновный файл. Это руководство посвящено безопасному поиску первоначальной записи PHP Fatal error в журнале, её сопоставлению со временем ошибки и отключению диагностики после исправления.

#Причины и отличительные признаки

#Пошаговая диагностика и исправление

1. Сохраните время и безопасно повторите ошибкуЗапишите URL и точное время с часовым поясом, какое действие было выполнено и видит ли ошибку посетитель. Не отправляйте формы заказа многократно и не повторяйте операции оплаты. Если сайт рабочий, предпочтите тестовую копию.

1. Откройте файловый менеджер или защищённый доступ SSHНайдите корень WordPress с wp-config.php. Прежде чем что-либо менять, скопируйте wp-config.php за пределы публичного каталога и запишите текущие значения WP_DEBUG, WP_DEBUG_LOG и WP_DEBUG_DISPLAY. Если константы уже есть, не дублируйте их.

1. Включите запись без показа пользователямВ wp-config.php перед строкой остановки редактирования измените существующие определения констант на значения из примера. Для WP_DEBUG_LOG=true файл обычно создаётся в wp-content/debug.log, если процесс имеет право записи. Записи могут содержать секреты — ограничьте доступ и используйте закрытый журнал.
2. Фрагмент wp-config.php, не команда терминала; задайте значения ровно один раз

   PHPКопировать всёВыделить

   Фрагмент wp-config.php, не команда терминала; задайте значения ровно один раз.

   define('WP_DEBUG', true);
   define('WP_DEBUG_LOG', true);
   define('WP_DEBUG_DISPLAY', false);

1. Найдите первое сообщение Fatal errorОткройте wp-content/debug.log через закрытый файловый менеджер или SSH. Ищите запись с временем воспроизведения, названием Fatal error/Uncaught Error и путём файла; строки Warning обычно следствие, а не причина. Не публикуйте полный журнал с токенами, путями и данными пользователей.

1. Если файл пуст, проверьте журнал PHP обработчикаВ панели хостинга откройте журналы ошибок конкретного домена или обратитесь к администратору PHP-FPM. Сопоставьте время, пул и сообщение. На сервере с SSH только для просмотра при известном пути разрешено читать конец файла; не угадывайте имя общего журнала.
2. Путь замените на реальный и проверьте права доступа; команда читает файл без изменения

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Путь замените на реальный и проверьте права доступа; команда читает файл без изменения.

   tail -n 80 /путь/к/закрытому/php-error.log

1. Отделите следствие от первопричиныЕсли ошибка указывает на плагин, откройте его страницу версии и журнал изменений, сопоставьте версию PHP. Если проблема возникла после обновления, на копии выполните безопасный откат одного плагина. При memory exhausted сравните нагрузку и конкретный запрос; не увеличивайте memory_limit бесконтрольно.

1. Закройте диагностику и проверьте новый запросПосле исправления верните WP_DEBUG=false и прежние значения остальных констант; проверьте, что подробные сообщения не показываются пользователям. Удаляйте или архивируйте debug.log только после того, как сохранили нужный фрагмент в закрытом месте. Повторите первоначальное действие и проверьте отсутствие новой записи Fatal error.

#Проверка результата

Критическая ошибка больше не воспроизводится на исходном адресе; в журнале нет нового Fatal error за время проверки, а подробная диагностика выключена и закрыта от посетителей.

#Что делать, если не помогло

Если в логе указан файл ядра, это не всегда ошибка самого ядра: изучите стек вызовов и последний загруженный модуль. Если журнал не создаётся, выясните расположение PHP error_log и права, не назначая папке wp-content разрешения 777.