Критическая ошибка WordPress: восстановление после обновления

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

В такой ситуации не нужно сразу переустанавливать CMS, восстанавливать всю базу данных или удалять файлы сайта. Практическая задача состоит из трёх этапов: вернуть доступ через режим восстановления, определить проблемный компонент по журналу debug.log и при необходимости отключить его через файловый менеджер, FTP или SFTP.

Эта инструкция относится именно к фатальным ошибкам PHP внутри WordPress, возникшим после обновления или активации плагина либо темы. Ошибки подключения к базе данных и ответы HTTP 500, возникающие до запуска WordPress, требуют другой диагностики и здесь не рассматриваются.

Как понять, что проблема связана с плагином или темой

Связь с обновлением наиболее вероятна, если непосредственно перед сбоем выполнялось одно из следующих действий:

• обновление одного или нескольких плагинов;
• установка новой версии активной темы;
• активация ранее не использовавшегося расширения;
• включение функции, добавленной обновлённым плагином;
• массовое автоматическое обновление компонентов WordPress.

На страницах сайта и в административной панели при этом может появиться одинаковое сообщение о критической ошибке. Иногда главная страница продолжает работать, а ошибка возникает только в /wp-admin/, редакторе, форме заказа или другом разделе. Это не исключает проблему в расширении: фатальная ошибка может выполняться только при определённом запросе.

Зафиксируйте, что именно обновлялось и когда возник сбой. Не запускайте повторное обновление и не меняйте одновременно несколько компонентов: большое количество изменений усложнит поиск причины.

Что подготовить перед восстановлением

Для работы потребуется хотя бы один из следующих способов доступа:

• ссылка режима восстановления из письма WordPress;
• файловый менеджер в панели управления хостингом;
• FTP- или SFTP-доступ к каталогу сайта.

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

Регулярные копии файлов и базы данных заметно упрощают такие ситуации. Практические способы подготовки и проверки копий описаны в статье о резервном копировании сайта.

Определите корневой каталог установленного WordPress. В зависимости от хостинга он может называться public_html, www, htdocs или совпадать с доменом. Правильный каталог содержит файлы wp-config.php, wp-login.php и папки wp-admin, wp-content, wp-includes.

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

Для большинства сайтов доступ к файлам через панель и SFTP доступен на виртуальном хостинге; для действий из этой инструкции root-доступ и изменение системных служб не нужны.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Шаг 1. Попробуйте войти через Recovery Mode

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

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

Как использовать ссылку восстановления

1. Откройте ссылку из письма в том браузере, в котором будете работать с административной панелью.
2. Авторизуйтесь под учётной записью администратора.
3. Прочитайте уведомление WordPress о приостановленном плагине или теме.
4. Откройте раздел «Плагины» или «Внешний вид → Темы» в зависимости от указанного компонента.
5. Деактивируйте проблемный плагин либо переключитесь на исправную тему.
6. Откройте сайт в обычном окне браузера и проверьте несколько страниц.

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

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

Почему Recovery Mode может не помочь

Переходите к следующему способу, если:

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

Шаг 2. Включите запись ошибок в debug.log

Журнал нужен, чтобы не угадывать виновника по времени обновления, а увидеть путь к PHP-файлу, тип ошибки и строку, на которой выполнение было остановлено. WordPress записывает такой журнал с помощью параметров отладки в wp-config.php.

На рабочем публичном сайте сообщения PHP не следует показывать посетителям. Поэтому ошибки нужно направить в файл и одновременно отключить их вывод в HTML.

Создайте копию wp-config.php

В файловом менеджере или FTP-клиенте найдите wp-config.php в корневом каталоге WordPress. Скачайте его на компьютер либо создайте рядом копию с понятным именем, например wp-config.php.backup. Убедитесь, что резервный файл действительно сохранился, прежде чем редактировать оригинал.

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

Добавьте или приведите параметры к следующему виду:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Этот блок должен находиться до завершающего комментария WordPress:

/* That's all, stop editing! Happy publishing. */

Текст комментария в конкретной установке может отличаться из-за перевода или версии файла, но параметры отладки необходимо размещать до строки, после которой WordPress прекращает чтение пользовательских настроек.

WP_DEBUG включает механизм отладки, WP_DEBUG_LOG направляет сообщения в журнал, а WP_DEBUG_DISPLAY со значением false скрывает их от посетителей. При стандартной конфигурации журнал создаётся по адресу wp-content/debug.log. Параметр WP_DEBUG_LOG работает только при включённом WP_DEBUG.

Значения true и false записываются без кавычек. Строка 'false' в PHP не равна логическому значению false и может привести к неожиданному результату.

Сохраните файл и вызовите ошибку повторно

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

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

Затем откройте каталог wp-content и найдите debug.log. Если файл существовал до диагностики и содержит много старых сообщений, сначала скачайте его, переименуйте, например, в debug.log.before-recovery, а затем повторите проблемный запрос. Новый короткий журнал будет проще анализировать.

Что делать, если debug.log не появился

Проверьте последовательно:

1. Сохранены ли изменения именно в том wp-config.php, который относится к нужному домену.
2. Нет ли выше по файлу второго определения WP_DEBUG со значением false.
3. Расположен ли блок до завершающего комментария конфигурации.
4. Была ли после включения журнала повторно открыта проблемная страница.
5. Может ли PHP записывать файлы в wp-content.

Не устанавливайте для каталогов и файлов права 777. На виртуальном хостинге безопаснее проверить владельца и права через панель либо обратиться в поддержку. Хостинг также может вести отдельный журнал PHP, но для рассматриваемой задачи сначала следует правильно настроить штатный debug.log WordPress.

Шаг 3. Найдите виновника в журнале

Открывайте debug.log с конца: последние строки обычно относятся к только что выполненному запросу. Ищите сообщения с обозначениями PHP Fatal error, Uncaught Error, Uncaught TypeError или Parse error. Предупреждения Warning, уведомления Notice и сообщения Deprecated могут быть полезны разработчику, но сами по себе не всегда останавливают сайт.

Условная запись может выглядеть так:

PHP Fatal error: Uncaught Error: Call to undefined function example_function()
in /home/account/public_html/wp-content/plugins/example-plugin/includes/loader.php:123

В этом примере важнее всего путь:

wp-content/plugins/example-plugin/

Он указывает, что выполнение остановилось в каталоге плагина example-plugin. Если путь содержит:

• wp-content/plugins/имя-плагина/ — ошибка связана с файлом плагина или вызванным им кодом;
• wp-content/themes/имя-темы/ — остановка произошла в теме;
• wp-content/mu-plugins/ — сообщение относится к обязательному плагину, который не управляется как обычное расширение.

Не делайте вывод только по названию функции в первой строке. Ориентируйтесь на полный путь к файлу и стек вызовов. Иногда один плагин вызывает функцию другого, а фатальная ошибка возникает потому, что зависимость не загрузилась. В таком случае журнал помогает установить место остановки, но для окончательного вывода нужно учитывать, какие компоненты только что обновлялись.

Как читать типичные фатальные сообщения

• Call to undefined function — код попытался вызвать отсутствующую функцию. Возможны несовместимость версий, неполное обновление или неправильная загрузка зависимости.
• Class not found — PHP не обнаружил требуемый класс. Это бывает при отсутствии файла, ошибке автозагрузки или конфликте версий компонентов.
• TypeError — функция или метод получил значение неподходящего типа. Часто такое проявляется после изменения интерфейса между версиями.
• Parse error или syntax error — PHP не может разобрать код файла. Причиной может быть повреждённое обновление, ошибка в новой версии либо ручная правка.
• Allowed memory size exhausted — выполнение остановлено из-за исчерпания памяти. Если сообщение указывает на обновлённое расширение, его отключение может вернуть доступ, но увеличение лимита без анализа не устраняет чрезмерное потребление ресурсов.

Строка после двоеточия в конце пути показывает место, где PHP зафиксировал ошибку. Не редактируйте этот файл вслепую на рабочем сайте: изменение одной строки редко является надёжным исправлением стороннего расширения и будет потеряно при следующем обновлении.

Отделите свежую ошибку от старых записей

Проверьте время сообщения и сопоставьте его с последним запросом. В журнале могут находиться ошибки от задач WordPress, AJAX-запросов и предыдущих посещений. Надёжный способ проверки — сохранить старый лог, очистить или переименовать его, один раз воспроизвести сбой и изучить новый файл.

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

Шаг 4. Отключите проблемный плагин вручную

Если административная панель не открывается, WordPress можно заставить прекратить загрузку плагина без доступа к её интерфейсу. Для этого достаточно временно изменить имя каталога расширения.

Через файловый менеджер хостинга

1. Откройте корневой каталог нужного сайта.
2. Перейдите в wp-content/plugins.
3. Найдите папку, указанную в пути из debug.log.
4. Скачайте её резервную копию, если копии сайта нет.
5. Переименуйте каталог, добавив к имени понятный суффикс.

Например:

example-plugin
example-plugin.disabled

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

Через FTP или SFTP

1. Подключитесь к серверу с реквизитами, выданными хостингом.
2. Откройте каталог установки WordPress.
3. Перейдите в wp-content/plugins.
4. Выберите папку проблемного плагина.
5. Используйте команду переименования и добавьте суффикс .disabled.
6. Дождитесь обновления списка файлов и проверьте сайт в браузере.

Для этой операции не нужен root-доступ. На виртуальном хостинге достаточно файлового менеджера, FTP или SFTP с доступом к файлам конкретного аккаунта.

Если конкретный плагин определить не удалось

Как крайний диагностический шаг можно временно переименовать весь каталог:

wp-content/plugins
wp-content/plugins.disabled

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

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

Шаг 5. Отключите проблемную тему вручную

Активная тема находится в wp-content/themes. Если фатальная ошибка ведёт к её файлам и панель управления недоступна, каталог темы также можно переименовать.

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

1. Откройте wp-content/themes.
2. Создайте копию каталога активной темы.
3. Переименуйте его, например с custom-theme в custom-theme.disabled.
4. Откройте сайт и административную панель.
5. Войдите в раздел управления темами и проверьте, какой шаблон активирован.

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

После автоматического переключения внешний вид сайта изменится — это ожидаемо. На данном этапе задача состоит в восстановлении доступа. Возвращать исходную тему следует только после установки исправной версии или проверки её копии на тестовом сайте.

Шаг 6. Проверьте восстановление

Исчезновение сообщения на главной странице ещё не означает, что сайт полностью исправен. Проверьте:

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

Откройте журнал после проверки. Если новых сообщений Fatal error нет, а сайт и панель работают, аварийный доступ восстановлен. Предупреждения и уведомления можно сохранить для последующего анализа, но не следует смешивать их с исходной фатальной ошибкой.

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

Что делать с отключённым расширением

Не оставляйте переименованные каталоги без пояснений и не активируйте старую конфигурацию случайно. Выберите один из безопасных вариантов:

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

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

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

Шаг 7. Отключите отладку и удалите журнал

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

Откройте wp-config.php и измените существующие параметры:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Не добавляйте этот блок рядом с прежним: отредактируйте уже существующие строки. Сохраните файл, обновите сайт и убедитесь, что он продолжает работать.

Скачайте wp-content/debug.log, если он нужен для обращения к разработчику или в поддержку, а затем удалите его с публичного сайта. Проверьте, что после нового запроса файл не создаётся повторно. Если журнал появляется снова, найдите другое определение параметров отладки или настройку, которая включает их автоматически.

Частые ошибки при восстановлении

Удаление плагина вместо переименования

Удаление усложняет откат и может уничтожить локальные файлы. Для первичной диагностики достаточно изменить имя каталога. Удалять компонент следует позднее, когда принято решение о его замене.

Одновременное отключение всех компонентов

Если журнал уже указывает на конкретный плагин, массовое отключение создаёт лишние последствия и мешает понять, какое действие помогло. Меняйте по одному компоненту и проверяйте результат.

Вывод PHP-ошибок посетителям

Одного WP_DEBUG со значением true недостаточно для безопасной диагностики публичного сайта. Используйте WP_DEBUG_LOG и отключайте вывод через WP_DEBUG_DISPLAY.

Дублирование констант в wp-config.php

Повторное определение WP_DEBUG или WP_DEBUG_LOG может породить дополнительные предупреждения и запутать диагностику. Всегда ищите существующие строки перед добавлением настроек.

Анализ первой попавшейся записи

Старый debug.log может содержать сообщения за длительный период. Проверяйте время, путь, тип ошибки и последние строки после контролируемого повторения сбоя.

Возврат проблемной версии сразу на рабочий сайт

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

Краткий порядок действий

1. Зафиксируйте, какой плагин или тема обновлялись перед сбоем.
2. Создайте доступную резервную копию файлов.
3. Проверьте административную почту и попробуйте Recovery Mode.
4. Если доступ не восстановлен, включите WP_DEBUG_LOG в wp-config.php, оставив вывод ошибок скрытым.
5. Один раз воспроизведите сбой и откройте wp-content/debug.log.
6. Найдите последнюю фатальную ошибку и путь к каталогу виновника.
7. Переименуйте каталог плагина в wp-content/plugins или темы в wp-content/themes.
8. Проверьте сайт, панель управления и новые записи журнала.
9. Установите рабочую версию, выполните откат или замените расширение.
10. Отключите отладку и удалите debug.log с публичного сайта.

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