Как восстановить WordPress после фатальной ошибки без доступа к админке

Что означает fatal error в WordPress

Fatal error — это критическая ошибка PHP, из-за которой WordPress не может завершить выполнение запроса. Причиной может быть несовместимый плагин, ошибка в теме, отсутствующий класс или функция PHP, конфликт между расширениями, повреждённый файл или устаревшая версия PHP.

Сначала определите масштаб проблемы. Если не открывается только админка, а главная страница работает, причиной может быть плагин или код, который используется только в административной части. Если недоступны и сайт, и /wp-admin, необходимо отключить подозрительный компонент на уровне сервера или файловой системы.

Не повторяйте обновление вслепую и не удаляйте таблицы WordPress. Такие действия могут скрыть симптомы, но не устранить причину и усложнить восстановление.

• Запишите точный текст ошибки, имя файла и номер строки.
• Вспомните, что изменилось непосредственно перед сбоем: плагин, тема, WordPress, PHP или настройки сервера.
• Проверьте, возникает ли ошибка на всех страницах или только при попытке войти в админку.

Первый шаг — проверьте Recovery Mode

Во многих случаях WordPress отправляет администратору письмо о критической ошибке со специальной ссылкой Recovery Mode. Этот режим позволяет войти в админку, временно приостановив работу проблемного плагина или темы только для вашей сессии. Другие посетители при этом могут видеть отдельное сообщение об ошибке.

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

После входа не просто активируйте компонент повторно. Сначала проверьте его версию, требования к PHP и WordPress, дату последнего обновления и возможные сообщения о конфликте. Если ошибка появилась сразу после обновления, безопаснее временно оставить компонент отключённым и проверить предыдущую версию на staging.

• Ссылка Recovery Mode может быть временной, поэтому используйте её вскоре после получения письма.
• Если письма нет, проверьте папку со спамом и правильность адреса администратора.
• Recovery Mode не исправляет код компонента — он лишь помогает получить доступ и локализовать проблему.

Отключение проблемного плагина через WP-CLI

Если у вас есть SSH-доступ к серверу и установлен WP-CLI, плагин можно отключить без входа в админку. Перейдите в корневой каталог WordPress — обычно там находится файл wp-config.php — и выполните команду для нужного плагина.

Параметры --skip-plugins и --skip-themes не позволяют WordPress загружать плагины и тему во время выполнения команды. Это особенно важно, если ошибка возникает ещё на этапе запуска WordPress.

• Проверьте точный slug плагина в списке установленных расширений.
• После деактивации откройте сайт в приватном окне браузера и проверьте главную страницу, несколько внутренних страниц и /wp-admin.
• Если команда возвращает ошибку, сохраните её текст: он может указать на проблему с PHP, правами доступа или самим WP-CLI.

wp plugin list --skip-plugins --skip-themes
wp plugin deactivate problematic-plugin --skip-plugins --skip-themes

Если проблема связана с темой

Если fatal error появился после смены или обновления темы, временно активируйте стандартную тему, совместимую с вашей версией WordPress. В примере используется twentytwentyfour, но на сервере должна быть установлена именно указанная вами тема.

Если стандартной темы нет, сначала установите её из проверенного источника или восстановите файлы темы. Не копируйте случайную тему на рабочий сайт без проверки.

• Перед активацией убедитесь, что нужная стандартная тема находится в wp-content/themes/.
• Проверьте сайт после переключения: часть функций и вёрстка кастомной темы могут временно исчезнуть.
• Не удаляйте проблемную тему, пока не сохраните её файлы и настройки.

wp theme list --skip-plugins --skip-themes
wp theme activate twentytwentyfour --skip-plugins --skip-themes

Что делать, если WP-CLI тоже завершается с ошибкой

Если WordPress завершается с ошибкой ещё до выполнения команды WP-CLI, используйте файловый доступ через SSH, SFTP или файловый менеджер хостинга. Найдите каталог подозрительного плагина в wp-content/plugins/ и временно переименуйте его, например из problematic-plugin в problematic-plugin.disabled.

WordPress не найдёт плагин под исходным именем и не сможет его загрузить. Во многих случаях этого достаточно, чтобы сайт снова начал открываться. После восстановления доступа не переименовывайте каталог обратно сразу: сначала изучите логи и проверьте совместимость.

Если неизвестно, какой именно плагин вызвал сбой, можно временно переименовать каталог plugins, например в plugins.disabled. Это отключит все плагины. Затем верните каталогу исходное имя и включайте расширения по одному, проверяя сайт после каждой активации.

• Не переименовывайте и не удаляйте wp-content без резервной копии.
• Меняйте имя каталога, а не удаляйте его: так вы сможете быстро вернуть файлы.
• Если после отключения всех плагинов ошибка не исчезла, проверьте тему, версию PHP и файлы ядра.

cd /path/to/wordpress/wp-content/plugins/
mv problematic-plugin problematic-plugin.disabled

Диагностика: где искать причину ошибки

Текст fatal error обычно содержит путь к файлу и номер строки. Если в нём упоминается wp-content/plugins/, вероятнее всего, проблема связана с плагином. Путь к wp-content/themes/ указывает на тему, а сообщения о памяти, классе или функции могут свидетельствовать о конфликте компонентов или несовместимой версии PHP.

Просмотрите журнал WordPress, если он включён, а также логи PHP-FPM и веб-сервера. На разных хостингах они хранятся в разных местах, поэтому при необходимости обратитесь в службу поддержки хостинга.

Для временного журналирования в wp-config.php можно использовать следующие параметры. Не включайте отображение ошибок для всех посетителей рабочего сайта: служебная информация может содержать пути к файлам и детали конфигурации.

• После диагностики отключите WP_DEBUG или оставьте журналирование только в соответствии с правилами безопасности вашей среды.
• Не делайте debug.log общедоступным и проверьте права доступа к файлу.
• После сохранения нужных записей очистите или архивируйте старые логи, чтобы они не заняли всё дисковое пространство.

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

Что проверить на уровне сервера

Если в логах нет понятной причины, проверьте версию PHP, доступную память, права на файлы и наличие необходимых расширений PHP. Отдельно обратите внимание на изменения, выполненные одновременно с обновлением плагина: переключение версии PHP или изменение конфигурации веб-сервера также может привести к сбою.

Не меняйте версию PHP вслепую на рабочем сайте. По возможности сначала создайте копию или staging-среду и проверьте совместимость ядра, темы и плагинов.

• Сравните текущую версию PHP с требованиями проблемного плагина и темы.
• Проверьте ограничения memory_limit и max_execution_time, если ошибка связана с нехваткой ресурсов.
• Убедитесь, что после восстановления сайт не возвращает ошибки 500 и не попадает в бесконечные редиректы.

Восстановление после того, как сайт снова заработал

После отключения проблемного компонента проверьте не только главную страницу, но и формы, поиск, авторизацию, корзину и оплату, если они есть на сайте. Просмотрите журнал ошибок в течение нескольких минут после восстановления: иногда страница открывается, но фоновые запросы или cron-задачи всё ещё завершаются с ошибкой.

Плагин или тему, из-за которых произошёл сбой, не следует просто включать повторно. Сделайте резервную копию файлов и базы данных, проверьте совместимость версий, ознакомьтесь с журналом изменений и протестируйте компонент на staging. Если проблема началась после обновления, можно временно вернуться к предыдущей версии, но используйте это только как краткосрочную меру.

После тестирования обновите проблемный компонент до исправленной версии или замените его на поддерживаемое решение. Устаревшее расширение создаёт не только риск повторного fatal error, но и потенциальную угрозу безопасности.

• Сделайте полную резервную копию перед повторной активацией.
• Тестируйте обновления на staging, если сайт критически важен для бизнеса.
• Ведите список изменений: он поможет быстро определить причину следующего сбоя.
• Не оставляйте debug.log и служебные сообщения общедоступными.