Конфликт плагинов WordPress: как найти виновника через WP-CLI и логи без поломки сайта

После обновления WordPress, темы или плагина сайт может внезапно показать critical error, белый экран, сломанный checkout или бесконечный запрос в admin-ajax. Самый рискованный способ искать причину — хаотично отключать всё подряд на рабочем сайте. Так легко потерять исходное состояние и создать новые проблемы.

Надёжная диагностика строится иначе: сначала фиксируем симптом и ошибку, затем проверяем окружение и только после этого изолируем конкретный компонент. WP-CLI особенно полезен, когда wp-admin уже недоступен.

Сначала зафиксируйте ошибку

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

Не начинайте с очистки всех логов и переустановки WordPress. Логи могут содержать единственную строку, которая сразу показывает файл, класс или функцию-виновника.

Включаем логирование без вывода ошибок посетителю

WordPress поддерживает отладочные константы WP_DEBUG и WP_DEBUG_LOG. На production обычно не нужно показывать PHP-ошибки в браузере, поэтому WP_DEBUG_DISPLAY оставляют выключенным.

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

После воспроизведения ошибки проверьте wp-content/debug.log. На сервере также полезны PHP-FPM, Nginx или Apache error logs: fatal error может возникнуть раньше, чем WordPress успеет записать собственный лог.

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

Важнее не количество предупреждений, а первая ошибка, связанная с моментом сбоя. Ищите PHP Fatal error, Uncaught Error, TypeError, Allowed memory size exhausted и стек вызовов.

Путь вида wp-content/plugins/example-plugin/... часто указывает на компонент, где ошибка проявилась, но не всегда доказывает, что именно он первопричина. Один плагин может вызвать функцию другого или получить неожиданные данные после изменения API.

Проверяем состояние через WP-CLI

Официальный WP-CLI позволяет получить список плагинов без входа в админку:

wp plugin list

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

wp plugin list --status=active --fields=name,status,version,update

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

wp --skip-plugins plugin list

Важно: MU-плагины не исчезают от —skip-plugins

--skip-plugins пропускает обычные плагины, но must-use plugins загружаются отдельно. Если ошибка находится в wp-content/mu-plugins/, это нужно учитывать и проверять такой код отдельно.

То же относится к --skip-themes: параметр полезен для диагностики, но не является универсальным способом запустить любой WordPress с полностью пустым окружением.

Не отключайте все плагины сразу на production

Команда wp plugin deactivate --all существует, но на интернет-магазине или рабочем сервисе она может отключить платежи, мультиязычность, безопасность, интеграции и фоновые процессы. Использовать её на production без плана восстановления опасно.

Если лог уже указывает на конкретный плагин, безопаснее начать с него:

wp plugin deactivate plugin-slug

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

Бинарная изоляция на staging

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

На рабочем магазине staging особенно важен: отключение WooCommerce, платёжного шлюза, кеша или интеграции склада ради эксперимента может повлиять на реальные заказы.

Проверяем конфликт с темой

Ошибка может зависеть не от двух плагинов, а от плагина и темы. Для диагностической команды можно использовать --skip-themes, а на staging временно активировать стандартную тему WordPress.

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

Проверяем PHP и память

После обновления плагин может использовать синтаксис или функции, несовместимые с текущей версией PHP. Сначала узнайте фактическую версию CLI и PHP-FPM: они могут отличаться.

php -v
wp --info

Если в логе Allowed memory size exhausted, не спешите просто увеличивать лимит. Нужно понять, это реальная нехватка памяти под рабочую операцию или бесконечный цикл, огромный запрос либо несовместимость, которая съедает память.

Проверяем cron и фоновые задачи

Некоторые конфликты проявляются только в WP-Cron, очередях WooCommerce Action Scheduler, импорте или webhook. Страница сайта при этом может работать нормально.

WP-CLI позволяет посмотреть cron-события:

wp cron event list

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

После нахождения виновника

Отключить плагин — не всегда решение. Нужно определить причину: несовместимая версия, вызов удалённой функции, конфликт имени, неправильный тип данных, изменение WooCommerce API, PHP-версия или порядок загрузки.

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

Чего не стоит делать

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

Рабочая последовательность диагностики

1. Зафиксировать симптом, время и последние изменения.
2. Сделать резервную копию перед изменениями.
3. Получить PHP/server и WordPress logs.
4. Проверить активные плагины и версии через WP-CLI.
5. Использовать --skip-plugins или --skip-themes для диагностических команд при необходимости.
6. Проверить конкретный подозреваемый компонент.
7. Для сложного конфликта перенести проверку на staging и изолировать компоненты группами.
8. После исправления повторить исходный сценарий и проверить логи ещё раз.

Когда нужна техническая диагностика

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

В технической поддержке WordPress A.S Groups можно провести диагностику на уровне WordPress, PHP и сервера, найти конфликт и исправить причину с минимальным вмешательством в рабочий сайт. Для сложных случаев сначала фиксируем текущее состояние и только затем меняем конфигурацию.