Strona zamówienia w WooCommerce ładuje się bez końca. Jak znaleźć konflikt?

Klient dodał produkty do koszyka, przeszedł na stronę zamówienia i zobaczył kręcące się kółko, które nie znika. Lista metod płatności jest wyszarzona, przycisk zamówienia nie reaguje albo po jego kliknięciu nic się nie dzieje. Sklep wygląda na czynny, a sprzedaż stoi, często przez wiele godzin, zanim ktokolwiek to zauważy.

Ten wpis jest instrukcją dla właścicieli sklepów na WooCommerce, którzy chcą samodzielnie ustalić, co blokuje stronę zamówienia. Opisuję kolejno, jak odróżnić zawieszenie od zwykłej powolności, jak odczytać wskazówki z raportu stanu sklepu i z przeglądarki, jak przeprowadzić test konfliktu wtyczek i motywu bez wyłączania sklepu klientom oraz jak naprawić każdą z typowych przyczyn.

Po lekturze czytelnik będzie umiał wskazać konkretny element, który psuje zamówienia, usunąć usterkę albo przekazać autorowi wtyczki lub firmie hostingowej zgłoszenie, na które da się odpowiedzieć bez dopytywania.

Po czym poznać, że strona zamówienia się zawiesiła, a nie tylko działa wolno?

Strona zamówienia w WooCommerce nie wczytuje się w całości za jednym razem. Po jej otwarciu oraz po każdej zmianie adresu, kraju czy sposobu dostawy przeglądarka wysyła do serwera krótkie zapytanie w tle i prosi o aktualne podsumowanie: metody płatności i kwoty. Na czas oczekiwania sklep nakłada na tę część strony półprzezroczystą warstwę z kółkiem.

W sprawnym sklepie warstwa znika po chwili. Zawieszenie rozpoznaje się po tym, że kółko kręci się bez końca, a część z podsumowaniem zamówienia i płatnościami w ogóle się nie pojawia albo pozostaje nieaktywna. Dokumentacja WooCommerce opisuje ten objaw wprost: jeśli zapytanie w tle się nie powiedzie, sekcja z podsumowaniem może się nie wczytać, a kółko może kręcić się w nieskończoność.

Zwykła powolność wygląda inaczej. Kółko po kilku lub kilkunastu sekundach ustępuje i zamówienie da się złożyć. To również problem, ale innego rodzaju, a sposób jego badania opisałem we wpisie o tym, co spowalnia WordPressa.

Przed dalszą pracą trzeba ustalić zasięg usterki. Stronę zamówienia otwiera się w oknie prywatnym przeglądarki, na innym urządzeniu i najlepiej w innej sieci, na przykład w telefonie z wyłączonym Wi-Fi. Jeśli zawieszenie występuje tylko w jednej przeglądarce, przyczyną bywa jej rozszerzenie blokujące skrypty albo stare pliki zapamiętane lokalnie. Jeśli występuje wszędzie, źródło leży w sklepie.

Skąd bierze się niekończące się ładowanie?

Kółko nie jest usterką, tylko jej objawem. Oznacza, że przeglądarka nie dostała od serwera odpowiedzi, której się spodziewała, albo że skrypt obsługujący zamówienie przestał działać, zanim zdążył zdjąć warstwę ładowania. Oficjalna dokumentacja WooCommerce wymienia pięć najczęstszych powodów.

• Różne adresy w polach „Adres WordPressa (URL)” i „Adres witryny (URL)”, przez co zapytania w tle trafiają pod inny adres niż ten, z którego przyszedł klient.
• Błędy JavaScript lub konflikt skryptów pochodzących z motywu albo z wtyczek.
• Nieprawidłowa odpowiedź serwera na zapytanie w tle: zamiast danych w formacie JSON wraca kod strony HTML albo sama wartość -1.
• Wysyłka wiadomości e-mail o zamówieniu, która na wolniejszym serwerze przeciąga obsługę zamówienia ponad dopuszczalny czas.
• Zbyt niski limit pamięci przydzielonej WordPressowi.

W praktyce do tej listy dochodzą jeszcze trzy źródła kłopotów: pamięć podręczna, która zapisała stronę zamówienia jak zwykłą podstronę, nieaktualne pliki szablonów WooCommerce skopiowane do motywu oraz zabezpieczenia serwera lub wtyczki ochronnej, które odrzucają zapytania sklepu. Każdą z tych przyczyn da się potwierdzić lub wykluczyć w kilka minut, pod warunkiem zachowania kolejności.

Kolejność ma znaczenie, ponieważ najtańsze sprawdzenia nie wymagają żadnych zmian w sklepie. Najpierw odczytuje się to, co sklep i przeglądarka same zgłaszają, a dopiero potem wyłącza się wtyczki. Odwrócenie tej kolejności kończy się zwykle wyłączaniem wszystkiego po kolei na działającym sklepie, co samo potrafi wyrządzić szkody.

Co przygotować, zanim zacznie się cokolwiek zmieniać?

Dokumentacja WooCommerce zaleca wykonanie kopii zapasowej przed testem konfliktu. Wyłączanie i ponowne włączanie wtyczek zazwyczaj niczego nie psuje, ale w rzadkich przypadkach wtyczka po ponownym włączeniu traci część ustawień. Kopia obejmuje pliki i bazę danych, a sposób jej wykonania i sprawdzenia opisałem we wpisie o tym, jak zrobić kopię zapasową WordPressa, która naprawdę działa.

Drugą rzeczą jest miejsce do testów. Najbezpieczniej pracować na kopii roboczej sklepu, czyli na jego klonie pod osobnym adresem, w którym nikt nie składa zamówień. Wiele firm hostingowych udostępnia taką funkcję w panelu, a dokumentacja WooCommerce wskazuje też wtyczkę WP Staging. Na kopii roboczej można wyłączać wszystko bez obaw o klientów.

Jeżeli kopii roboczej nie ma i nie da się jej szybko utworzyć, pozostaje tryb rozwiązywania problemów z wtyczki Health Check & Troubleshooting, opisany w dalszej części. Wyłącza on wtyczki i motyw wyłącznie dla zalogowanego administratora, a klienci widzą sklep bez zmian.

Na koniec przygotowań należy zapisać dokładny przebieg, który wywołuje usterkę: jaki produkt, jaki kraj i sposób dostawy, czy klient był zalogowany, w którym momencie pojawia się kółko. Każdy kolejny test trzeba powtarzać w ten sam sposób, bo inaczej wyniki nie będą porównywalne.

Co mówi raport „Status systemu” i jak go odczytać?

Dokumentacja WooCommerce radzi zacząć od ekranu stanu sklepu i w pierwszej kolejności usunąć błędy, które sklep sam tam wyróżnił. To najszybsze sprawdzenie, bo jeden ekran pokazuje naraz adresy, limit pamięci, wersje oprogramowania i stan szablonów.

1. W panelu WordPressa należy przejść do „WooCommerce”, a następnie do pozycji „Status”. Otwiera się zakładka „Status systemu”.
2. Trzeba przejrzeć cały raport i zanotować każdy wiersz wyróżniony na czerwono. Tak oznaczane są pozycje wymagające uwagi.
3. W części dotyczącej środowiska WordPressa odczytuje się adresy sklepu oraz wiersz z limitem pamięci WP. Dokumentacja wskazuje, że limit powinien wynosić co najmniej 64 MB.
4. W części poświęconej szablonom sprawdza się, czy przy plikach nadpisanych przez motyw nie ma informacji o nieaktualnej wersji.
5. W zakładce „Logi” tego samego ekranu należy odszukać pliki o nazwie zaczynającej się od fatal-errors i otworzyć najnowszy. Dokumentacja zaleca sięgnąć po ten dziennik w pierwszej kolejności.

Wpis w dzienniku błędów krytycznych jest zwykle najkrótszą drogą do winowajcy. Komunikat zawiera ścieżkę do pliku, w którym wystąpił błąd, a w ścieżce widać nazwę katalogu wtyczki lub motywu. Jeśli godzina wpisu zgadza się z godziną próby złożenia zamówienia, podejrzany jest znany jeszcze przed testem konfliktu.

Jak sprawdzić, czy oba adresy sklepu są takie same?

Zapytania w tle nie dochodzą do skutku, gdy adres WordPressa i adres witryny się różnią. Najczęściej chodzi o drobiazg: jeden adres zaczyna się od https://, drugi od http://, albo jeden zawiera www, a drugi nie. Przeglądarka traktuje takie adresy jak dwie różne witryny i ze względów bezpieczeństwa blokuje wymianę danych między nimi.

Sprawdzenie wykonuje się w menu „Ustawienia”, w pozycji „Ogólne”. Pola „Adres WordPressa (URL)” i „Adres witryny (URL)” powinny zawierać tę samą wartość, zgodną z adresem, pod którym sklep faktycznie się otwiera. Po poprawce trzeba zapisać zmiany i ponownie się zalogować.

Ta zmiana wymaga ostrożności. Błędny adres w tych polach odcina dostęp do panelu, dlatego przed zapisaniem należy dwa razy przeczytać wpisaną wartość i mieć pod ręką dane dostępowe do hostingu. Jeśli pola są wyszarzone, adresy zostały ustawione na stałe w pliku wp-config.php i tam trzeba je poprawić.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: ustalę, która wtyczka, ustawienie lub usługa serwera blokuje stronę zamówienia, i doprowadzę sklep do stanu, w którym zamówienia znów przechodzą.

Jak odczytać błąd w konsoli przeglądarki?

Jeśli raport stanu niczego nie wyjaśnił, następnym źródłem wiedzy jest sama przeglądarka. Każda z popularnych przeglądarek ma wbudowane narzędzia dla programistów, które pokazują błędy skryptów na otwartej stronie. Ich użycie niczego w sklepie nie zmienia, więc można to robić na działającym sklepie.

1. Do koszyka trzeba włożyć dowolny produkt i przejść na stronę zamówienia.
2. Narzędzia otwiera klawisz F12 albo skrót Ctrl+Shift+I, a na komputerach Apple skrót Cmd+Option+I.
3. Należy przejść do zakładki „Console”. Narzędzia te w większości przeglądarek mają angielskie nazwy zakładek.
4. Stronę zamówienia odświeża się przy otwartych narzędziach i czeka, aż pojawi się kółko.
5. Komunikaty oznaczone na czerwono są błędami. Przy każdym z nich po prawej stronie widnieje nazwa pliku i numer wiersza, a po najechaniu kursorem pełny adres pliku.

Najwięcej mówi adres pliku. Fragment /wp-content/plugins/nazwa-wtyczki/ wskazuje wtyczkę, fragment /wp-content/themes/nazwa-motywu/ wskazuje motyw. Jeżeli adres prowadzi do katalogu pamięci podręcznej albo do pliku o losowej nazwie złożonej z liter i cyfr, błąd powstał w połączonym i pomniejszonym pliku utworzonym przez wtyczkę optymalizującą, a właściwy winowajca ukrywa się w środku.

Treść komunikatu warto skopiować w całości, razem z adresem pliku. Przyda się w zgłoszeniu do autora wtyczki. Nie trzeba jej rozumieć: wystarczy wiedzieć, że czerwony wpis pojawiający się w chwili zawieszenia oznacza skrypt, który przerwał pracę i pociągnął za sobą obsługę zamówienia.

Brak czerwonych wpisów też jest informacją. Oznacza, że skrypty działają, a kłopot leży po stronie odpowiedzi serwera. Wtedy trzeba zajrzeć do sąsiedniej zakładki.

Jak sprawdzić, co serwer odpowiada na zapytanie sklepu?

Zakładka „Network” w tych samych narzędziach pokazuje wszystkie zapytania wysyłane przez stronę. Dokumentacja WooCommerce zaleca ograniczenie widoku do zapytań w tle i obejrzenie odpowiedzi związanych z zamówieniem.

1. Przy otwartej stronie zamówienia należy przejść do zakładki „Network” i wybrać filtr „XHR”, w nowszych wersjach przeglądarek opisany jako „Fetch/XHR”.
2. Stronę trzeba odświeżyć, a potem zmienić dowolne pole adresu, żeby wywołać ponowne przeliczenie zamówienia.
3. Na liście pojawiają się zapytania. W klasycznej wersji strony zamówienia ich adres zawiera fragment wc-ajax, a w wersji zbudowanej z bloków fragment wc/store.
4. Po kliknięciu zapytania odczytuje się kod odpowiedzi w kolumnie „Status” oraz treść w zakładce „Response”.

Poprawna odpowiedź ma kod 200 i treść w formacie JSON, czyli tekst zaczynający się od nawiasu klamrowego. Wszystko inne jest tropem, a każdy z nich prowadzi w inne miejsce.

Odpowiedź zawiera kod HTML zamiast danych

Według dokumentacji są dwie typowe przyczyny. Pierwsza to plik index.html w głównym katalogu WordPressa, który serwer podaje zamiast pliku index.php. Taki plik bywa pozostałością po stronie tymczasowej z okresu budowy sklepu. Należy go usunąć albo poprosić firmę hostingową o ustawienie pierwszeństwa dla index.php.

Druga przyczyna to wtyczka pamięci podręcznej, która dokleja własny kod HTML przed danymi. Wtedy czyści się pamięć podręczną, a jeśli to nie pomaga, na czas próby wyłącza się tę wtyczkę. Podobny skutek daje ostrzeżenie PHP wypisane na początku odpowiedzi: jego treść zawiera ścieżkę do pliku wtyczki, która je wywołała.

Odpowiedź to sama wartość -1

Dokumentacja wyjaśnia, że taka odpowiedź oznacza nieudaną weryfikację jednorazowego znacznika bezpieczeństwa, spowodowaną treścią zapisaną w pamięci podręcznej. Klient dostał stronę zapamiętaną wcześniej dla kogoś innego, razem z nieważnym już znacznikiem. Rozwiązaniem jest wyczyszczenie pamięci podręcznej sklepu oraz wszystkich warstw po stronie serwera, a potem wykluczenie strony zamówienia z zapisywania, co opisuję niżej.

Kod 403, 500 albo brak odpowiedzi

Kod 403 oznacza odmowę. Zapytanie zostało zatrzymane przez wtyczkę ochronną, zaporę serwera albo usługę pośredniczącą w ruchu. Kod 500 oznacza błąd po stronie serwera i wtedy szczegóły znajdują się w dzienniku błędów krytycznych opisanym wcześniej. Zapytanie, które przez długi czas pozostaje w stanie oczekiwania i kończy się kodem 504 albo wcale, wskazuje na przekroczenie czasu, najczęściej przez zbyt wolną wysyłkę wiadomości lub brak pamięci.

Jak przeprowadzić test konfliktu wtyczek i motywu?

Konflikt powstaje wtedy, gdy dwa fragmenty kodu wysyłają sprzeczne polecenia. Dokumentacja WooCommerce stwierdza jednoznacznie, że testowanie jest jedynym sposobem ustalenia, co go powoduje. Wskazówki z konsoli i dzienników skracają test, ale go nie zastępują.

Opisany niżej przebieg jest zgodny z oficjalną procedurą. Najlepiej wykonać go na kopii roboczej sklepu.

1. Aktualizacja wszystkich wtyczek i motywów do najnowszych wersji. Część konfliktów ustępuje na tym etapie, bo autorzy zdążyli już wydać poprawkę.
2. W menu „Wygląd”, w pozycji „Motywy”, należy włączyć domyślny motyw WordPressa, na przykład Twenty Twenty-Five, albo motyw Storefront przygotowany przez twórców WooCommerce.
3. Trzeba powtórzyć zapisany wcześniej przebieg zamówienia. Jeśli usterka zniknęła, powoduje ją dotychczasowy motyw. Jeśli trwa, test idzie dalej.
4. W menu „Wtyczki” wyłącza się wszystkie wtyczki oprócz WooCommerce. Najszybciej zaznaczyć je na liście, z rozwijanej listy działań zbiorczych wskazać „Wyłącz” i kliknąć „Zastosuj”.
5. Ponowna próba zamówienia. Jeśli strona działa, winna jest jedna z wyłączonych wtyczek. Jeśli nadal się zawiesza, przyczyna leży poza zwykłymi wtyczkami i motywem.
6. Wtyczki włącza się z powrotem pojedynczo i po każdej powtarza się ten sam przebieg zamówienia. Ta, po której włączeniu kółko wraca, jest źródłem konfliktu.
7. Na koniec przywraca się właściwy motyw i sprawdza, czy sklep wygląda i działa jak przed testem.

Przy dużej liczbie wtyczek włączanie po jednej trwa długo. Dopuszczalne jest przyspieszenie: włącza się połowę wtyczek naraz i sprawdza, w której połowie znajduje się winowajca, a potem tę połowę dzieli się dalej. Jedna uwaga: wtyczka płatności i wtyczka dostawy są potrzebne, żeby w ogóle dojść do końca zamówienia, więc w sklepie testowym warto na czas próby zostawić najprostszą metodę, na przykład przelew tradycyjny wbudowany w WooCommerce.

Zdarza się, że usterka pojawia się dopiero przy dwóch konkretnych wtyczkach włączonych jednocześnie. Wtedy po znalezieniu pierwszej trzeba ją zostawić włączoną, wyłączyć resztę i powtórzyć włączanie pojedynczo, aż wróci kółko. Para jest wynikiem testu.

Jak zrobić test na działającym sklepie, nie wyłączając go klientom?

Służy do tego wtyczka Health Check & Troubleshooting, przygotowana przez społeczność WordPressa. Jej tryb rozwiązywania problemów daje czystą sesję: wszystkie wtyczki są wyłączone i używany jest motyw domyślny, ale wyłącznie dla zalogowanego użytkownika, który ten tryb uruchomił. Pozostali odwiedzający widzą sklep w zwykłej postaci.

Po instalacji tryb uruchamia się z ekranu stanu witryny w menu „Narzędzia”, w zakładce poświęconej rozwiązywaniu problemów. W górnym pasku administratora pojawia się wtedy menu, z którego włącza się pojedyncze wtyczki i przełącza motyw tylko dla własnej sesji. Tryb trwa do chwili jego wyłączenia lub wylogowania.

W tym trybie należy najpierw włączyć samo WooCommerce i wtyczkę płatności, sprawdzić zamówienie, a potem dokładać kolejne wtyczki. Trzeba pamiętać o ograniczeniu: próbne zamówienia składane w ten sposób trafiają do prawdziwej bazy sklepu, więc po teście należy je anulować i uzupełnić stan magazynu.

Co z wtyczkami, których nie da się wyłączyć?

Część kodu nie pojawia się na zwykłej liście wtyczek. Dokumentacja opisuje dwie takie grupy, widoczne w osobnych zakładkach nad listą: wtyczki obowiązkowe, w oryginale „Must-Use”, oraz pliki rozszerzające, w oryginale „Drop-ins”. Nie mają odnośnika do wyłączenia.

Niektóre z nich instaluje wtyczka nadrzędna i znikają po jej wyłączeniu. Inne dodaje firma hostingowa, na przykład jako warstwę pamięci podręcznej. Jeśli test z samym WooCommerce i motywem domyślnym nadal kończy się kółkiem, trzeba poprosić hosting o czasowe wyłączenie tych dodatków. Samodzielne usuwanie plików z tych katalogów odradzam, bo bywa, że od nich zależy działanie całego serwera.

Dlaczego podczas testu trzeba wyłączyć pamięć przeglądarki?

Przeglądarka przechowuje skrypty z poprzednich wizyt. Po wyłączeniu wtyczki może nadal używać starego pliku i test da fałszywy wynik. Dokumentacja zaleca, by w narzędziach dla programistów, w zakładce „Network”, zaznaczyć pole „Disable cache” i trzymać narzędzia otwarte przez cały test. Po zakończeniu pole należy odznaczyć.

Jak ustawić pamięć podręczną, żeby nie psuła zamówień?

Pamięć podręczna przyspiesza sklep, zapisując gotowe strony. Strona zamówienia nie może być zapisywana, bo za każdym razem pokazuje dane konkretnego klienta i jego koszyka. Zalecenia WooCommerce dla wtyczek pamięci podręcznej wymieniają trzy strony, które muszą pozostać dynamiczne: „Koszyk”, „Zamówienie” i „Moje konto”.

Wiele wtyczek wyklucza te strony samodzielnie, ale tylko wtedy, gdy są one poprawnie przypisane w ustawieniach WooCommerce. Sklep, w którym strona zamówienia ma zmieniony adres albo została zbudowana od nowa w kreatorze stron, często wypada z tego automatu. Dlatego wykluczenie warto sprawdzić ręcznie w ustawieniach wtyczki, w polu z listą adresów pomijanych przy zapisywaniu. O tym, gdzie przypisuje się strony sklepu, piszę we wpisie o pierwszych ustawieniach WooCommerce.

Zalecenia wymieniają także pliki cookie, przy których obecności strona nie powinna być podawana z pamięci: woocommerce_cart_hash, woocommerce_items_in_cart oraz wp_woocommerce_session_. Jeśli używana jest pamięć podręczna bazy danych, z zapisywania wyłącza się dane o nazwie zaczynającej się od _wc_session_.

Osobną sprawą jest łączenie i pomniejszanie skryptów. Dla jednej z popularnych wtyczek dokumentacja WooCommerce wprost zaleca unikanie pomniejszania plików JavaScript. Moja rada jest szersza: gdy konsola pokazuje błąd w pliku z katalogu pamięci podręcznej, należy na próbę wyłączyć łączenie, pomniejszanie i opóźnianie skryptów, wyczyścić pamięć i powtórzyć zamówienie. Jeśli kółko znika, funkcje włącza się z powrotem pojedynczo, a skrypty WooCommerce dopisuje do listy wyjątków.

Pamięć podręczna działa często na kilku poziomach jednocześnie: we wtyczce, na serwerze i w usłudze pośredniczącej w ruchu. Wyczyszczenie jednej warstwy nie wystarcza. Jeżeli wykluczenia we wtyczce są poprawne, a klienci nadal dostają zapamiętaną stronę zamówienia, trzeba poprosić hosting o wykluczenie tych samych adresów po stronie serwera.

Co zrobić, gdy zawiodły e-maile, pamięć serwera albo szablony?

Zamówienie zawiesza się po kliknięciu przycisku, a mimo to trafia do panelu

To charakterystyczny objaw wolnej wysyłki wiadomości. Sklep zapisuje zamówienie, zaczyna wysyłać potwierdzenia do klienta i do obsługi, a serwer pocztowy odpowiada tak wolno, że przeglądarka nie doczekuje się wyniku. Klient widzi kółko, klika ponownie i powstają zdublowane zamówienia.

Dokumentacja WooCommerce podaje na to rozwiązanie na poziomie kodu: odroczenie wiadomości, tak aby były wysyłane po zakończeniu obsługi zamówienia. Służy do tego jeden wiersz:

add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Wiersz umieszcza się w pliku functions.php motywu potomnego albo we wtyczce do fragmentów kodu, na przykład Code Snippets. Nie należy wpisywać go do pliku motywu głównego, bo aktualizacja motywu go usunie. Błąd składni w tym pliku wyłącza całą witrynę, więc przed zmianą trzeba mieć kopię i dostęp do plików przez panel hostingu. Trwałym rozwiązaniem jest zwykle zmiana sposobu wysyłki na sprawny serwer SMTP.

Limit pamięci jest za niski

Jeśli raport stanu pokazuje limit pamięci poniżej 64 MB, zapytania sklepu mogą kończyć się niepowodzeniem. Limit podnosi się w pliku wp-config.php, dopisując nad wierszem kończącym edycję ustawień następującą wartość:

define( 'WP_MEMORY_LIMIT', '256M' );

WordPress nie przekroczy jednak limitu, jaki dla PHP ustawiła firma hostingowa. Gdy po zmianie raport nadal pokazuje starą wartość, trzeba zwiększyć limit w panelu hostingu albo poprosić o to obsługę.

Motyw używa nieaktualnych szablonów WooCommerce

Motywy często kopiują do siebie pliki szablonów sklepu, żeby zmienić ich wygląd. Po dużej aktualizacji WooCommerce stara kopia szablonu zamówienia może nie zawierać elementów, których oczekują nowe skrypty. Raport stanu wyróżnia takie pliki w części o szablonach. Naprawa polega na aktualizacji motywu, a gdy autor jej nie wydał, na zgłoszeniu mu sprawy z listą plików z raportu. Ręczne podmienianie szablonów to praca dla programisty.

Zapytania blokuje zabezpieczenie

Kod 403 w zakładce sieci oznacza, że zapytanie odrzuciła ochrona. Sprawdza się to, wyłączając na próbę wtyczkę ochronną w ramach testu konfliktu. Jeśli to nie ona, o przejrzenie dziennika zapory trzeba poprosić hosting, podając dokładną godzinę próby i adres zapytania. Nie należy wyłączać ochrony na stałe: właściwym rozwiązaniem jest wyjątek dla adresów używanych przez stronę zamówienia.

Jak potwierdzić naprawę i jakich błędów unikać?

Zniknięcie kółka w panelu administratora niczego jeszcze nie dowodzi. Zalogowany administrator zwykle omija pamięć podręczną, więc widzi inną wersję sklepu niż klient. Naprawę potwierdza się w oknie prywatnym, bez logowania, składając pełne zamówienie próbne od koszyka do strony z podziękowaniem.

Pełne potwierdzenie obejmuje cztery rzeczy: warstwa ładowania znika po zmianie adresu i sposobu dostawy, zamówienie pojawia się w panelu z właściwym statusem, potwierdzenie dochodzi na skrzynkę, a konsola przeglądarki nie pokazuje czerwonych wpisów. Próbę warto powtórzyć na telefonie oraz dla każdej metody płatności, bo wtyczki bramek ładują własne skrypty. Jeśli kłopot dotyczy tylko jednej bramki, pomocny będzie wpis o tym, jak podłączyć płatności BLIK i szybkie przelewy w WooCommerce.

Co zrobić, gdy test niczego nie wykazał?

Jeżeli strona zawiesza się nawet z samym WooCommerce i motywem domyślnym, przyczyna leży poza wtyczkami: w konfiguracji serwera, w dodatkach hostingu albo w danych sklepu. Wtedy należy przekazać sprawę firmie hostingowej lub pomocy technicznej. Dokumentacja prosi, by w zgłoszeniu opisać, jak odtworzyć usterkę, i wymienić wykonane już testy. Dobre zgłoszenie może brzmieć tak:

„Strona zamówienia w sklepie pod adresem [adres] wyświetla niekończące się kółko ładowania. Usterka występuje w każdej przeglądarce, także w oknie prywatnym. Kroki: produkt [nazwa] do koszyka, przejście do zamówienia, wybór kraju Polska. Zapytanie [adres zapytania] zwraca kod [kod] i treść [treść]. Test z motywem domyślnym i samym WooCommerce dał ten sam wynik. W załączeniu raport stanu systemu i wpis z dziennika błędów z godziny [godzina].”

Najczęstsze pomyłki podczas szukania konfliktu

• Wyłączanie wszystkich wtyczek na działającym sklepie w godzinach sprzedaży, bez kopii i bez kopii roboczej.
• Testowanie za każdym razem innym przebiegiem zamówienia, przez co wyniki nie dają się porównać.
• Pomijanie czyszczenia pamięci podręcznej po każdej zmianie, co daje fałszywe wyniki w obie strony.
• Uznanie sprawy za zamkniętą po znalezieniu winnej wtyczki i pozostawienie jej wyłączonej, mimo że sklep jej potrzebuje.
• Usunięcie wtyczki zamiast jej wyłączenia, co w wielu przypadkach powoduje utratę ustawień i danych.
• Wklejanie do plików motywu fragmentów kodu z przypadkowych źródeł bez kopii i bez dostępu do plików.

Po znalezieniu winowajcy właściwym krokiem jest kontakt z autorem wtyczki lub motywu. Zgłoszenie z treścią błędu z konsoli, wersjami oprogramowania z raportu stanu i opisem przebiegu zazwyczaj wystarcza do przygotowania poprawki. Do tego czasu można poszukać w ustawieniach wtyczki opcji, która wyłącza jej działanie na stronie zamówienia, albo czasowo zastąpić ją inną.

Najczęstsze pytania

Czy wyłączenie wtyczek usunie ich ustawienia?

Samo wyłączenie zazwyczaj niczego nie usuwa, a dane pozostają w bazie do ponownego włączenia. Inaczej jest przy usunięciu wtyczki, które może spowodować utratę ustawień. Dokumentacja WooCommerce mimo to zaleca wykonanie kopii zapasowej przed testem, bo w rzadkich przypadkach kłopoty się zdarzają.

Strona zamówienia działa u administratora, a u klientów nie. Dlaczego?

Najczęściej odpowiada za to pamięć podręczna. Zalogowany administrator dostaje stronę tworzoną na bieżąco, a niezalogowany klient jej zapamiętaną kopię z nieważnym znacznikiem bezpieczeństwa. Trzeba wykluczyć stronę zamówienia z zapisywania i wyczyścić wszystkie warstwy pamięci, a sprawdzenie wykonać w oknie prywatnym.

Kółko pojawia się tylko na telefonach. Co to oznacza?

Zwykle oznacza skrypt lub ustawienie działające wyłącznie w widoku mobilnym: osobną pamięć podręczną dla telefonów, opóźnianie skryptów do pierwszego dotknięcia ekranu albo element motywu ładowany tylko na małych ekranach. Test konfliktu przeprowadza się tak samo, lecz każdą próbę wykonuje się na telefonie.

Usterka pojawiła się zaraz po aktualizacji. Czy cofnąć wersję?

Cofnięcie wersji bywa szybkim sposobem przywrócenia sprzedaży, a dokumentacja wymienia do tego wtyczkę WP Rollback. Jest to jednak rozwiązanie tymczasowe, ponieważ stare wersje nie dostają poprawek bezpieczeństwa. Bezpieczniej przywrócić sklep z kopii sprzed aktualizacji, a nową wersję sprawdzić najpierw na kopii roboczej.

Czy przyczyną może być bramka płatności?

Tak. Wtyczki płatności dodają na stronie zamówienia własne skrypty i łączą się z serwerami operatora. Błąd w takim skrypcie albo nieprawidłowe dane dostępowe potrafią zatrzymać całą sekcję płatności. W teście konfliktu rozpoznaje się to po tym, że z samym przelewem tradycyjnym zamówienie przechodzi, a po włączeniu bramki kółko wraca.

Ile trwa znalezienie konfliktu?

To zależy od liczby wtyczek i od tego, czy dziennik błędów lub konsola wskazują podejrzanego. Przy wyraźnym komunikacie sprawa zamyka się szybko. Bez wskazówek trzeba przejść cały test, a przy kilkudziesięciu wtyczkach wymaga to cierpliwości i metody dzielenia na połowy.

Czy da się to sprawdzić bez dostępu do serwera?

Większość opisanych czynności wykonuje się w panelu WordPressa i w przeglądarce: raport stanu, dziennik błędów, konsola, test konfliktu, ustawienia pamięci podręcznej. Dostęp do plików jest potrzebny dopiero przy zmianie limitu pamięci, usunięciu zbędnego pliku z katalogu głównego albo przy naprawie po nieudanej edycji kodu.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Zawieszona strona zamówienia to sytuacja, w której każda godzina oznacza utracone zakupy, a szukanie przyczyny po omacku tylko ten czas wydłuża. Mogę przejąć sprawę w całości: wykonam kopię, przygotuję bezpieczne miejsce do testów, odczytam dzienniki i odpowiedzi serwera, przeprowadzę test konfliktu, usunę przyczynę albo uzgodnię poprawkę z autorem wtyczki lub firmą hostingową, a na koniec sprawdzę pełnym zamówieniem próbnym, że sklep znów sprzedaje.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i krótko opisać, co widać na stronie zamówienia. Odpowiem, od czego zacznę i czego będę potrzebować.