Problemy z WooCommerce - jak diagnozować i naprawiać

Zgłoszenie sklep nie działa zamień na opis czynności. Czy strona się nie otwiera, produkt nie trafia do koszyka, płatność nie kończy się poprawnie, czy zamówienie istnieje bez wiadomości? Zapisz adres podstrony, przybliżony czas, urządzenie, status logowania i dokładny komunikat. Przy zamówieniu zachowaj jego identyfikator, bez publikowania danych kupującego.

Sprawdź, czy problem dotyczy wszystkich produktów i metod płatności, czy jednego wariantu. Porównaj moment awarii z aktualizacją, zmianą konfiguracji, importem danych lub działaniem integracji. Zbieżność czasowa jest wskazówką, nie dowodem winy konkretnej wtyczki.

Przed naprawą zabezpiecz aktualny stan plików i bazy oraz upewnij się, że istnieje sposób odtworzenia kopii. Gdy awaria wpływa na płatności, ustal z administratorem sposób ograniczenia dalszych błędnych operacji. Nie usuwaj zamówień tylko dlatego, że mają nieoczekiwany status. Mogą być potrzebne do wyjaśnienia transakcji i późniejszego uzgodnienia rozliczeń.

Staging powinien pozwalać odtworzyć konfigurację bez wysyłania prawdziwych wiadomości, płatności, paczek lub zleceń do zewnętrznych systemów. Samo skopiowanie domeny nie odłącza integracji. Przed próbą sprawdź klucze, webhooki, zadania cykliczne i dostęp do kopii danych. Uzgodnij, które operacje są izolowane, a których nie można bezpiecznie odtworzyć.

Dokumentacja WooCommerce dotycząca konfliktów zaleca kontrolę motywu i dodatków. Na kopii pozostaw WooCommerce oraz element niezbędny do odtworzenia badanego procesu, a kolejne zmiany wykonuj pojedynczo. Zapisuj wynik i konfigurację, przy której problem wraca. Sprawdź też dodatki wymuszane przez hosting i warstwy cache niewidoczne na zwykłej liście wtyczek.

Health Check jest osobną wtyczką. Przy kontroli 12.09.2026 katalog informuje o braku testów z trzema ostatnimi głównymi wydaniami WordPress, więc nie jest to domyślna rekomendacja instalacji. Opisany przez autorów tryb troubleshooting pozwala zmieniać konfigurację widzianą w sesji testującego użytkownika, ale nie stanowi kompletnej izolacji zewnętrznych zdarzeń. Nie traktuj go jako zamiennika przygotowanego środowiska do sprawdzania całego łańcucha obsługi zamówienia.

Kod 500 mówi o błędzie serwera, ale sam nie wskazuje brakującej pamięci ani konkretnego dodatku. W logach szukaj wpisu z czasu odtworzenia problemu. Przydatne są typ błędu, plik, operacja i powtarzalność. Ostatni komunikat na ekranie nie zawsze jest przyczyną całego zdarzenia.

Dokumentacja WordPress zaznacza: "It is not recommended to use WP_DEBUG or the other debug tools on live sites". Opis debugowania rozdziela funkcje stałych: WP_DEBUG włącza tryb diagnostyczny, WP_DEBUG_LOG zapisuje log, a WP_DEBUG_DISPLAY kontroluje wyświetlanie komunikatów. Wyłączenie DISPLAY samo nie włącza logowania. LOG może wskazywać plik poza standardowym katalogiem treści.

Konfigurację diagnostyczną powinien przygotować administrator na kontrolowanej kopii. Trzeba zmienić istniejące ustawienia bez duplikowania definicji, ograniczyć dostęp do loga i ustalić czas jego przechowywania. Nie wklejaj całego loga do publicznego zgłoszenia. Szerszą ścieżkę awarii opisuje poradnik błędów WordPress.

Najpierw porównaj status zamówienia, jego notatki i informację operatora płatności. Powrót kupującego do sklepu oraz powiadomienie serwerowe operatora to różne zdarzenia. Klient może zamknąć przeglądarkę, mimo że płatność została przyjęta. Z kolei samo wyświetlenie strony podziękowania nie powinno zastępować sprawdzenia rozliczenia.

W poradniku błędów płatności WooCommerce punktem diagnozy są między innymi statusy, logi i konfiguracja bramki. Porównuj zdarzenia po identyfikatorach, bez ponawiania prawdziwej płatności na próbę. W razie niejasności uzgodnij stan z operatorem lub administratorem, zanim zmienisz zamówienie ręcznie.

Sprawdź wersję modułu, środowisko płatności i zgodność z używanym checkout, w tym Blocks. Nie zakładaj, że automatycznie wygasł klucz albo że każdą awarię naprawi jego wymiana. Na kopii przeprowadź przewidziane przez dostawcę scenariusze testowe i sprawdź również anulowanie oraz błąd odpowiedzi. Zapisz oczekiwany status końcowy dla każdego przypadku.

Wybierz konkretną czynność: otwarcie kategorii, wyszukiwanie, dodanie do koszyka lub zapis zamówienia. Zmierz ją w porównywalnych warunkach przed zmianą i po niej. Wolna karta produktu oraz wolny panel administracyjny mogą mieć inne przyczyny. Sprawdź obciążenie serwera, zapytania bazy i połączenia do usług zewnętrznych, zanim zmienisz pakiet hostingu.

WooCommerce wskazuje trzy dynamiczne obszary wyłączane z typowego cache całych stron: Cart, Checkout i My Account. Dokumentacja cache pomaga ustalić zakres wykluczeń. Nie oznacza to wyłączenia każdego rodzaju cache całej witryny. Po zmianie sprawdź, czy koszyk i konto nie pokazują cudzych lub nieaktualnych danych.

Rozmiar zdjęć, skrypty dodatków i ciężkie zapytania analizuj na podstawie wyników. Nie włączaj lazy loading najważniejszego obrazu wyłącznie dlatego, że istnieje taka opcja. Nie usuwaj hurtowo zadań kolejki i danych zamówień w ramach przyspieszania. Liczba wtyczek sama nie wyznacza szybkości sklepu.

Dla wiadomości sprawdź, czy zamówienie osiągnęło status uruchamiający dany typ maila i czy powiadomienie jest aktywne. WooCommerce email FAQ wyjaśnia, że pozostawanie przy Pending Payment nie uruchamia typowych wiadomości związanych z opłaconym zamówieniem. W takiej sytuacji konfiguracja SMTP nie naprawi brakującego wyzwalacza.

Jeżeli wiadomość została wygenerowana, przejdź do transportu, odpowiedzi dostawcy poczty i doręczenia. Zapis wysłano nie dowodzi, że odbiorca dostał mail do skrzynki głównej. Szczegóły rozwija poradnik WooCommerce bez maili.

Przy stanach ustal system nadrzędny i mapowanie SKU. Porównaj sprzedaż, rezerwację, anulowanie oraz zwrot dla jednego produktu. Opóźnienie synchronizacji i podwójne przetworzenie zdarzenia wymagają innych poprawek. Nie wyrównuj stanów przez przypadkowe ponawianie importu. Kontrolę źródła danych opisuje poradnik problemów ze stanami. Zachowaj historię badanego produktu, aby ustalić, która operacja zmieniła liczbę sztuk.

Przed aktualizacją zanotuj wersje WordPress, WooCommerce, PHP, motywu i dodatków istotnych dla sprzedaży. Sprawdź zgodność planowanych wydań. Nie łącz zmiany środowiska, motywu i wszystkich integracji w jedną nierozpoznawalną operację. Testuj kolejność, która pozwala wskazać źródło problemu, a po każdej zmianie wykonaj uzgodnione scenariusze.

Wdrożenie sprawdzonej poprawki nie oznacza nadpisania produkcyjnej bazy kopią ze stagingu. W czasie testów sklep mógł przyjąć nowe zamówienia, płatności i zmiany stanów. Ustal sposób przeniesienia kodu i konfiguracji oraz obsługi ewentualnej migracji danych. Plan cofnięcia zmiany też musi uwzględniać nowe zdarzenia.

Przy odbiorze sprawdź produkt, koszyk, dostawę, status zamówienia, wiadomość i integrację magazynową w uzgodnionym zakresie. Zanotuj, co dokładnie wdrożono i jak monitorować objaw po zmianie. Automatyczny komunikat aktualizacja zakończona nie potwierdza, że proces zakupowy działa poprawnie w konfiguracji Twojego sklepu.

Do pierwszego zgłoszenia wystarczy adres sklepu i konkretny objaw. Dodaj czas wystąpienia oraz informację o ostatniej zmianie, jeśli ją znasz. Zrzut komunikatu może pomóc, ale usuń z niego dane klienta i informacje dostępowe. Dostępy techniczne przekazuje się później w uzgodniony sposób, z odpowiednim zakresem uprawnień.

W wycenie rozdziel diagnozę, naprawę potwierdzonej przyczyny i ewentualne dalsze prace. Lista podejrzanych wtyczek nie jest jeszcze rozpoznaniem. Dobry opis odbioru określa, jaka czynność ma działać i po czym zostanie to sprawdzone. Informacje o naprawie WordPress pomagają porównać zakres interwencji.

KC Mobile zajmuje się WordPress i sklepami internetowymi. Jeśli problem blokuje pracę sklepu, opisz go w kontakcie. Nie musisz wcześniej ustalać przyczyny, kompletować pełnego raportu ani deklarować sztywnego budżetu. Zakres diagnozy i potrzebne materiały można ustalić na podstawie zgłoszonego objawu.