Konflikt wtyczek nie zawsze wygląda jak spektakularny błąd. Czasem znika przycisk w koszyku, formularz nie wysyła wiadomości, edytor blokowy przestaje zapisywać, a zadanie cron nie wykonuje się do końca. Problem może wynikać z konfliktu hooków, różnych wersji bibliotek JavaScript, nadpisywania tych samych opcji albo błędnego założenia jednego dodatku o działaniu drugiego.
Szybka odpowiedź
Najlepszy test nie polega na wyłączeniu trzydziestu wtyczek na żywej stronie. Odtwórz problem na stagingu, włącz logowanie błędów, a następnie izoluj komponenty. Jeśli podejrzewasz konkretną aktualizację, zacznij od niej. Jeśli nie — dziel zestaw rozszerzeń na grupy, aby szybciej zawęzić przyczynę.
Najpierw odtwórz błąd
Zapisz dokładne kroki: użytkownik wchodzi na konkretną stronę, wybiera opcję, klika przycisk i wtedy występuje błąd. Bez powtarzalnego scenariusza łatwo uznać, że „już działa”, choć problem pojawia się tylko dla określonej roli, produktu albo urządzenia. Dobry przypadek testowy skraca diagnostykę wielokrotnie.
Sprawdź konsolę i logi PHP
Konflikty frontendowe często zostawiają błędy JavaScript w konsoli, a backendowe — wyjątki i ostrzeżenia w logach PHP. Jeśli dwa rozszerzenia definiują tę samą funkcję, ładują niezgodną bibliotekę lub przekazują zły typ danych, log może wskazać dokładny plik. To lepsze niż losowe przełączanie ustawień.
Test binarny zamiast pojedynczego wyłączania
Przy dużej liczbie wtyczek można wyłączyć połowę na stagingu, sprawdzić błąd i na tej podstawie zawęzić grupę. Kilka iteracji pozwala znaleźć problem szybciej niż testowanie po jednej. Na produkcji taka metoda jest ryzykowna, bo każda grupa może zawierać element odpowiedzialny za płatności, bezpieczeństwo lub formularze.
Konflikt po aktualizacji nie musi oznaczać „złej wtyczki”
Nowa wersja może poprawnie wdrożyć zmianę API, podczas gdy drugi, nieaktualny komponent nadal oczekuje starego zachowania. Dlatego sprawdź oba changelogi i kompatybilność. Czasem rozwiązaniem jest aktualizacja drugiego dodatku, a nie cofanie pierwszego na miesiące.
Po znalezieniu pary potrzebna jest decyzja
Tymczasowe wyłączenie jednego rozszerzenia kończy awarię, ale nie zawsze temat. Oceń, która funkcja jest ważniejsza, czy istnieje aktualizacja, poprawka producenta, zamiennik lub możliwość usunięcia dublującej funkcji. Im mniej zbędnych dodatków, tym mniejsza powierzchnia przyszłych konfliktów.
Jak potwierdzić, że naprawa naprawdę działa?
Po znalezieniu konfliktu przygotuj mały test regresji obejmujący obie funkcje. Jeśli problem dotyczył płatności i cache, sprawdź koszyk jako użytkownik anonimowy i zalogowany, różne metody płatności oraz opróżnianie cache. Jeżeli konflikt był w JavaScript, przetestuj mobile i desktop. Ważne jest udowodnienie, że naprawa zachowała funkcję obu komponentów albo świadomie zastąpiła jeden z nich.
Co obserwować po zmianie?
Zapisz wersje wtyczek, WordPressa i PHP, na których konflikt został potwierdzony. Ta informacja przyda się przy kolejnych aktualizacjach. Obserwuj logi po wdrożeniu oraz changelogi producentów — oficjalna poprawka może pozwolić usunąć tymczasowe obejście, które w przeciwnym razie zostanie w projekcie na lata.
Kiedy przekazać temat dalej?
Eskaluj, jeśli konflikt dotyczy płatności, danych klientów, uprawnień albo niestandardowego kodu, którego nikt nie zna. Wyłączenie jednego dodatku może zakończyć objaw, ale zostawić lukę funkcjonalną. Przy krytycznych funkcjach potrzebna jest decyzja architektoniczna i test na stagingu.
Praktyczny scenariusz diagnostyczny
Załóżmy, że po instalacji wtyczki cache przestaje działać formularz. Wyłączenie cache rozwiązuje problem, ale to dopiero wskazówka. Sprawdź, czy formularz używa nonce, AJAX lub REST API i czy odpowiedź została omyłkowo zbuforowana. Wyklucz odpowiednią ścieżkę lub endpoint z cache, odtwórz scenariusz i dopiero wtedy włącz wtyczkę ponownie. Przy konflikcie dwóch dodatków test „wyłącz wszystko i włącz po kolei” jest dobry do izolacji, ale finalna diagnoza powinna wskazać mechanizm: duplikację skryptu, filtr, hook, cache, kolejność ładowania albo niezgodny format danych. Dzięki temu nie musisz rezygnować z potrzebnej funkcji tylko dlatego, że przypadkiem znalazłeś kombinację, w której błąd znika.
Dodatkowa kontrola po naprawie
Warto też pamiętać o zależnościach wersji. Konflikt może wystąpić nie dlatego, że dwie wtyczki są z zasady niekompatybilne, lecz dlatego, że jedna oczekuje nowszego WordPressa, PHP albo biblioteki JavaScript. Zapisz wersje środowiska przed testem i zmieniaj je świadomie. Dzięki temu po kilku tygodniach nie wrócisz do tego samego problemu bez wiedzy, która kombinacja była stabilna.
Bezpieczna kolejność działań
- Odtwórz błąd i zanotuj dokładny scenariusz.
- Zrób kopię i przygotuj staging.
- Sprawdź konsolę JS oraz log PHP.
- Izoluj podejrzane wtyczki na stagingu, najlepiej metodą dzielenia zestawu.
- Sprawdź changelogi i zgodność obu komponentów.
- Po naprawie wykonaj regresję formularzy, płatności, panelu i crona.
Czego nie robić
Nie wyłączaj hurtowo wtyczek na sklepie przy aktywnych klientach. Nie zostawiaj na stałe starej podatnej wersji tylko dlatego, że „na niej działa”. Konflikt trzeba rozwiązać, a nie zamrozić całą instalację w czasie.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
HeatLogic może odtworzyć konflikt na stagingu, znaleźć konkretny komponent i przygotować trwałe rozwiązanie: aktualizację, konfigurację, zamiennik albo poprawkę kodu.
Najczęściej zadawane pytania
Czy dwie dobre wtyczki mogą się gryźć?
Tak. Każda może działać poprawnie osobno, ale razem mogą kolidować w hookach, JS, CSS, bazie lub API.
Czy tryb awaryjny wtyczki diagnostycznej wystarczy?
Może pomóc, ale przy krytycznej stronie nadal potrzebujesz kopii, logów i testu pełnych funkcji.
Czy cofnięcie jednej wtyczki to dobre rozwiązanie?
Może być bezpiecznym rollbackiem awaryjnym, ale później trzeba znaleźć docelowe rozwiązanie i wrócić do wspieranych wersji.
Jak zapobiegać konfliktom?
Utrzymuj rozszerzenia, ogranicz ich liczbę do potrzebnych, testuj większe aktualizacje na stagingu i monitoruj logi.