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

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

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

После обновления плагина сайт может показать белый экран, ошибку 500, критическую ошибку, 403, сломанный дизайн, неработающую админку, ошибку checkout WooCommerce или перестать отправлять формы. Важно не просто вернуть сайт, а понять, какой компонент вызвал сбой.

Если после обновления появилась пустая страница, используйте инструкцию белый экран WordPress после обновления. Если сайт отдаёт внутреннюю ошибку сервера, ближе подойдёт материал ошибка 500 WordPress. Если из-за обновления перестала открываться панель управления, смотрите не работает админка WordPress.

Причина

Плагин после обновления может изменить PHP-код, hooks, AJAX-обработчики, REST API endpoints, шаблоны, JavaScript, стили, структуру базы данных или зависимости. Если сайт, тема, другой плагин или версия PHP не готовы к этим изменениям, WordPress ломается.

Частые причины:

• PHP fatal error — новая версия плагина вызывает критическую ошибку.
• Несовместимость с версией PHP — плагин требует более новую версию PHP или ломается на текущей.
• Конфликт с темой — тема переопределяет шаблоны, функции или hooks плагина.
• Конфликт с другим плагином — два плагина меняют одну и ту же логику.
• Нехватка памяти — после обновления плагин стал тяжелее или запускает миграцию данных.
• Незавершённое обновление — часть файлов обновилась, часть осталась старой.
• Проблема с кешем — старые CSS, JS, page cache, object cache или CDN конфликтуют с новой версией.
• Ошибка в базе данных — плагин обновил таблицы, опции или метаданные, но процесс оборвался.
• Security-плагин или WAF заблокировал запрос — особенно при AJAX, REST API, формах, checkout и сохранении настроек.
• Плагин изменил логику WooCommerce — сломались корзина, checkout, оплата, доставка или статусы заказов.
• Плагин несовместим с кастомным кодом — старые snippets, функции в functions.php или самописный мини-плагин больше не подходят.

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

Диагностика

Сначала определите, как именно сломался сайт. Это важнее, чем сразу отключать всё подряд.

Симптом после обновления	Вероятная причина	Что проверить первым
Белый экран	PHP fatal error, тема, память, конфликт плагинов	debug.log, error_log, обновлённый плагин
Ошибка 500	PHP, .htaccess, память, сервер, несовместимость	логи, .htaccess, плагины через FTP
Критическая ошибка WordPress	фатальная ошибка в плагине, теме или кастомном коде	Recovery Mode, debug.log, путь к файлу ошибки
Не открывается админка	security, плагин админки, PHP fatal error, редирект	/wp-login.php, FTP, логи, cookies, security-плагин
Сломалась вёрстка	кеш CSS/JS, конфликт темы, изменились классы или шаблоны	очистка кеша, консоль браузера, шаблоны темы
Не работает форма	AJAX, reCAPTCHA, SMTP, REST API, WAF, JS-ошибка	Network, console, admin-ajax.php, SMTP-логи
Сломался WooCommerce checkout	оплата, доставка, сессии, кеш, wc-ajax, конфликт	логи WooCommerce, checkout, кеш, платёжный модуль
Сайт работает, но админка тормозит	миграция данных, cron, тяжёлые запросы, autoloaded options	логи, cron, база данных, Query Monitor

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

• Какой именно плагин обновлялся последним?
• Обновлялся один плагин или сразу несколько?
• Есть ли резервная копия до обновления?
• Пришло ли письмо WordPress о Recovery Mode?
• Открывается ли /wp-admin/?
• Открывается ли /wp-login.php?
• Есть ли доступ к FTP/SFTP или файловому менеджеру хостинга?
• Есть ли ошибка в wp-content/debug.log?
• Есть ли записи в error_log хостинга?
• Сломалась публичная часть сайта, админка, форма, WooCommerce или всё сразу?

Решение

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

1. Остановите дальнейшие обновления

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

2. Сделайте резервную копию текущего состояния

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

Сохраните минимум:

• папку wp-content;
• файл wp-config.php;
• файл .htaccess;
• экспорт базы данных;
• логи ошибок.

3. Проверьте Recovery Mode

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

Проверьте:

• почту администратора сайта;
• папку “Спам”;
• адрес администратора в базе данных, если почта не приходит;
• логи SMTP, если сайт использует SMTP-плагин.

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

4. Отключите обновлённый плагин через FTP

Через FTP/SFTP или файловый менеджер хостинга откройте папку:

wp-content/plugins/

Найдите папку плагина, который обновлялся последним, и переименуйте её. Например:

• было: plugin-name
• стало: plugin-name-disabled

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

5. Если обновлялось несколько плагинов

Если вы не знаете, какой плагин виноват, временно переименуйте всю папку:

• было: wp-content/plugins
• стало: wp-content/plugins-disabled

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

Важно: на WooCommerce-сайте отключение всех плагинов может временно отключить магазин, оплату, доставку, письма, формы и интеграции. Делайте это аккуратно, желательно на копии сайта или в момент минимальной активности.

6. Включите debug.log

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

Чаще всего путь в ошибке сразу указывает направление:

• wp-content/plugins/plugin-name/... — проблема в плагине;
• wp-content/themes/theme-name/... — проблема в теме;
• wp-includes/... — может быть конфликт с ядром, несовместимый код или повреждённое обновление;
• wp-content/mu-plugins/... — проблема в обязательном плагине;
• wp-content/object-cache.php — возможен конфликт object cache.

7. Проверьте тему

Иногда обновился плагин, но ломает сайт именно тема. Например, тема переопределяла шаблоны WooCommerce, использовала старые функции плагина или зависела от старых hooks.

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

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

8. Проверьте PHP-версию и память

После обновления плагин может начать требовать другую версию PHP или больше памяти.

Проверьте:

• текущую версию PHP на хостинге;
• требования плагина;
• ошибки Allowed memory size exhausted;
• ошибки TypeError, Class not found, Call to undefined function;
• лимиты memory_limit, max_execution_time, max_input_vars.

9. Очистите кеш

После обновления могут конфликтовать старые кешированные файлы и новая версия плагина.

Проверьте:

• кеш плагина WordPress;
• серверный кеш хостинга;
• Object Cache / Redis / Memcached;
• Cloudflare или другой CDN;
• кеш браузера;
• кеш конструктора страниц;
• минификацию CSS/JS.

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

10. Решите: откат, исправление или замена плагина

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

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

Код

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

Включить debug.log в wp-config.php

Куда вставлять: файл wp-config.php, перед строкой /* That's all, stop editing! */.

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

Увеличить память WordPress

Важно: это помогает только при нехватке памяти. Если причина в синтаксической ошибке, несовместимости или конфликте плагина, увеличение памяти не исправит проблему.

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

Отключить конкретный плагин через WP-CLI

Важно: отключайте сначала тот плагин, который обновлялся последним.

wp plugin deactivate plugin-name

Отключить все плагины через WP-CLI

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

wp plugin deactivate --all

Посмотреть список плагинов и версии

wp plugin list

Откатить плагин через WP-CLI, если есть zip-файл старой версии

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

wp plugin deactivate plugin-name
wp plugin delete plugin-name
wp plugin install /path/to/plugin-old-version.zip --activate

Переключить тему через WP-CLI

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

wp theme list
wp theme activate twentytwentyfour

Проверить целостность ядра WordPress

wp core verify-checksums

Результат

После правильной диагностики должен быть понятен не только факт поломки, но и источник:

• обновлённый плагин вызывает PHP fatal error;
• плагин конфликтует с темой;
• плагин конфликтует с другим плагином;
• сайту не хватает памяти;
• текущая версия PHP несовместима;
• обновление оборвалось и часть файлов повреждена;
• кеш отдаёт старые CSS/JS или старый PHP object cache;
• WAF или security-плагин блокирует новые запросы;
• после обновления сломался WooCommerce checkout, форма или REST API;
• нужен откат, исправление кода или замена плагина.

Хороший результат — сайт снова открывается, админка доступна, формы отправляются, WooCommerce принимает заказы, ошибок в логах нет, а обновлённый плагин либо исправлен, либо откатан, либо заменён.

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

Если сайт показывает “На сайте произошла критическая ошибка”

Проверьте email администратора и Recovery Mode. Если письма нет, включите debug.log и ищите путь к файлу, который вызвал ошибку.

Если обновление оборвалось

Проверьте файл:

.maintenance

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

Если сломалась только админка

Проверьте плагины, которые работают в панели управления: SEO, WooCommerce, security, кеш, редакторы страниц, импорт/экспорт, бэкапы, аналитика, CRM, кастомные админ-модули.

Если сломался только дизайн

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

Если сломался WooCommerce

Проверьте корзину, checkout, оплату, доставку, письма, сессии, wc-ajax, кеш и логи WooCommerce. После любого восстановления магазина сделайте тестовый заказ.

Если плагин нужен, но новая версия ломает сайт

Не всегда правильное решение — навсегда остаться на старой версии. Нужно понять, почему новая версия ломает сайт:

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

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

• Обновлять всё подряд после первой ошибки. Так вы теряете понимание, какой плагин сломал сайт.
• Удалять плагин вместо отключения. Можно потерять настройки, таблицы или данные интеграции.
• Не делать копию перед восстановлением. Даже сломанный сайт нужно сохранить перед правками.
• Отключать все плагины на WooCommerce без проверки рисков. Это может остановить оплату, доставку и заказы.
• Не смотреть debug.log. Лог часто сразу показывает файл и строку ошибки.
• Сразу откатывать весь сайт. Иногда достаточно откатить один плагин.
• Оставлять старую версию плагина навсегда. Это может создать проблемы безопасности и совместимости.
• Игнорировать PHP-версию. Новая версия плагина может требовать другую среду.
• Чистить базу без копии. Можно повредить настройки сайта, плагинов, WooCommerce или форм.
• Проверять только главную. Нужно проверить админку, формы, заказы, письма, REST API, AJAX и мобильную версию.

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

Чеклист восстановления после обновления плагина

1. Зафиксируйте, какой плагин обновлялся.
2. Остановите дальнейшие обновления.
3. Сделайте копию файлов и базы.
4. Проверьте письмо Recovery Mode.
5. Включите WP_DEBUG_LOG.
6. Проверьте wp-content/debug.log.
7. Проверьте error_log хостинга.
8. Отключите обновлённый плагин через FTP/SFTP или WP-CLI.
9. Если обновлялось несколько плагинов, отключайте и возвращайте их по одному.
10. Проверьте активную тему и дочернюю тему.
11. Проверьте версию PHP и лимит памяти.
12. Очистите кеш сайта, сервера, object cache и CDN.
13. Проверьте REST API, admin-ajax.php, формы и WooCommerce.
14. Решите: откатить плагин, исправить конфликт, обновить окружение или заменить плагин.
15. После восстановления проверьте сайт полностью, а не только главную страницу.

Что искать в debug.log

• PHP Fatal error — критическая ошибка PHP.
• Parse error — синтаксическая ошибка.
• Uncaught Error — необработанная ошибка.
• Allowed memory size exhausted — закончилась память.
• Cannot redeclare — функция объявлена два раза.
• Call to undefined function — плагин вызывает функцию, которой нет.
• Class not found — отсутствует нужный класс.
• TypeError — несовместимость типов после обновления PHP или плагина.
• Deprecated — устаревший код, если сервер обрабатывает предупреждения как критичные.

Как понять, можно ли просто откатить плагин

Откат обычно подходит, если:

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

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

FAQ

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

Остановите дальнейшие обновления, сделайте копию, проверьте Recovery Mode, включите debug.log, отключите обновлённый плагин через FTP/SFTP или WP-CLI и проверьте сайт.

Можно ли восстановить сайт без доступа к админке?

Да. Обычно используют FTP/SFTP, файловый менеджер хостинга, WP-CLI, базу данных и логи. Через FTP можно отключить проблемный плагин даже без входа в WordPress.

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

Зайдите через FTP/SFTP в wp-content/plugins/ и переименуйте папку проблемного плагина. Если неизвестно, какой плагин виноват, временно переименуйте всю папку plugins.

Нужно ли удалять плагин?

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

Почему после обновления плагина появился белый экран?

Чаще всего из-за PHP fatal error, несовместимости с темой, другим плагином, версией PHP или нехватки памяти. Включите debug.log, чтобы увидеть точную причину.

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

Новая версия плагина может вызывать внутреннюю PHP-ошибку, конфликт с сервером, памятью, темой, .htaccess или WAF. Нужно смотреть WordPress debug.log и error_log хостинга.

Можно ли просто откатить весь сайт из бэкапа?

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

Что делать, если обновлялось сразу несколько плагинов?

Отключите все плагины через FTP или WP-CLI, затем включайте по одному и проверяйте сайт после каждого включения. Так можно найти конкретный конфликт.

Почему сайт работает, но сломалась только админка?

Плагин может ломать только административную часть: меню, редактор, REST API, admin-ajax.php, WooCommerce-отчёты, SEO-панели или кастомные настройки. Смотрите логи и консоль браузера.

Почему сайт работает, но сломался WooCommerce?

Плагин мог изменить checkout, оплату, доставку, сессии, письма, статусы или AJAX. После восстановления обязательно проверьте тестовый заказ, письмо клиенту и статус заказа.

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

Можно временно, если это нужно для восстановления. Но затем нужно проверить безопасность, совместимость и план обновления. Старые версии плагинов могут содержать уязвимости.

Когда лучше заменить плагин?

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

Вывод

Если WordPress сломался после обновления плагина, не нужно хаотично удалять файлы и обновлять всё подряд. Самый безопасный порядок: остановить обновления, сделать копию, проверить Recovery Mode, включить debug.log, отключить обновлённый плагин через FTP или WP-CLI, проверить тему, PHP, память, кеш, логи и основные сценарии сайта.

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