Soban
Sklep nie przyjmuje zamówień po aktualizacji — co sprawdzić?
Po aktualizacji WordPressa, WooCommerce, PrestaShop, modułu płatności albo PHP sklep przestał przyjmować zamówienia? Najpierw ustal, na którym etapie zatrzymuje się zakup. Niedziałający koszyk, błąd przy płatności i brak potwierdzenia mogą mieć różne przyczyny.
Ten poradnik pomoże zebrać informacje do naprawy i ograniczyć ryzyko kolejnych problemów. Nie wymaga wykonywania próbnych płatności na działającym sklepie.
Płatność pobrana, a zamówienia nie widać?
Najpierw porównaj panel sklepu z panelem operatora płatności. Ustal numer transakcji, kwotę, godzinę i jej stan: próba, autoryzacja i skutecznie pobrana płatność to różne sytuacje. Nie zakładaj ani sukcesu, ani braku obciążenia na podstawie samego komunikatu w przeglądarce.
Nie zachęcaj klienta do wielokrotnego ponawiania płatności przed sprawdzeniem poprzedniej próby. Jeśli pieniądze zostały pobrane, dalsze działanie wymaga uzgodnienia statusu transakcji i zamówienia, a czasem kontaktu z operatorem.
Zapisz objaw i ostatnie zmiany
- Czy produkt trafia do koszyka i czy poprawnie liczy się cena oraz dostawa?
- Czy problem dotyczy gościa, zalogowanego klienta czy obu przypadków?
- Czy widać metody płatności i czy działa przekierowanie do operatora?
- Czy pojawia się konkretny błąd, biały ekran lub niekończące się ładowanie?
- Co zmieniono bezpośrednio wcześniej: aplikację, motyw, moduł, PHP, cache lub reguły ochrony?
Zapisz godzinę i adres problematycznego kroku. Zrzut ekranu do zgłoszenia powinien mieć zasłonięte dane klienta. Nie publikuj całych logów, tokenów ani identyfikatorów sesji.
Gdy nie działa koszyk lub wybór dostawy
Administrator powinien sprawdzić błędy JavaScript i nieudane żądania sieciowe oraz dopasować je do logów serwera. Istotne jest, czy błąd występuje przed wysłaniem zamówienia, czy już podczas jego zapisu. Sam komunikat „spróbuj ponownie” nie określa przyczyny.
Po zmianach cache lub optymalizacji trzeba sprawdzić, czy dynamiczne etapy zakupu nie dostają nieaktualnych danych. Reguły dobiera się do konkretnego sklepu i rozszerzeń. Wyłączenie całej ochrony lub losowe czyszczenie danych sesji na produkcji nie jest dobrym testem przyczyny.
Gdy zniknęły metody płatności
Sprawdź konfigurację modułu, jego zgodność z aplikacją oraz warunki wyświetlania danej metody. W WooCommerce znaczenie może mieć również obsługa klasycznego formularza i blokowego checkoutu przez rozszerzenie. Nie zmieniaj kluczy płatności, dopóki nie ma dowodu, że problem dotyczy poświadczeń.
Jeżeli płatność u operatora zakończyła się powodzeniem, ale sklep nie zmienił statusu, trzeba sprawdzić log powiadomienia zwrotnego, webhooka lub callbacku właściwego dla tego modułu. Ponowne wysłanie powiadomienia wykonuje się według instrukcji operatora, po sprawdzeniu istniejących danych.
Gdy po zmianie PHP występuje błąd 500
Wróć do pierwszego błędu z odpowiedniej godziny. Przyczyną może być kod motywu, modułu lub brakujące rozszerzenie PHP. Nie każdy błąd serwera oznacza włamanie. Zobacz diagnostykę błędu 500 po zmianie PHP i plan aktualizacji PHP z testami.
W PrestaShop tryb debug może ujawniać błędy odwiedzającym. Szczegółową diagnostykę prowadź na zabezpieczonym teście, a na produkcji korzystaj z odpowiednio chronionych logów. Nie zostawiaj publicznego wyświetlania błędów po naprawie.
Sprawdź, czy baza może zapisać zamówienie
Jeśli log wskazuje błąd zapisu lub pełną tabelę, administrator powinien skontrolować bazę i jej zasoby. Samo zwiększenie limitu pamięci nie naprawia każdej takiej sytuacji. Przykład opisuje poradnik MySQL 1114: The table is full.
Test konfliktu i wycofanie zmiany
Odtwórz problem na osobnym środowisku z kopią danych zabezpieczoną przed dostępem osób postronnych. Wyłącz wysyłkę maili oraz produkcyjne integracje. Płatności sprawdzaj wyłącznie w prawidłowo skonfigurowanym sandboxie danego operatora; samo skopiowanie sklepu nie przełącza modułu w tryb testowy.
W WooCommerce można na tej kopii stopniowo wykluczać konflikt motywu lub wtyczek, zachowując elementy niezbędne do odtworzenia problemu. Po jednej zmianie powtórz tę samą próbę i zapisz wynik. Dla PrestaShop dobierz analogiczny plan do modułów i wersji sklepu.
Powrót do starszych plików i odtworzenie starszej bazy to różne operacje. Aktualizacja mogła zmienić strukturę danych, a po wykonaniu backupu mogły wpłynąć nowe zamówienia. Cofnięcie trzeba zaplanować z uwzględnieniem tych zmian.
Kiedy uznać naprawę za sprawdzoną?
Na teście sprawdź cały uzgodniony przebieg: produkt, koszyk, dostawę, płatność testową, pojedyncze zamówienie i właściwy status. Uwzględnij telefon i komputer oraz typ klienta, którego dotyczyła awaria. Po selektywnym wdrożeniu na produkcję skontroluj działanie bez nieuzgodnionych obciążeń i monitoruj kolejne zdarzenia.
Potrzebujesz pomocy z niedziałającym sklepem? Podaj domenę, objaw, moment ostatniego poprawnego działania i listę zmian. Dostęp do diagnozy ustalimy osobno; nie wysyłaj hasła w pierwszej wiadomości.