Что менялось
Обновление плагина, темы, PHP или ручная правка кода.
Практическая диагностика · WordPress
WordPress пишет «На сайте возникла критическая ошибка»: что проверить
Это сообщение означает, что PHP завершил выполнение с фатальной ошибкой. Причиной может быть плагин, тема, несовместимая версия PHP, нехватка памяти или повреждённый код. Главная задача — получить реальный текст ошибки и не выключать компоненты наугад.
Быстрый маршрут
Что проверить за первые 5 минут
Перед любыми изменениями фиксируем момент появления ошибки и последние действия на сайте.
Есть ли админка
Ошибка на всём сайте или только на frontend/конкретной странице.
Посмотреть error log
Нужен файл и строка, где возник fatal error.
Проверить PHP
Версия и расширения должны подходить проекту.
Сделать snapshot
Перед отключением компонентов сохранить текущее состояние.
Фраза «критическая ошибка» — не диагноз.Диагнозом становится конкретный PHP fatal error с файлом, строкой и контекстом последнего изменения.
Шаг 1
Начните с PHP/error log, а не с белого экрана
WordPress скрывает подробности fatal error от посетителя, что правильно для безопасности. Но серверный error log обычно содержит тип ошибки, путь к файлу и строку.
Если хостинг или панель разделяет логи веб-сервера и PHP, проверяем оба. Важно смотреть записи ровно в момент воспроизведения ошибки.
Не включайте отображение PHP-ошибок посетителям production-сайта. Диагностические сообщения лучше писать в закрытый лог.
Шаг 2
Свяжите ошибку с последним обновлением или изменением окружения
Если проблема появилась сразу после обновления одного плагина, это сильнее любой общей гипотезы. Если сайт сломался после переключения PHP 7.4 → 8.x, ищем несовместимый код и устаревшие зависимости.
При массовом автообновлении полезно смотреть точное время обновлений и версии пакетов, а не отключать все плагины одновременно.
Шаг 3
Отключайте подозрительный компонент контролируемо
Если fatal указывает на файл плагина, временно отключаем именно его и проверяем результат. Если ошибка в теме — переключение на резервную тему лучше делать только после snapshot и понимания влияния на frontend.
Массовое переименование каталога plugins иногда помогает вернуть доступ, но уничтожает диагностический контекст. Для production-проекта лучше точечное отключение.
Шаг 4
Проверьте совместимость PHP, расширения и memory_limit
После переноса или обновления сервера может измениться версия PHP, набор модулей, ionCube, intl, mbstring или лимиты памяти. Ошибки undefined function/class и allowed memory size дают разные направления поиска.
Увеличение memory_limit оправдано только если приложение действительно требует больше памяти. Если один запрос внезапно съедает сотни мегабайт, сначала ищем цикл, тяжёлый импорт или конфликт плагина.
php -vПомогает сверить окружение, но версия CLI может отличаться от PHP-FPM сайта.
php -mПоказывает доступные расширения в CLI; для сайта сверяем FPM-конфигурацию отдельно.
Шаг 5
После возврата сайта устраните причину, а не оставляйте случайный откат
Если откат версии плагина восстановил сайт, фиксируем совместимость и план обновления. Если пришлось вернуть старую PHP, проверяем, какие компоненты мешают переходу.
После восстановления очищаем кеши, повторяем проблемный сценарий и смотрим error log ещё раз — отсутствие белого экрана не гарантирует отсутствие предупреждений и вторичных ошибок.
Практический пример
Сайт сломался сразу после обновления одного плагина
После автоматического обновления frontend показывает критическую ошибку, а wp-admin частично открывается. Простое обновление страницы ничего не меняет.
В PHP log видно fatal error в файле обновлённого плагина: новая версия вызывает функцию, недоступную в текущей версии PHP. Временно откатываем плагин, затем обновляем окружение на тестовой копии и проверяем совместимость.
| Факт | Вывод |
|---|---|
| Ошибка появилась сразу после update | первый кандидат — обновлённый компонент |
| Fatal указывает на файл плагина | не нужно отключать всё подряд |
| Причина связана с PHP API | проверяем матрицу совместимости |
Типовые сценарии
Что подсказывает текст fatal error
Несколько типовых формулировок позволяют сразу сузить область.
| Сообщение в логе | Вероятная причина | Следующий шаг |
|---|---|---|
| Call to undefined function | нет расширения или несовместимый код | проверить PHP-модули и версию |
| Class not found | не загрузилась зависимость/плагин | autoload, обновление, конфликт |
| Allowed memory size exhausted | исчерпан memory_limit | найти тяжёлый процесс и оценить лимит |
| Parse error / syntax error | ошибка после правки файла | вернуть корректную версию кода |
| Fatal в конкретном плагине | обновление/конфликт плагина | точечно отключить и проверить совместимость |
Чего не делать
Типичные действия, которые мешают диагностике
Отключать все плагины сразу
Сайт может ожить, но вы потеряете понимание виновника.
Показывать display_errors посетителям
Это раскрывает пути и внутренние детали приложения.
Повышать memory_limit до огромного значения
Можно замаскировать утечку или бесконечный процесс.
Удалять файлы проблемного плагина
Лучше сохранить возможность отката и понять причину.
Чек-лист
Проверка критической ошибки WordPress
- Зафиксировать последнее изменение: Что обновлялось перед ошибкой.
- Воспроизвести ошибку: Точный URL и действие.
- Посмотреть PHP log: Тип fatal, файл и строка.
- Определить компонент: Core, plugin, theme или custom code.
- Проверить PHP: Версия, FPM и расширения.
- Проверить память: Есть ли exhausted memory.
- Сделать snapshot: Перед отключением/откатом.
- Отключить точечно: Только подозрительный компонент.
- Повторить сценарий: Проверить, что причина устранена.
- Запланировать корректное обновление: Не оставлять уязвимую старую версию без плана.
Когда нужен доступ к проекту
Какие данные ускоряют диагностику
Если сайт production и ошибка затрагивает оплату, формы или кабинет, нужен snapshot и доступ к логам до любых массовых действий. Это позволяет восстановить работу без потери диагностического следа.
Передавать пароли в текст статьи или публичную переписку не нужно. Для рабочей диагностики доступы выдаются отдельно и только к тем системам, которые действительно нужны для проверки.
Вопросы
Короткие ответы
Можно ли исправить критическую ошибку без доступа к админке?
Да, через файловый доступ, панель, WP-CLI и серверные логи, но изменения лучше делать со snapshot.
Почему письмо о recovery mode не приходит?
Почта сайта может быть настроена неправильно; сам PHP log надёжнее для первичной диагностики.
Нужно ли переустанавливать WordPress?
Обычно нет. Сначала найдите конкретный fatal error.
Если отключение плагина помогло, проблема решена?
Сайт восстановлен, но нужно выяснить совместимость и безопасно вернуть функциональность.