Awaria kasy to nie to samo co słaba konwersja - przy awarii nikt nie kupi, choćby bardzo chciał, i naprawia się to zupełnie inaczej. To rozróżnienie warto zrobić na wejściu, bo mieszanie tych dwóch spraw jest powodem, dla którego ludzie tygodniami skracają formularz w sklepie, w którym przycisk zamówienia po prostu nie działa na telefonie. Gdy kasa stoi i liczy się każda godzina, naprawa WooCommerce zaczyna się od testu zamówienia do ostatniego kroku.
Jeśli Twój objaw brzmi „mam ruch, ale mało zamówień”, to nie ten tekst - tam problem jest w ścieżce i w zaufaniu, a rozkładam to przy porzuconych koszykach z powodów technicznych. Jeśli objaw brzmi „nie da się złożyć zamówienia” - jesteś we właściwym miejscu.
Poniżej sześć objawów, które widzę najczęściej, każdy z przyczynami w kolejności prawdopodobieństwa i konkretnym miejscem do sprawdzenia.
Krok zerowy: odtwórz awarię i zapisz warunki
Zanim cokolwiek zmienisz, ustal dokładnie, w jakich warunkach kasa nie działa. Cztery pytania:
- Na czym - telefon czy komputer, która przeglądarka? Awarie JavaScriptu bywają widoczne tylko w jednej.
- Z czym w koszyku - dowolny produkt czy konkretny? Produkty wirtualne, z wariantami, z dodatkami i rezerwacyjne przechodzą przez inny kod.
- Z jakim adresem - awaria „brak metod wysyłki” prawie zawsze zależy od kraju i kodu pocztowego.
- Zalogowany czy jako gość? To najszybszy test na problemy z sesją i z cache.
Zapisz odpowiedzi. Połowa diagnozy to ustalenie, czy awaria dotyczy wszystkich, czy jednego przypadku - i to zmienia miejsce, w którym trzeba szukać.
Testuj zawsze w oknie prywatnym przeglądarki. Twoje własne okno ma sesję, ciasteczka i uprawnienia administratora, przez które połowa problemów z cache jest niewidoczna.
Objaw 1: strona kasy jest pusta albo biała
Adres /zamowienie/ otwiera się, ale nie ma na nim nic - albo jest sama stopka.
Przyczyny w kolejności:
- Błąd PHP przerywający renderowanie. Najczęściej po aktualizacji wtyczki albo motywu. Sprawdzisz to od razu, włączając tryb debugowania (opis niżej) - w logu będzie nazwa pliku i numer linii.
- Strona kasy straciła treść. WooCommerce potrzebuje na tej stronie shortcode’u
[woocommerce_checkout]albo bloku kasy. Jeśli ktoś edytował stronę w builderze i zapisał ją bez tego elementu, kasa przestaje istnieć. Sprawdź: WooCommerce → Ustawienia → Zaawansowane - która strona jest ustawiona jako strona zamówienia, a potem otwórz ją w edytorze. - Motyw nadpisuje szablon kasy przestarzałą wersją. Sprawdzisz w WooCommerce → Status: sekcja z szablonami pokazuje ostrzeżenie, jeśli motyw zawiera nieaktualne pliki WooCommerce.
Jeśli biały ekran dotyczy całego sklepu, a nie samej kasy, to inna awaria - opisałem ją w tekście o białym ekranie w WordPressie i o błędzie krytycznym.
Objaw 2: kasa przekierowuje do koszyka albo pokazuje „Twój koszyk jest pusty”
Klient dodaje produkt, klika „przejdź do kasy” i ląduje z powrotem w pustym koszyku. To jeden z najczęstszych zgłoszeń i prawie zawsze chodzi o sesję.
WooCommerce trzyma zawartość koszyka w sesji użytkownika, powiązanej ciasteczkiem. Jeśli ciasteczko nie dojdzie albo sesja się nie odnajdzie, koszyk jest pusty z punktu widzenia serwera - nawet jeśli chwilę wcześniej pokazywał trzy produkty.
Przyczyny w kolejności:
- Cache stron obejmuje koszyk i kasę. To przyczyna numer jeden. Strony
/koszyk/,/zamowienie/i/moje-konto/muszą być wyłączone z cache w każdej warstwie: wtyczka cache, cache serwera, cache dostawcy CDN. Wystarczy, że jedna z warstw serwuje zapisany HTML, i wszyscy widzą koszyk pierwszego klienta albo pusty. - Rozjazd adresu strony. Sklep dostępny pod
wwwi bezwww, albo podhttpihttps, ustawia ciasteczka osobno dla każdej wersji. Przejście z jednej na drugą gubi koszyk. Jedna wersja kanoniczna i przekierowanie 301 z pozostałych. - Tabela sesji WooCommerce przepełniona albo uszkodzona. Sesje żyją w osobnej tabeli i przy dużym sklepie potrafią urosnąć do setek tysięcy wierszy, co spowalnia każdy odczyt aż do przekroczenia limitu czasu.
- Wtyczka bezpieczeństwa albo zgody na ciasteczka blokuje ciasteczko sesji. Część banerów zgody blokuje wszystkie ciasteczka do momentu akceptacji - także funkcjonalne, bez których sklep nie może działać. Ciasteczka koszyka WooCommerce muszą być zawsze w kategorii niezbędnych.
Objaw 3: przycisk „Kup i zapłać” nic nie robi
Formularz wypełniony, klient klika i nic - żadnego błędu, żadnego przeładowania. To niemal zawsze błąd JavaScriptu, który zatrzymał wykonanie skryptu obsługującego wysyłkę formularza.
Sprawdzenie zajmuje minutę: otwórz kasę, wciśnij F12, przejdź na zakładkę Console i kliknij przycisk. Zobaczysz czerwony komunikat z nazwą pliku, który się wywalił - i to zwykle od razu wskazuje winowajcę.
Najczęstsze przyczyny:
- Wtyczka ładująca własną wersję jQuery obok tej z WordPressa. Dwie wersje w jednym oknie kasują sobie nawzajem obsługę zdarzeń.
- Wtyczka optymalizacyjna łącząca i minifikująca skrypty. Łączenie plików JavaScript w jeden to najczęstszy sprawca awarii kasy w sklepie, który „działał wczoraj”. Wyłącz łączenie i minifikację na stronie kasy i sprawdź ponownie - to test na trzydzieści sekund.
- Błąd 403 albo 400 przy odwołaniu do
admin-ajax.phplub Store API. Widać go w zakładce Network jako czerwone żądanie. Przyczyną jest zwykle zapora aplikacyjna po stronie hostingu albo wtyczki bezpieczeństwa, która blokuje żądanie z danymi adresowymi jako „podejrzane”. Naprawa: wyjątek w regułach zapory dla adresów kasy. - Błąd w skrypcie bramki płatności - wtedy komunikat w konsoli wskaże plik wtyczki płatniczej.
Objaw 4: „Brak dostępnych metod wysyłki”
Klient wpisuje adres i zamiast kosztu dostawy dostaje komunikat, że wysyłka jest niedostępna. Zamówienia nie da się złożyć.
To prawie nigdy nie jest awaria kodu - to konfiguracja stref wysyłki. WooCommerce → Ustawienia → Wysyłka:
- Adres klienta nie mieści się w żadnej strefie. Strefy działają jak filtry po kraju, województwie i kodzie pocztowym. Jeśli klient jest spoza zdefiniowanych obszarów, wpada do strefy domyślnej („Lokalizacje nieobjęte innymi strefami”) - a ona bywa pusta.
- Strefa istnieje, ale nie ma w niej żadnej metody. Sama strefa nic nie daje, trzeba do niej dodać metodę: stawkę ryczałtową, darmową wysyłkę albo odbiór osobisty.
- Warunek darmowej wysyłki blokuje wszystko. Jeśli w strefie jest wyłącznie darmowa wysyłka od 300 zł, klient z koszykiem za 100 zł nie ma żadnej opcji. Zawsze zostawiaj w strefie metodę bez warunku.
- Klasy wysyłkowe bez zdefiniowanej stawki. Jeśli produkt ma przypisaną klasę wysyłkową, a metoda nie ma stawki dla tej klasy ani stawki „bez klasy”, metoda zniknie z listy.
- Wtyczka przewoźnika nie dostaje odpowiedzi z API i nie pokazuje żadnej opcji. Wtedy w logach WooCommerce (WooCommerce → Status → Dzienniki) będzie wpis wtyczki z błędem połączenia.
Test kontrolny: dodaj do strefy tymczasową stawkę ryczałtową 0 zł i sprawdź, czy się pokazuje. Jeśli tak, problem jest w konfiguracji metod, nie w kasie.
Objaw 5: nie widać metod płatności po przejściu na kasę blokową
Klient dochodzi do sekcji płatności i nie ma tam nic albo jest tylko przelew tradycyjny, choć w ustawieniach bramka jest włączona.
Przyczyna jest niemal zawsze jedna: wtyczka bramki nie deklaruje zgodności z kasą blokową. Kasa blokowa nie renderuje starych metod płatności automatycznie - każda musi zarejestrować się osobno w rejestrze metod dla bloków. Wtyczka, która tego nie robi, nie wyrzuca błędu; po prostu jej nie ma na liście.
Trzy drogi wyjścia, w kolejności:
- Zaktualizuj wtyczkę bramki. Większość dużych operatorów obsługuje kasę blokową od dawna, ale sklepy z zamrożonymi aktualizacjami siedzą na wersjach sprzed tej zmiany.
- Sprawdź, czy operator ma nowszą wtyczkę pod inną nazwą - część przepisała integracje od nowa zamiast aktualizować starą.
- Wróć tymczasowo do klasycznej kasy (opis niżej) i zaplanuj migrację na spokojnie.
To samo dotyczy wtyczek do wysyłki i do faktur - przy przejściu na kasę blokową sprawdza się cały zestaw, nie tylko płatności. Jak zaplanować taką aktualizację, żeby nie odkryć problemu na produkcji, rozpisałem w checkliście bezpiecznych aktualizacji.
Objaw 6: zamówienie utyka jako „oczekujące na płatność” mimo zapłaty
Klient płaci, bank potwierdza, pieniądze są - a w sklepie zamówienie ma status „oczekujące na płatność” i nikt nie dostaje maila.
Tu awaria nie jest w kasie, tylko w powrotnej wiadomości od operatora płatności. Bramka po zaksięgowaniu wysyła do sklepu powiadomienie, które zmienia status. Jeśli to powiadomienie nie dojdzie, zamówienie zostaje w miejscu.
Gdzie sprawdzić, po kolei:
- Notatki zamówienia w panelu, prawa kolumna. Jest tam ślad każdej próby komunikacji z bramką i to pierwsze miejsce, w które zaglądam.
- Dzienniki WooCommerce (WooCommerce → Status → Dzienniki) - wtyczki bramek logują tam odpowiedzi z API.
- Panel operatora płatności - każdy ma historię wysłanych powiadomień z kodem odpowiedzi. Kod inny niż 200 oznacza, że sklep odrzucił żądanie.
- Zapora hostingu i wtyczka bezpieczeństwa - najczęstszy sprawca. Żądanie przychodzi z serwera operatora, wygląda nietypowo i wpada w regułę blokującą. Naprawa to wpisanie adresów operatora na białą listę.
- Cache na stronie podziękowania - potrafi pokazać klientowi zapisaną stronę cudzego zamówienia.
Objawy tego problemu bywają identyczne jak awaria kasy, a przyczyna jest zupełnie inna - dlatego opisałem go szerzej przy porównaniu bramek płatności.
Narzędzia, którymi to się diagnozuje
Cztery rzeczy, bez których diagnoza jest zgadywaniem:
- Konsola przeglądarki (F12). Zakładka Console pokazuje błędy JavaScriptu, zakładka Network - żądania, które wróciły z błędem. To pierwsze miejsce przy każdym „nic się nie dzieje po kliknięciu”.
- Tryb debugowania WordPressa. W pliku
wp-config.phpustawiaszWP_DEBUGiWP_DEBUG_LOGnatrue, aWP_DEBUG_DISPLAYnafalse- błędy trafią wtedy do plikuwp-content/debug.log, a nie na oczy klientów. Po naprawie wyłącz to z powrotem. - Dzienniki WooCommerce - WooCommerce → Status → Dzienniki. Bramki, wtyczki wysyłkowe i integracje piszą tu wprost, co poszło nie tak.
- Kopia sklepu do testów. Wyłączanie wtyczek na żywym sklepie w środku dnia to gotowe zlecenie na drugą awarię.
Metoda połowienia, gdy nic nie widać w logach
Klasyka, która działa zawsze, choć nudno:
- Zrób kopię zapasową i pracuj na kopii sklepu.
- Przełącz motyw na domyślny (Storefront albo dowolny motyw WordPressa). Kasa działa? Winny jest motyw.
- Wyłącz wszystkie wtyczki poza WooCommerce i bramką płatności. Działa? Winna jest jedna z wyłączonych.
- Włączaj po połowie naraz, sprawdzając kasę po każdej rundzie. Przy dwudziestu wtyczkach znajdziesz winowajcę w pięciu krokach, nie w dwudziestu.
Gdy już wiesz, która wtyczka, masz trzy opcje: aktualizacja, zamiennik albo zgłoszenie do autora z konkretnym błędem z konsoli. Trzymanie wyłączonej wtyczki jako „naprawy” jest rozwiązaniem tylko wtedy, gdy nikt jej nie potrzebuje.
Obejście awaryjne: powrót do klasycznej kasy
Jeśli awaria pojawiła się razem z przejściem na kasę blokową i sklep stoi, masz szybkie wyjście. Wchodzisz do edytora strony zamówienia, usuwasz blok kasy i wstawiasz w to miejsce shortcode [woocommerce_checkout]. Sklep wraca na klasyczną implementację, w której działają stare wtyczki i stare snippety.
Traktuj to jako plaster, nie jako rozwiązanie. Kasa blokowa jest kierunkiem, w którym WooCommerce idzie, i za rok część wtyczek będzie wspierać wyłącznie ją. Ale plaster, który przywraca sprzedaż tego samego popołudnia, jest wart swojej ceny - migrację zrobisz potem, na kopii i bez pośpiechu.
Kolejność diagnozy w pigułce
- Odtwórz awarię w oknie prywatnym i zapisz warunki: urządzenie, produkt, adres, zalogowany czy gość
- Otwórz konsolę przeglądarki (F12) - czerwony błąd wskaże plik
- Sprawdź zakładkę Network pod kątem żądań z kodem 400, 403 lub 500
- Zajrzyj w notatki zamówienia i w WooCommerce → Status → Dzienniki
- Włącz tryb debugowania i przeczytaj
wp-content/debug.log - Sprawdź strefy wysyłki i wyjątki cache dla koszyka, kasy i konta
- Na kopii sklepu: domyślny motyw, potem metoda połowienia wtyczek
- Napraw przyczynę, wyłącz debugowanie, złóż testowe zamówienie od początku do końca
Pierwsze cztery kroki to kwadrans i w większości przypadków wskazują winowajcę. Jeśli po nich nadal nie wiadomo, problem jest zwykle po stronie serwera - i tam trzeba zajrzeć w logi błędów PHP.
Kiedy to nie jest awaria kasy
Trzy sytuacje, które wyglądają jak awaria, a nią nie są, i warto je odsiać, zanim zaczniesz grzebać:
- Kasa ładuje się bardzo długo, ale w końcu działa. To problem wydajności, nie awaria - opisałem go przy wolnym sklepie WooCommerce.
- Klienci dochodzą do kasy i nie kończą. To konwersja, nie awaria; przyczyny i kolejność napraw są przy porzuconych koszykach.
- Zamówienia wpadają, ale nikt nie dostaje maila. Kasa działa poprawnie, problem jest w wysyłce poczty ze sklepu - i tam trzeba szukać: uwierzytelnienie wysyłki, wpisy SPF i DKIM w domenie, kolejka zadań. To osobna diagnoza, niezwiązana z kasą.
Najczęstsze pytania
Kasa działa u mnie, a klienci zgłaszają, że nie mogą kupić. Jak to sprawdzić? Testuj w oknie prywatnym, jako niezalogowany, na telefonie i na danych komórkowych. Zalogowany administrator omija cache, ma inne uprawnienia i często inny zestaw skryptów - dlatego u Ciebie działa wszystko. Poproś też zgłaszającego klienta o dokładny objaw i zrzut ekranu; „nie działa” bez tego nie da się odtworzyć.
Czy mogę stracić zamówienia przez awarię kasy? Zamówienia już złożone są bezpieczne - siedzą w bazie i awaria kasy ich nie dotyka. Tracisz te, których klienci nie zdążyli złożyć, i nie ma po nich śladu w panelu. Dlatego przy awarii kasy liczy się godzina, a nie dzień: sklep, który nie przyjmuje zamówień, jest zamknięty.
Po aktualizacji WooCommerce kasa przestała działać. Cofnąć aktualizację? Cofanie samego WooCommerce rzadko jest właściwą odpowiedzią, bo problem zwykle leży we wtyczce, która nie nadążyła za zmianą. Szybciej znajdziesz winowajcę metodą połowienia. Jeśli musisz przywrócić sprzedaż natychmiast - przywróć kopię sprzed aktualizacji, a diagnozę zrób na kopii testowej.
Czy błąd 403 na admin-ajax.php to problem hostingu?
Najczęściej tak - to zapora aplikacyjna po stronie serwera albo wtyczki bezpieczeństwa blokująca żądanie z danymi adresowymi. Zgłoś to hostingowi z dokładnym adresem żądania i godziną; w logach zapory zobaczą regułę, która je zablokowała, i dodadzą wyjątek. Sam adres admin-ajax.php jest zupełnie normalnym elementem WordPressa, nie oznaką włamania.
Ile trwa naprawa niedziałającej kasy? Jeśli przyczyną jest konfliktowa wtyczka, cache albo strefa wysyłki - godziny, nie dni. Diagnoza to zwykle kwadrans do dwóch, naprawa tyle samo. Dłużej trwa tylko wtedy, gdy trzeba przepisać integrację pod kasę blokową albo gdy awaria nałożyła się na inny problem, na przykład na przeciążony serwer. Konkretną liczbę podaję po zajrzeniu do sklepu, zawsze na piśmie i przed startem.
Masz to u siebie i nie wiesz, od czego zacząć? Przyspieszam i naprawiam istniejące strony i sklepy - Core Web Vitals, awarie, rozbudowa o funkcje, których brakuje. Porozmawiajmy o projekcie.