После обновления плагина сломался сайт WordPress

После обновления плагина сломался сайт WordPress

Краткий ответ: если после обновления плагина сломался сайт WordPress, не удаляйте файлы и не переустанавливайте сайт сразу. Сначала сделайте backup файлов и базы, проверьте письмо режима восстановления, включите debug.log, отключите проблемный плагин через FTP/SFTP или WP-CLI, проверьте error_log, версию PHP, кеш, совместимость с темой, WooCommerce и последние изменения.

Чаще всего сайт ломается после обновления плагина из-за PHP fatal error, конфликта с темой, несовместимости с версией PHP, неудачного обновления файлов, ошибки JavaScript, изменения структуры базы данных или конфликта с кешем.

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

Причина

Плагин WordPress — это не отдельная “кнопка” в админке. Он может подключать PHP-код, JavaScript, CSS, AJAX, REST API, cron-задачи, таблицы базы данных, шорткоды, виджеты, WooCommerce-хуки, формы, кеш и интеграции с внешними сервисами.

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

Типовые причины:

• новая версия плагина несовместима с текущей версией PHP;
• плагин конфликтует с темой или дочерней темой;
• плагин конфликтует с другим плагином;
• обновление прошло не полностью и часть файлов повреждена;
• в новой версии изменились классы, функции или хуки;
• кеш отдаёт старые CSS/JS после обновления;
• в debug.log уже были ошибки, но их не проверяли до обновления;
• плагин изменил таблицы или опции в базе данных;
• security-плагин, WAF или ModSecurity блокирует новые запросы;
• WooCommerce-плагин сломал checkout, оплату, доставку или письма;
• на сайте нет backup, поэтому откат стал сложнее.

Диагностика

Сначала определите, что именно сломалось. От симптома зависит способ восстановления.

Симптом после обновления	Вероятная причина	Что проверить первым
Белый экран	fatal PHP error, memory limit, конфликт плагина	debug.log, error_log, последний обновлённый плагин
Критическая ошибка WordPress	PHP-ошибка в файлах плагина или зависимости	письмо режима восстановления, debug.log, FTP/SFTP
Ошибка 500	PHP, .htaccess, сервер, память, несовместимость	логи хостинга, debug.log, версия PHP
Не открывается wp-admin	fatal error, security-плагин, редирект, cookies	FTP/SFTP, папка плагина, error_log, кеш
Пропали стили или сломалась верстка	кеш, CSS, JS, page builder, тема	очистку кеша, консоль браузера, минификацию
Не работает форма	AJAX, reCAPTCHA, SMTP, JS-ошибка, конфликт формы	консоль браузера, Network, почтовые логи
Не работает WooCommerce checkout	wc-ajax, сессии, оплата, доставка, кеш	WooCommerce logs, консоль, платежный модуль
Появились 404	rewrite rules, REST API, постоянные ссылки	настройки постоянных ссылок, .htaccess, REST API
Сайт стал очень медленным	cron, admin-ajax.php, база, тяжёлый запрос	Query Monitor, server logs, cron events

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

Решение

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

1. Сделайте backup текущего состояния. Даже если сайт сломан, сохраните файлы и базу данных.
2. Зафиксируйте симптом. Скриншот ошибки, URL, время обновления, название плагина и его новая версия.
3. Проверьте письмо администратора. WordPress может прислать ссылку режима восстановления.
4. Включите debug.log. Нужно увидеть точную PHP-ошибку и путь к файлу.
5. Проверьте error_log на хостинге. Иногда ошибка не попадает в WordPress debug.log.
6. Отключите проблемный плагин. Если админка недоступна, сделайте это через FTP/SFTP или WP-CLI.
7. Очистите кеш. Сайт, серверный кеш, CDN и кеш браузера.
8. Проверьте сайт после отключения. Главная, внутренние страницы, wp-admin, формы, мобильная версия.
9. Решите: откатить плагин или исправить конфликт. Откат — временное восстановление, не финальное решение.
10. Проверьте совместимость. WordPress, PHP, тема, WooCommerce, другие плагины.
11. Повторите обновление на staging. На рабочем сайте не нужно повторять рискованное обновление без теста.

Код

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

Куда вставлять: в файл wp-config.php, выше строки /* That’s all, stop editing! */. Код включает запись ошибок в debug.log, но не выводит их на экран.

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

После включения проверьте файл:

/wp-content/debug.log

Если ошибка связана с памятью, можно временно увеличить лимит. Это не заменяет диагностику, но иногда помогает вернуть доступ в админку. Куда вставлять: в wp-config.php, выше строки /* That’s all, stop editing! */.

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');

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

Если есть доступ к WP-CLI, можно посмотреть плагины и отключить конкретный проблемный плагин. Команды выполняются в терминале на сервере из корня сайта:

wp plugin list
wp plugin deactivate plugin-slug
wp plugin status plugin-slug

Если нужно переустановить плагин вручную через WP-CLI, сначала убедитесь, что есть backup и вы понимаете последствия для настроек, базы и WooCommerce:

wp plugin install plugin-slug --force
wp plugin activate plugin-slug

Важно: не отключайте все плагины на рабочем сайте без понимания последствий. Для WooCommerce это может повлиять на корзину, checkout, оплату, доставку, письма, статусы заказов, CRM, Telegram и личный кабинет.

После диагностики на рабочем сайте отключите debug-режим:

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

Как отключить плагин через FTP/SFTP

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

1. Откройте корневую папку сайта.
2. Перейдите в /wp-content/plugins/.
3. Найдите папку обновлённого плагина.
4. Переименуйте её, например: plugin-name-disabled.
5. Откройте сайт и wp-admin.
6. Если сайт заработал, причина почти точно в этом плагине или его конфликте.

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

Когда откатывать плагин

Откат плагина нужен, когда после отключения сайт заработал, но функционал плагина критичен: форма заявок, оплата, доставка, личный кабинет, LMS, мультиязычность, SEO, интеграция с CRM или WooCommerce.

Перед откатом проверьте:

• есть ли backup старой версии плагина;
• не изменяла ли новая версия структуру базы данных;
• не закрывала ли новая версия уязвимость безопасности;
• совместима ли старая версия с текущим WordPress и PHP;
• не зависит ли от плагина оплата, заказы, формы или роли пользователей;
• можно ли повторить проблему на staging-копии.

Откат — это способ вернуть сайт в рабочее состояние. После отката всё равно нужно понять, почему новая версия сломала сайт.

Что проверить в WooCommerce

Если обновился WooCommerce-плагин, платёжный модуль, доставка, checkout-плагин, CRM-интеграция или плагин писем, главной страницы недостаточно. Нужно пройти путь покупателя.

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

Что проверить в форме и AJAX

После обновления плагина сайт может открываться, но перестать принимать заявки. Особенно часто это касается Contact Form 7, SMTP, reCAPTCHA, pop-up форм, AJAX-фильтров и интеграций с Telegram/CRM.

• отправляется ли форма;
• приходит ли письмо администратору;
• не попадает ли письмо в спам;
• нет ли JavaScript-ошибок в консоли;
• работает ли admin-ajax.php;
• не блокирует ли запрос WAF или security-плагин;
• не сломался ли nonce;
• не конфликтует ли кеш или минификация JS;
• доходит ли заявка в CRM или Telegram.

Результат

После восстановления нужно получить не просто открывающийся сайт, а понятное состояние проекта.

• сайт открывается;
• wp-admin доступен;
• проблемный плагин найден;
• понятно, что сломалось: PHP, JS, AJAX, база, кеш, WooCommerce или совместимость;
• debug.log проверен после восстановления;
• error_log на хостинге проверен;
• формы заявок протестированы;
• WooCommerce-сценарии проверены, если магазин есть;
• кеш очищен;
• постоянные ссылки работают;
• нет новых 404, 500, 403 или критических ошибок;
• есть новый backup после восстановления;
• обновление повторно проверено на staging или отложено до исправления конфликта.

Дополнительные способы

Режим восстановления WordPress

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

Проверка server error_log

Если debug.log пустой, проверьте серверный error_log в панели хостинга. Иногда PHP-ошибки пишутся только туда.

Проверка версии PHP

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

Проверка кеша и минификации

После обновления плагина старые CSS/JS могут конфликтовать с новыми файлами. Очистите кеш сайта, серверный кеш, CDN и браузер. Минификацию временно отключайте только для диагностики.

Проверка staging-копии

Если сайт важен для заявок, заказов или рекламы, повторяйте обновление на staging. Это помогает найти конфликт без риска для рабочего сайта.

Частые ошибки

• Продолжать обновлять остальные плагины. Так сложнее понять, какой компонент сломал сайт.
• Удалять плагин вместо временного отключения. Можно потерять файлы, настройки или следы ошибки.
• Не делать backup. Без копии откат становится сложнее.
• Отключать все плагины без необходимости. Это может сломать формы, WooCommerce, SEO, мультиязычность и интеграции.
• Не читать debug.log. Лог часто сразу показывает файл и строку ошибки.
• Считать, что если главная открылась — всё исправлено. Могут оставаться сломанными формы, checkout, письма или AJAX.
• Откатывать старую версию навсегда. Старая версия может содержать уязвимость или конфликтовать с будущими обновлениями.
• Не проверять PHP-версию. Новая версия плагина может требовать другое окружение.
• Не очищать кеш. Старые CSS/JS могут продолжать ломать сайт после исправления.

Диагностика проблем

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

Что происходит	Что может быть причиной	Что делать
Сайт ломается сразу после активации плагина	fatal error, несовместимость PHP, конфликт с темой	включить debug.log, проверить путь ошибки, отключить плагин
Ошибка появляется только в админке	admin hooks, AJAX, REST API, page builder, security-плагин	проверить wp-admin, Network, error_log, admin-ajax.php
Ошибка только на фронтенде	шорткод, виджет, шаблон, CSS/JS, кеш	проверить страницу с проблемой, консоль браузера, шаблон темы
Форма не отправляется	AJAX, reCAPTCHA, SMTP, JS-конфликт	проверить консоль, Network, почтовые логи, WAF
Checkout зависает	wc-ajax, оплата, доставка, сессии, кеш	проверить WooCommerce logs, консоль, исключения кеша
Ошибка только у гостей	кеш, права, security-плагин, JS, сессии	проверить инкогнито, другой браузер, кеш и роли
Ошибка только на мобильном	адаптивный JS, lazy load, оптимизация CSS, кеш	проверить mobile view, консоль, отключить оптимизацию для теста
Плагин не обновился полностью	права файлов, нехватка места, обрыв запроса	проверить FTP, место на диске, права файлов, установить плагин вручную
Сайт стал медленным	cron, база, внешние API, тяжёлые запросы	проверить Query Monitor, cron events, server logs

Как безопасно повторить обновление

После восстановления не стоит сразу снова нажимать “обновить”. Сначала нужно подготовить безопасный повтор.

1. Создайте свежий backup рабочего состояния.
2. Создайте staging-копию сайта.
3. На staging включите debug.log.
4. Повторите обновление проблемного плагина.
5. Проверьте, повторяется ли ошибка.
6. Проверьте PHP-версию и совместимость.
7. Отключите кеш и минификацию только для диагностики.
8. Проверьте конфликт с темой и другими плагинами.
9. Если причина найдена — исправьте её на staging.
10. Только после проверки переносите решение на рабочий сайт.

Для общей профилактики полезно соблюдать безопасный порядок обновлений: backup, staging, поэтапное обновление и проверка ключевых функций. Подробно это разобрано в статье обновление WordPress, темы и плагинов: как делать безопасно.

FAQ

Что делать, если после обновления плагина сломался сайт WordPress?

Сделайте backup, включите debug.log, проверьте error_log, отключите проблемный плагин через FTP/SFTP или WP-CLI, очистите кеш, проверьте сайт и решите: откатить плагин, исправить конфликт или обновить окружение.

Как отключить плагин, если не работает админка?

Через FTP/SFTP откройте /wp-content/plugins/ и переименуйте папку проблемного плагина. После этого WordPress отключит его автоматически.

Можно ли просто удалить плагин?

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

Почему после обновления плагина появилась критическая ошибка?

Обычно причина в PHP fatal error: несовместимость с версией PHP, конфликт с темой, другим плагином, отсутствующим классом, изменённой функцией или повреждённым обновлением.

Что делать, если debug.log пустой?

Проверьте, правильно ли включён WP_DEBUG_LOG, есть ли права на запись в wp-content, и посмотрите server error_log в панели хостинга. Иногда ошибки пишутся только в серверный лог.

Как откатить плагин на старую версию?

Безопаснее откатывать из backup или на staging-копии. Если админка доступна, можно использовать инструмент отката, но сначала проверьте, не закрывала ли новая версия важную уязвимость.

Почему после обновления сломалась только форма?

Вероятные причины: JavaScript-конфликт, AJAX-ошибка, reCAPTCHA, nonce, SMTP, кеш, WAF или изменение логики самого плагина формы.

Почему после обновления сломался WooCommerce?

Причина может быть в checkout, wc-ajax, сессиях, доставке, оплате, webhook, callback, письмах или конфликте с кешем. Проверять нужно весь путь заказа, а не только главную страницу.

Нужно ли восстанавливать весь сайт из backup?

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

Как не допустить такой проблемы снова?

Делайте backup перед обновлениями, обновляйте плагины по одному, проверяйте changelog, используйте staging, контролируйте debug.log, не держите устаревшие плагины и тестируйте формы, WooCommerce, админку и мобильную версию после обновления.

Вывод

Если после обновления плагина сломался сайт WordPress, главное — не паниковать и не делать хаотичных действий. Безопасный порядок такой: backup, debug.log, error_log, отключение конкретного плагина, очистка кеша, проверка сайта, откат или исправление конфликта.

После восстановления нужно не просто вернуть сайт “как было”, а понять причину: несовместимость PHP, конфликт плагинов, ошибка темы, проблема кеша, WooCommerce, AJAX, REST API или повреждённое обновление. Тогда следующее обновление можно провести безопасно через staging и проверку ключевых сценариев.