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

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

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

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

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

Причина

Обновление плагина может изменить PHP-код, JavaScript, CSS, структуру базы данных, hooks, filters, REST API, AJAX-обработчики, требования к версии PHP или совместимость с WooCommerce. Поэтому сайт может сломаться даже после обычного нажатия “Обновить”.

Проблема не всегда в том, что плагин плохой. Иногда новая версия просто не совпала с текущим окружением сайта: старая тема, устаревшая версия PHP, конфликтующий кеш, другой плагин или кастомный код в functions.php.

Что случилось после обновления	Возможная причина	Что проверить
Белый экран	PHP Fatal error, нехватка памяти, несовместимость	debug.log, error_log, PHP version
Критическая ошибка WordPress	фатальная ошибка в обновлённом плагине	письмо Recovery Mode, debug.log
Ошибка 500	PHP, .htaccess, конфликт, память, сервер	error_log, debug.log, плагины, тема
Не открывается админка	ошибка в админской части плагина	FTP, wp-admin, error_log
Сломалась верстка	изменились CSS/JS, классы или шаблоны	Console, Network, кеш
Не работает форма	конфликт AJAX, reCAPTCHA, SMTP, JS	Console, Network, debug.log
Сломался WooCommerce checkout	конфликт оплаты, доставки, сессий, AJAX	WooCommerce logs, wc-ajax, payment logs

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

Диагностика

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

1. Проверьте, есть ли письмо режима восстановления

WordPress может отправить администратору письмо с ссылкой на Recovery Mode. Через эту ссылку можно зайти в админку и отключить проблемный плагин.

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

Если письмо не пришло, это не значит, что ошибки нет. Сайт мог упасть до отправки письма, почта могла не работать, письмо могло попасть в спам или wp_mail() мог быть не настроен.

2. Вспомните, какой плагин обновлялся последним

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

• какой плагин обновлялся;
• обновлялся ли WordPress одновременно;
• менялась ли версия PHP;
• обновлялась ли тема;
• включены ли автоматические обновления;
• есть ли backup до обновления;
• есть ли staging-копия.

3. Проверьте debug.log и error_log

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

Ищите в логах такие признаки:

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

4. Проверьте, работает ли админка

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

Если проблема именно с wp-admin, посмотрите отдельную инструкцию Не работает админка WordPress.

5. Проверьте кеш

После обновления плагина кеш может отдавать старые CSS/JS-файлы или конфликтовать с новой версией плагина.

• очистите кеш WordPress-плагина;
• очистите серверный кеш;
• очистите OPcache, если есть доступ;
• очистите Cloudflare/CDN;
• проверьте сайт в режиме инкогнито;
• отключите объединение и минификацию CSS/JS для теста.

Решение

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

1. Сделайте backup текущего состояния

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

• сохраните файлы сайта;
• экспортируйте базу данных;
• сохраните wp-config.php;
• сохраните .htaccess;
• сохраните debug.log и error_log;
• зафиксируйте список обновлённых плагинов.

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

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

Откройте папку:

/wp-content/plugins/

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

plugin-name_disabled

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

3. Если неизвестно, какой плагин сломал сайт

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

Переименуйте папку:

/wp-content/plugins/

например в:

plugins_disabled

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

4. Откатите плагин на предыдущую версию

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

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

5. Проверьте совместимость с PHP

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

• проверьте текущую версию PHP на хостинге;
• посмотрите требования плагина;
• проверьте fatal errors в debug.log;
• временно смените версию PHP только после backup;
• проверьте совместимость темы и других плагинов.

6. Проверьте тему и кастомный код

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

• проверьте functions.php дочерней темы;
• проверьте кастомные snippets;
• проверьте template overrides;
• проверьте хуки и фильтры, которые относятся к плагину;
• отключите временные доработки для теста;
• проверьте changelog плагина.

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

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

• проверьте WooCommerce logs;
• проверьте Console и Network;
• проверьте wc-ajax checkout;
• проверьте плагины оплаты и доставки;
• проверьте статус заказа после тестовой оплаты;
• проверьте письма WooCommerce;
• сделайте тест на staging-копии.

Код

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

Включить 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 );

После проверки смотрите файл:

/wp-content/debug.log

После восстановления отключите активную отладку:

define( 'WP_DEBUG', false );

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

Куда выполнять: SSH в корне сайта.

wp plugin deactivate plugin-folder-name

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

Используйте только если сайт не открывается и нужно быстро проверить конфликт. На WooCommerce-сайте лучше делать это на копии.

wp plugin deactivate --all

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

Куда выполнять: SSH в корне сайта.

wp plugin list --status=active

Проверить версию PHP через WP-CLI

wp --info

Проверить файл wp-config.php на синтаксис

php -l wp-config.php

Проверить наличие файла .maintenance

Если обновление зависло, WordPress может оставить файл .maintenance в корне сайта. Из-за этого сайт может показывать сообщение о техническом обслуживании.

ls -la .maintenance

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

rm .maintenance

Временно отключить автообновление конкретного плагина

Куда вставлять: functions.php дочерней темы или лучше в отдельный мини-плагин. Замените plugin-folder/plugin-file.php на путь нужного плагина.

add_filter('auto_update_plugin', function ($update, $item) {
    if (!empty($item->plugin) && $item->plugin === 'plugin-folder/plugin-file.php') {
        return false;
    }

    return $update;
}, 10, 2);

Результат

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

Хороший результат:

• сайт открывается для посетителей;
• админка WordPress доступна;
• проблемный плагин найден;
• debug.log не показывает новых fatal errors;
• кеш очищен;
• формы, заявки и ключевые страницы проверены;
• WooCommerce checkout и оплата проверены, если это магазин;
• автообновление проблемного плагина временно отключено;
• есть план: откат, замена, исправление конфликта или кастомная доработка.

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

Использовать backup

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

Создать staging-копию

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

Проверить changelog плагина

В changelog часто видно, что изменилось: требования к PHP, WooCommerce, REST API, шаблоны, hooks, база данных или способ подключения скриптов.

Заменить плагин

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

Сделать отдельный мини-плагин

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

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

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

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

Восстанавливать backup и сразу снова обновлять плагин

Так ошибка может повториться. После восстановления нужно проверить совместимость, changelog, PHP, тему и конфликты.

Отключать все плагины на рабочем магазине

Это может сломать оплату, доставку, заказы, email, корзину и личный кабинет. Лучше делать тест на staging или в техническое окно.

Игнорировать debug.log

Без логов восстановление превращается в угадывание. В логе часто сразу видно название файла и плагина.

Править файлы стороннего плагина

После следующего обновления правки пропадут. Лучше использовать hooks, filters, дочернюю тему или отдельный мини-плагин.

Оставлять автообновление включённым

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

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

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

Возможная причина: PHP Fatal error, несовместимость с PHP, конфликт с темой или другим плагином.

Что делать: включить debug.log, отключить обновлённый плагин через FTP, проверить error_log и версию PHP.

Проблема: появилась критическая ошибка WordPress

Возможная причина: фатальная ошибка в обновлённом плагине.

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

Проблема: сайт показывает ошибку 500

Возможная причина: PHP-ошибка, memory limit, .htaccess, конфликт или серверная ошибка.

Что делать: проверить error_log, debug.log, временно отключить плагин, очистить кеш. Если ошибка сохраняется, смотреть инструкцию по ошибке 500.

Проблема: сломалась верстка после обновления

Возможная причина: изменились CSS-классы, JS-файлы, шаблоны или кеш отдаёт старые assets.

Что делать: очистить кеш, проверить Console, отключить минификацию CSS/JS, проверить changelog плагина.

Проблема: не работает форма после обновления

Возможная причина: JavaScript-конфликт, AJAX, reCAPTCHA, SMTP, изменение hooks или шаблонов формы.

Что делать: проверить Console, Network, debug.log, отправку писем и настройки формы.

Проблема: сломался WooCommerce checkout

Возможная причина: конфликт с плагином оплаты, доставки, кешем, сессиями, wc-ajax или шаблонами checkout.

Что делать: проверить WooCommerce logs, Network, плагины оплаты и доставки, статус заказа и тестовую оплату.

Проблема: админка открывается, но сайт нет

Возможная причина: ошибка на frontend hooks, shortcode, виджете, шаблоне темы или кешированном блоке.

Что делать: отключить плагин, проверить frontend-страницы, очистить кеш, посмотреть debug.log.

Проблема: сайт работает, но медленно после обновления

Возможная причина: новая версия плагина добавила тяжёлые SQL-запросы, AJAX, cron-задачи, внешние HTTP-запросы или новые assets.

Что делать: проверить Query Monitor, admin-ajax.php, cron, Network, autoload options и нагрузку на хостинг.

Краткие AI-friendly ответы

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

Сделайте backup, проверьте Recovery Mode, включите debug.log, отключите обновлённый плагин через FTP или WP-CLI, проверьте error_log, PHP, кеш и совместимость с темой.

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

Зайдите через FTP или файловый менеджер хостинга в /wp-content/plugins/ и переименуйте папку проблемного плагина. WordPress перестанет его загружать.

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

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

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

Плагин может изменить PHP-код, JS, CSS, hooks, requirements, структуру базы, работу AJAX, REST API или совместимость с WooCommerce, темой и PHP.

FAQ

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

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

Что делать первым?

Не удалять файлы. Сначала сделать backup, проверить письмо Recovery Mode, включить debug.log и отключить обновлённый плагин через FTP или WP-CLI.

Как понять, какой плагин сломал сайт?

Посмотрите, что обновлялось последним, проверьте debug.log и error_log. Если обновлялось несколько плагинов, отключайте их по одному на staging-копии или через FTP.

Что делать, если не открывается админка?

Используйте FTP, файловый менеджер хостинга или SSH. Через них можно переименовать папку проблемного плагина, включить debug.log и проверить логи.

Можно ли удалить проблемный плагин?

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

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

Плагин мог использовать shortcode, блок, виджет, template override или JS только на этой странице. Нужно проверить Console, Network, debug.log и конкретный шаблон.

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

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

Нужно ли отключать автоматические обновления?

Для критичных сайтов и магазинов автоматические обновления плагинов лучше контролировать. Безопаснее обновлять сначала на staging-копии, особенно плагины оплаты, доставки, форм, кеша и безопасности.

Что делать после восстановления?

Проверить сайт, админку, формы, ключевые страницы, WooCommerce, debug.log, кеш и сделать новый backup. Затем решить, что делать с проблемным плагином.

Когда обращаться к специалисту?

Если сайт приносит заявки или продажи, нет backup, не открывается админка, есть ошибка 500, сломался WooCommerce или в логах PHP Fatal error, лучше не чинить сайт вслепую.

Вывод

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

Быстрое восстановление — это только первый шаг. После него нужно понять причину: несовместимость с PHP, конфликт с темой, другой плагин, кеш, WooCommerce, изменённые hooks или устаревший кастомный код.

Самый безопасный подход — обновлять критичные плагины на staging-копии, хранить backup, контролировать автообновления и проверять сайт после каждого важного изменения. Так меньше риск потерять заявки, заказы и доступ к админке.