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

Обновили плагин, нажали «Обновить страницу» — и вместо сайта появилось сообщение «На сайте произошла критическая ошибка». Иногда перестаёт открываться только административная панель, иногда падает отдельная страница, корзина WooCommerce или редактор Elementor.
‎
‎Если проблема возникла сразу после обновления конкретного расширения, первым подозреваемым действительно становится этот плагин. Однако удалять WordPress, переустанавливать тему или восстанавливать весь сайт из старой резервной копии сразу не стоит. Гораздо безопаснее сначала отключить обновлённый плагин, вернуть доступ к сайту и только после этого выяснять точную причину сбоя.
‎
‎Что означает критическая ошибка после обновления плагина
‎
‎WordPress работает на PHP. Если новая версия плагина выполняет код, который PHP не может продолжить выполнять, возникает фатальная ошибка. WordPress прекращает формирование текущего запроса и вместо обычной страницы может показать сообщение о критической ошибке.
‎
‎Причиной может быть не только программный баг самого расширения. После обновления могут проявиться:
‎
‎- несовместимость плагина с используемой версией PHP;
‎- конфликт с другим плагином;
‎- конфликт с активной темой;
‎- изменение функции, класса или API, от которых зависел другой компонент;
‎- ошибка в пользовательском коде, который взаимодействует с обновлённым плагином;
‎- превышение доступного лимита памяти;
‎- некорректно завершившееся обновление файлов.
‎
‎Поэтому формулировка «после обновления сломался сайт» ещё не означает, что новая версия плагина плохая сама по себе. Обновление могло лишь проявить конфликт, который раньше не возникал.
‎
‎Почему WordPress не всегда откатывает проблемное обновление автоматически
‎
‎В современных версиях WordPress есть несколько защитных механизмов.
‎
‎При фатальных ошибках ядро может задействовать Recovery Mode — режим восстановления, определить проблемный плагин или тему и отправить администратору специальное письмо для входа. В режиме восстановления компонент, связанный с фатальной ошибкой, временно приостанавливается для административной сессии.
‎
‎Кроме того, WordPress умеет создавать временную резервную копию обновляемого расширения. Механизм отката неудачных ручных обновлений появился в WordPress 6.3, а начиная с WordPress 6.6 автоматические обновления активных плагинов дополнительно проверяются на PHP fatal error и при обнаружении такой ошибки предыдущая версия может быть восстановлена автоматически.
‎
‎Однако это не полноценная замена резервным копиям и тестированию. Например, автоматическая проверка после автообновления использует loopback-запрос. Поэтому, если ошибка появляется только при открытии определённого товара, страницы Elementor, AJAX-запроса или оформления заказа, автоматический механизм может не воспроизвести именно этот сценарий.
‎
‎Шаг 1. Проверьте письмо WordPress о критической ошибке
‎
‎Начните с почты, указанной в WordPress как административная.
‎
‎При обнаружении подходящей фатальной ошибки WordPress может отправить сообщение, в котором будет указано, какой плагин или тема вызвали сбой, а также ссылка для входа в Recovery Mode.
‎
‎Проверьте также папку «Спам». Если письмо пришло, не спешите сразу повторно активировать проблемное расширение. Сначала войдите в режим восстановления, убедитесь, что сайт снова доступен, и посмотрите название компонента, который WordPress приостановил.
‎
‎Если письма нет, переходите к отключению плагина вручную.
‎
‎Шаг 2. Отключите обновлённый плагин, если админка не открывается
‎
‎Если «/wp-admin/» доступен, всё просто: откройте Плагины → Установленные плагины и деактивируйте расширение, после обновления которого появилась ошибка.
‎
‎Если панель администратора тоже недоступна, используйте SFTP, FTP или файловый менеджер хостинга.
‎
‎Откройте каталог:
‎
‎»/wp-content/plugins/»
‎
‎Найдите папку проблемного расширения. Например:
‎
‎»example-plugin»
‎
‎и временно переименуйте её:
‎
‎»example-plugin-disabled»
‎
‎WordPress больше не сможет загрузить плагин из прежнего каталога, поэтому расширение будет фактически отключено.
‎
‎Теперь снова откройте сайт.
‎
‎Если сайт заработал, связь с этим плагином практически подтверждена. Но следующий вопрос — почему новая версия вызвала ошибку.
‎
‎Если ничего не изменилось, возможно, обновление затронуло другой компонент либо одновременно обновлялось несколько расширений. В этом случае потребуется журнал ошибок.

‎Шаг 3. Найдите реальную причину в debug.log
‎
‎Угадывать по внешнему виду ошибки не нужно. WordPress позволяет записывать PHP-ошибки в журнал.
‎
‎Откройте «wp-config.php» в корне сайта и проверьте настройки отладки. Для временной диагностики можно использовать:

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

‎»WP_DEBUG_LOG» сохраняет сообщения отладки в журнал, а «WP_DEBUG_DISPLAY» со значением «false» помогает не показывать технические ошибки посетителям сайта.
‎
‎После сохранения файла снова вызовите проблемную страницу и проверьте:
‎
‎»/wp-content/debug.log»
‎
‎Ищите последние записи с формулировками вроде:
‎
‎»PHP Fatal error»
‎
‎»Uncaught Error»
‎
‎»Uncaught TypeError»
‎
‎»Allowed memory size exhausted»
‎
‎»Call to undefined function»
‎
‎Особенно полезен путь к файлу. Например, запись вида:
‎
‎»/wp-content/plugins/example-plugin/includes/class-example.php»
‎
‎показывает, что ошибка возникла во время выполнения кода этого плагина.
‎
‎Однако путь к файлу не всегда означает, что виноват исключительно он. Один плагин может вызвать функцию другого, передать ему неожиданные данные или использовать API, поведение которого изменилось. Поэтому при сложной ошибке смотрят не только последнюю строку, но и весь «Stack trace».
‎
‎После завершения диагностики режим отладки на рабочем сайте лучше отключить.
‎
‎Шаг 4. Проверьте совместимость PHP и зависимостей
‎
‎После крупного обновления плагина требования к окружению могли измениться. Поэтому проверьте:
‎
‎- версию PHP на сервере;
‎- требования новой версии плагина;
‎- версию WordPress;
‎- наличие обязательных зависимостей;
‎- совместимость дополнений для этого плагина;
‎- активную тему и дочернюю тему;
‎- пользовательские PHP-сниппеты.
‎
‎Особенно внимательно стоит проверять связки вроде WooCommerce + платёжные или доставочные расширения, Elementor + сторонние наборы виджетов, а также плагины с собственными add-ons.
‎
‎Например, основной плагин обновился до новой версии, а дополнительное расширение осталось старым и продолжает обращаться к функции или методу, который разработчик изменил. В результате ошибка появляется не в момент установки обновления, а при выполнении конкретного действия на сайте.
‎
‎Шаг 5. Нужно ли откатывать плагин на предыдущую версию
‎
‎Если новая версия действительно вызывает критическую ошибку, временный откат допустим как способ вернуть рабочий сайт. Но делать его следует осознанно.
‎
‎Наиболее безопасный вариант — восстановить предыдущую рабочую версию самого плагина из резервной копии или из официального источника разработчика.
‎
‎Не загружайте старые ZIP-файлы с неизвестных сайтов.
‎
‎Есть ещё один нюанс: некоторые обновления меняют не только PHP-файлы, но и структуру данных в базе. Поэтому простой возврат старых файлов не всегда равнозначен полному откату обновления.
‎
‎Особенно осторожно нужно действовать на WooCommerce-сайтах и других проектах с постоянно меняющимися данными. Восстановление всей резервной копии сайта недельной давности может вернуть старую версию плагина — и одновременно удалить новые заказы, заявки, пользователей или изменения контента.

Поэтому перед полным восстановлением сначала определите, можно ли откатить только проблемный компонент.
‎
‎Шаг 6. Что делать после восстановления сайта
‎
‎Когда сайт снова открылся, работа ещё не закончена.
‎
‎Необходимо понять, почему обновление привело к сбою. Иначе проблема вернётся при следующей попытке обновить плагин.
‎
‎Проверьте:
‎
‎1. журнал «debug.log»;
‎2. changelog проблемного плагина;
‎3. требования к PHP и WordPress;
‎4. документацию разработчика;
‎5. известные Issues или Discussions в официальном GitHub-репозитории, если он используется проектом;
‎6. совместимость связанных add-ons;
‎7. работу сайта на staging-копии с новой версией.
‎
‎После диагностики отключите «WP_DEBUG», если он не нужен постоянно, и не оставляйте общедоступный журнал с техническими данными.
‎
‎Можно ли просто оставить старую версию плагина
‎
‎На несколько часов или дней — иногда это разумная временная мера. На месяцы — уже плохая стратегия.
‎
‎Старая версия может содержать исправленные позже ошибки или уязвимости, а со временем начнёт конфликтовать с новой версией WordPress, PHP или другими расширениями.
‎
‎Поэтому откат — не финальное решение, а способ стабилизировать сайт, пока вы выясняете причину несовместимости.
‎
‎Если проблема подтверждена у самого разработчика плагина, можно дождаться исправляющего релиза. Если ошибка связана только с вашим сайтом, необходимо разбирать конфликт окружения, темы, custom-кода или другого расширения.
‎
‎Как обновлять плагины, чтобы сайт не падал
‎
‎Для небольшого информационного сайта обновление иногда действительно проходит по схеме «нажал кнопку — проверил главную страницу». Для коммерческого проекта этого недостаточно.
‎
‎Перед существенными обновлениями лучше:
‎
‎- иметь свежую резервную копию файлов и базы данных;
‎- тестировать обновление на staging-сайте;
‎- не обновлять сразу десятки критичных расширений;
‎- проверять changelog;
‎- контролировать требования к PHP;
‎- после обновления тестировать не только главную страницу;
‎- отдельно проверять формы, личный кабинет, поиск, корзину и оформление заказа;
‎- сохранять доступ к файловому менеджеру или SFTP.
‎
‎Особенно осторожно стоит обновлять плагины, которые отвечают за оплату, авторизацию, безопасность, кеширование, мультиязычность, Elementor, WooCommerce и интеграции с внешними сервисами.
‎
‎Когда лучше не исправлять ошибку самостоятельно
‎
‎Отключить очевидно проблемный плагин обычно несложно. Но дальнейшая диагностика требует осторожности, если:
‎
‎- сайт принимает заказы и платежи;
‎- резервной копии нет;
‎- после отключения плагина ошибка остаётся;
‎- новая версия успела изменить данные в базе;
‎- ошибка возникает только периодически;
‎- в «debug.log» фигурируют несколько плагинов;
‎- сбой связан с custom-кодом;
‎- сайт невозможно открыть даже после деактивации расширения;
‎- одновременно появились редиректы, неизвестные файлы или другие признаки возможного заражения.
‎
‎В таких ситуациях безопаснее сначала зафиксировать текущее состояние сайта и разобраться в причине, а уже затем менять версии компонентов.
‎
‎Вопросы и ответы
‎
‎Почему после обновления плагина появилась критическая ошибка WordPress?
‎
‎Чаще всего новая версия расширения столкнулась с несовместимостью: с PHP, WordPress, темой, другим плагином или пользовательским кодом. Точную причину лучше искать в «debug.log», а не определять по одному сообщению на экране.
‎
‎Как отключить плагин, если не открывается админка WordPress?
‎
‎Через SFTP, FTP или файловый менеджер откройте «/wp-content/plugins/» и временно переименуйте каталог проблемного плагина. После этого WordPress перестанет загружать его код.
‎
‎Можно ли вернуть предыдущую версию плагина WordPress?
‎
‎Да, но желательно использовать резервную копию или официальный источник разработчика. Необходимо учитывать, что обновление могло изменить данные в базе, поэтому возврат только PHP-файлов подходит не для каждого плагина.
‎
‎Почему WordPress сам не откатил обновление?
‎
‎WordPress содержит механизмы защиты при сбоях обновлений, а с версии 6.6 автообновления активных плагинов проверяются на PHP fatal errors с возможностью возврата предыдущей версии. Однако автоматическая проверка не гарантирует обнаружение каждой ошибки во всех пользовательских сценариях.
‎
‎Что делать, если после отключения обновлённого плагина сайт всё равно не работает?
‎
‎Проверьте «debug.log», серверный PHP error log и другие недавно обновлённые компоненты. Возможно, обновлялось несколько плагинов, проблема возникла в теме или ошибка проявилась в пользовательском коде.
‎
‎Нужно ли отключать автоматические обновления плагинов?
‎
‎Не обязательно отключать их для всех расширений. Важнее оценить критичность конкретного плагина, качество резервного копирования и возможность тестирования. Для ключевого коммерческого функционала staging-проверка перед обновлением обычно безопаснее слепого автообновления.
‎
‎Шаг 7. Сайт не восстановился после отключения плагина?
‎
‎Если после обновления плагина WordPress продолжает выдавать критическую ошибку, проблема может быть глубже обычного конфликта версий. Я могу проверить «debug.log», PHP, плагины, тему и пользовательский код, определить источник сбоя и восстановить работу сайта без лишних изменений рабочего функционала.