Конфлікт плагінів WordPress може повністю вивести сайт з ладу: сторінки перестають відкриватися, з’являється білий екран, виникає помилка 500 або користувачі не можуть оформити замовлення. Часто проблема виникає після встановлення, оновлення чи зміни налаштувань одного з компонентів, але не завжди винен саме останній плагін.
Перед будь-якими змінами бажано створити резервну копію файлів і бази даних. Якщо сайт уже недоступний, попросіть хостинг зробити snapshot або копію середовища. Неправильне видалення файлів, редагування бази даних чи масове відключення компонентів може призвести до втрати налаштувань і додаткових пошкоджень.
Ознаки конфлікту плагінів
Конфлікт варто підозрювати, якщо збій з’явився одразу після оновлення або встановлення плагіна. Типові симптоми:
- білий екран замість сайту або панелі керування;
- помилка
500 Internal Server Error,503 Service Unavailableчи повідомлення про критичну помилку WordPress; - адмінка відкривається частково, але окремі розділи не працюють;
- помилки виникають лише під час оформлення замовлення, оплати, авторизації або завантаження файлів;
- сторінки завантажуються повільно, зависають або повертають помилки AJAX;
- після оновлення зникають елементи теми, віджети, форми чи функції WooCommerce.
Причиною може бути несумісність версій WordPress, PHP, теми та плагінів. Також можливі дублювання функцій, конфлікт JavaScript-бібліотек, перевищення ліміту пам’яті PHP, пошкоджені файли або втручання шкідливого коду. Тому не варто автоматично звинувачувати один компонент без перевірки журналів помилок.
Відключення без адмінки
Якщо панель WordPress не відкривається, плагіни можна тимчасово вимкнути через файловий менеджер хостингу або SFTP. Спочатку відкрийте каталог wp-content/plugins і перейменуйте папку plugins, наприклад на plugins-disabled. WordPress не знайде компоненти й деактивує їх.
Якщо після цього сайт запрацював, поверніть папці початкову назву. Потім перейменовуйте каталоги окремих плагінів по одному, наприклад woocommerce на woocommerce-disabled, перевіряючи сайт після кожної зміни.
Інший спосіб — деактивація через базу даних. У таблиці параметрів WordPress запис активних плагінів зазвичай зберігається в полі active_plugins. Редагувати його вручну ризиковано: помилка у форматі serialized-даних може пошкодити налаштування. Перед такою операцією обов’язково зробіть копію бази даних і не змінюйте інші записи без розуміння їхнього призначення.
Якщо доступ до файлів і бази даних відсутній, зверніться до хостинг-провайдера або спеціаліста. Не слід навмання видаляти плагіни: деякі з них створюють власні таблиці, налаштування, правила доступу або пов’язані з критично важливими функціями сайту.
Пошук проблемного компонента
Після вимкнення всіх плагінів потрібно встановити, який саме компонент спричиняє збій. Активуйте їх по одному, щоразу перевіряючи головну сторінку, адмінку та функції, пов’язані з помилкою.
- Залиште всі плагіни вимкненими й перевірте, чи працює сайт.
- Увімкніть один плагін.
- Очистьте кеш WordPress, сервера, CDN і браузера, якщо вони використовуються.
- Перевірте сторінку або дію, під час якої виникала помилка.
- Зафіксуйте результат і переходьте до наступного компонента.
Якщо проблема з’являється після активації конкретного плагіна, це ще не доводить його несправність. Він може конфліктувати з темою, версією PHP або іншим уже активним компонентом. Для точнішої перевірки залиште підозрілий плагін увімкненим, а решту деактивуйте. Потім активуйте їх по одному, щоб знайти пару або групу, яка викликає збій.
Корисну інформацію дають журнали помилок хостингу, debug.log WordPress і журнали самого плагіна. Режим відладки не варто надовго залишати увімкненим на робочому сайті, оскільки повідомлення можуть містити шляхи до файлів, фрагменти запитів або інші технічні дані.
Якщо після деактивації плагінів помилка не зникає, перевірте тему, версію PHP, права доступу до файлів, ліміти пам’яті, конфігурацію сервера та можливе зараження. У такій ситуації проблема може бути не конфліктом, а пошкодженням ядра, бази даних або стороннім втручанням.
Тестування сумісності
Коли проблемний компонент визначено, не поспішайте одразу його видаляти. Перевірте, чи є оновлення плагіна, WordPress і теми, а також чи підтримує поточна версія плагіна встановлену версію PHP. Перед оновленням зробіть резервну копію та, за можливості, протестуйте зміни на копії сайту або staging-середовищі.
Важливо врахувати порядок оновлень. Масове оновлення всіх компонентів одночасно ускладнює пошук причини. Краще змінювати по одному елементу й фіксувати результат. Якщо конфлікт почався після оновлення, перевірте попередню версію лише з надійного джерела та усвідомлюйте ризики безпеки застарілого коду.
Для інтернет-магазину необхідно окремо перевірити картку товару, кошик, оформлення замовлення, способи оплати, доставку, листи та облік замовлень. Після збою в магазині може знадобитися Ремонт WooCommerce після конфлікту плагінів, особливо якщо помилки зачіпають замовлення або транзакції.
Якщо помилка виникає лише в окремому браузері чи для певної ролі користувача, перевірте консоль браузера, кеш, права доступу та JavaScript-конфлікти. Коли проблема пов’язана із запитами AJAX, просте вимкнення PHP-плагіна може не пояснити причину — потрібен аналіз мережевих запитів і серверних журналів.
Безпечне повернення функцій
Після виявлення конфлікту не повертайте всі компоненти одночасно. Залиште активними лише необхідні плагіни, відновіть їх у контрольованому порядку та після кожної зміни перевіряйте ключові функції сайту.
- збережіть копію робочого стану перед новими змінами;
- видаліть або замініть проблемний компонент лише після перевірки залежностей;
- перевірте налаштування теми й плагінів після деактивації;
- очистьте кеші та оновіть правила постійних посилань, якщо змінилися маршрути;
- перевірте форми, авторизацію, мобільну версію, замовлення та повідомлення про помилки;
- перегляньте журнали сервера протягом певного часу після відновлення.
Якщо сайт працює нестабільно, виникають повторні помилки, пошкоджені дані або є підозра на вірус, краще припинити експерименти на робочій копії. Спеціаліст може ізолювати проблему, перевірити файли та базу даних, порівняти резервні копії, оцінити сумісність версій і підготувати безпечний план відновлення без необґрунтованого ризику втрати даних.
Після ремонту варто налаштувати регулярні резервні копії, контроль оновлень, обмеження доступу до адмінки та моніторинг помилок. Це не усуває всі ризики, але допомагає швидше виявити повторний конфлікт і відновити працездатність сайту з меншою кількістю втручань.