Aktualizujemy wtyczkę, wracamy na stronę i zauważamy, że coś przestało działać. Przycisk nie reaguje, galeria wygląda inaczej albo znika element, który jeszcze przed chwilą był na swoim miejscu.Pierwsza myśl? Prawdopodobnie ostatnia aktualizacja. To dobry punkt wyjścia, ale jeszcze nie dowód na przyczynę problemu. W tym artykule pokażemy prosty sposób sprawdzania wtyczek na kopii strony. Przygotujemy też krótką próbę, dzięki której będzie można zobaczyć, jak wyłączenie jednego dodatku wpływa na wybrany element witryny. Bez edytowania kodu i bez wyłączania modułów na stronie odwiedzanej przez klientów.

Kiedy możemy podejrzewać konflikt wtyczek?

Sama obecność błędu nie oznacza jeszcze konfliktu. Problem może wynikać z ustawień jednego dodatku, motywu albo konfiguracji serwera.

O konflikcie mówimy wtedy, gdy elementy strony przeszkadzają sobie we wspólnym działaniu. Przykładowo formularz działa samodzielnie, ale przestaje reagować po włączeniu dodatkowego modułu.

Dlatego podczas sprawdzania strony tak ważna jest jedna zasada: zmieniamy jedną rzecz i ponownie wykonujemy tę samą czynność. Jeżeli wyłączymy pięć dodatków jednocześnie, a błąd zniknie, nadal nie będziemy wiedzieli, który z nich ma z nim związek.

Najpierw przygotowujemy kopię strony

Do szukania problemu potrzebujemy kopii obecnej witryny, czyli środowiska testowego nazywanego stagingiem. Czysta instalacja WordPressa może służyć do nauki, ale nie odtworzy wszystkich ustawień i zależności naszej strony.

Taki sposób diagnozowania zaleca również materiał szkoleniowy WordPressa o konfliktach wtyczek i motywów.

Jeżeli hosting oferuje tworzenie środowiska testowego, możemy skorzystać z tej funkcji. Inną możliwością jest WP STAGING.

Przed rozpoczęciem wykonujemy kopię zapasową. Następnie instalujemy WP STAGING, przechodzimy do listy środowisk testowych i wybieramy utworzenie nowej kopii. Nadajemy jej czytelną nazwę, lub zostawiamy domyślnie, i uruchamiamy klonowanie. Podstawową kopię w podfolderze można przygotować w darmowej wersji — opisuje to instrukcja WP STAGING.

Osobna kopia WordPressa przygotowana do sprawdzania wtyczek

Po otwarciu kopii sprawdzamy adres w przeglądarce. Dalsze zmiany wykonujemy właśnie tutaj.

W sklepie lub na stronie połączonej z zewnętrznymi usługami trzeba dodatkowo zadbać, aby kopia nie wysyłała prawdziwych wiadomości, nie uruchamiała płatności ani innych automatycznych działań. Kopia plików i bazy nie oznacza automatycznego odłączenia wszystkich integracji.

Prosta próba: wyłączamy jeden widoczny dodatek

Zanim zaczniemy szukać rzeczywistego konfliktu, możemy przećwiczyć sam sposób porównywania strony.

Wybieramy prostą wtyczkę odpowiadającą za widoczny dodatek, na przykład efekt animacji. O takich rozwiązaniach pisaliśmy już w artykule o animacjach i efektach przewijania w WordPressie.

Na kopii strony otwieramy podstronę z tym elementem. Następnie przechodzimy do:

Wtyczki → Zainstalowane wtyczki

Wyłączamy wyłącznie wybrany dodatek i odświeżamy podstronę. Sprawdzamy, co się zmieniło. Później ponownie włączamy wtyczkę i powtarzamy próbę.

Sprawdzamy jeden dodatek, zachowując pozostałe ustawienia

Ta próba pokazuje zależność elementu od wtyczki. Nie jest jeszcze testem potwierdzającym konflikt. Zniknięcie efektu po wyłączeniu modułu, który go dodaje, jest naturalnym zachowaniem.

Przy okazji ćwiczymy jednak dokładnie tę samą kolejność działań, którą wykorzystamy przy szukaniu usterki: zmiana, sprawdzenie i powrót do poprzedniego stanu.

Jak sprawdzić rzeczywisty problem?

Załóżmy, że na naszej stronie przycisk otwierający galerię przestał reagować. Na początku odtwarzamy ten problem na kopii i zapisujemy prosty scenariusz: otwieramy konkretną podstronę, klikamy wskazany przycisk i obserwujemy efekt.

Następnie wyłączamy jeden podejrzany dodatek, pozostawiając aktywną wtyczkę odpowiedzialną za samą galerię. Odświeżamy stronę i ponownie klikamy ten sam przycisk.

Jeżeli nic się nie zmieniło, przywracamy dodatek i przechodzimy do kolejnego. Jeśli galeria zaczęła działać, włączamy podejrzaną wtyczkę jeszcze raz. Powrót błędu będzie mocniejszą wskazówką niż pojedyncza udana próba.

Taki schemat wyłączania i ponownego uruchamiania dodatków opisano również w instrukcji diagnozowania błędów opublikowanej przez autora wtyczki na WordPress.org.

Przykład wpływu wtyczki na element strony

Gdy problem dotyczy sposobu ładowania strony, sprawdzamy również ustawienia optymalizacji JavaScriptu. Po każdej zmianie czyścimy pamięć podręczną kopii testowej, aby nie porównywać przypadkiem starego widoku z nowym.

Zapisujemy wynik, żeby nie zgubić tropu

Nie potrzebujemy rozbudowanego raportu. Wystarczy krótka notatka zawierająca:

  • sprawdzaną podstronę i czynność;
  • nazwę oraz wersję wyłączanej wtyczki;
  • zachowanie przed zmianą;
  • zachowanie po zmianie;
  • informację, czy błąd powrócił po ponownym włączeniu dodatku.

Taki zapis przyda się również wtedy, gdy zgłosimy problem autorowi wtyczki. Zamiast wiadomości „galeria nie działa” możemy wskazać, przy jakiej konfiguracji błąd występuje i jak go powtórzyć.

Co sprawdzić, gdy wyłączanie wtyczek nie pomaga?

Jeżeli po kolejnych próbach problem nadal występuje, wracamy do punktu wyjścia i sprawdzamy, czy nie skupiliśmy się zbyt szybko na jednej możliwej przyczynie. Brak poprawy po wyłączeniu pojedynczych dodatków nie wyklucza wszystkich zależności między nimi, ale warto przyjrzeć się także motywowi, ustawieniom strony oraz warunkom, w których pojawia się błąd.

Zaczynamy od porównania zachowania witryny w innej przeglądarce oraz w oknie prywatnym, bez logowania do WordPressa. Wykonujemy tę samą czynność na tej samej podstronie. Jeśli usterka pojawia się tylko w jednym z tych przypadków, zapisujemy tę różnicę. To przydatna wskazówka do dalszej diagnozy, choć sama w sobie nie rozstrzyga jeszcze, co odpowiada za problem.

Kolejnym krokiem może być sprawdzenie motywu. Na kopii testowej zapisujemy nazwę aktywnego motywu, a następnie tymczasowo uruchamiamy inny i ponawiamy próbę. Takie porównanie ma jednak sens tylko wtedy, gdy badana funkcja nadal jest dostępna. Jeżeli galeria lub przycisk były częścią poprzedniego motywu i po jego zmianie zniknęły, nie możemy uznać tego za potwierdzenie usunięcia błędu. Po sprawdzeniu przywracamy wcześniejszy motyw.

Jeżeli problem pozostaje, przyglądamy się jego zakresowi. Czy nie działa jeden element, czy cała podstrona? Czy pojawia się komunikat błędu, czy kliknięcie po prostu nie daje efektu? Zapisujemy dokładną treść komunikatu oraz godzinę wystąpienia usterki. Takie informacje mogą pomóc obsłudze hostingu odnaleźć odpowiednie wpisy w dziennikach błędów i sprawdzić, czy problem ma związek ze środowiskiem serwera.

Na tym etapie lepiej zebrać wyniki wykonanych prób niż wprowadzać kolejne przypadkowe zmiany. Przekazując problem administratorowi, autorowi motywu lub obsłudze hostingu, dołączamy opis sposobu odtworzenia błędu i listę sprawdzonych konfiguracji. Dzięki temu kolejna osoba może kontynuować diagnozę od miejsca, w którym skończyliśmy.

Co zrobić po znalezieniu podejrzanej wtyczki?

Wyłączenie dodatku może pomóc znaleźć przyczynę, ale nie zawsze jest docelowym rozwiązaniem. Być może wystarczy zmiana jednego ustawienia, aktualizacja albo wyłączenie optymalizacji dla konkretnego skryptu.

Najpierw sprawdzamy poprawkę na kopii. Dopiero gdy działa, wprowadzamy potrzebną zmianę na właściwej stronie i ponownie kontrolujemy problematyczny element.

Nie ma potrzeby przenoszenia całej testowej bazy danych tylko dlatego, że zmieniliśmy jedną opcję. W działającym sklepie mogły w tym czasie pojawić się nowe zamówienia.

Najbardziej przydatny będzie tutaj powtarzalny sposób pracy: jedna zmiana, ta sama czynność i zapisany rezultat. Dzięki temu kolejne kliknięcia w panelu prowadzą do konkretnego wniosku, a klienci mogą w tym czasie korzystać ze strony.

Jeżeli macie inne pytania odnośnie tworzenia stron internetowych, administracji stron internetowych lub pozycjonowaniem stron śmiało piszcie do nas.

Mateusz Adamski

Mateusz Adamski

Frontend Developer, Specjalista SEO. Od 2009 roku zajmuję się pozycjonowaniem oraz optymalizacją stron internetowych. Od 2012 roku specjalizuję się w tworzeniu stron i sklepów internetowych opartych na systemach CMS WordPress oraz Prestashop. Posiadam dobrą znajomość HTML5, CSS3, Bootstrap. Dysponuję również dużym doświadczeniem z programami Adobe Photoshop, Dreamweaver oraz CorelDRAW. Prywatnie jestem dużym fanem fotografii oraz motoryzacji. Od 2013 roku udzielam się jako klubowicz oraz moderator ogólnopolskiego klubu motoryzacyjnego. Masz jakieś pytania? Napisz do nas.