Koszyk PrestaShop znika po dodaniu produktu? Diagnostyka cookies, domeny i cache

Produkty znikają po odświeżeniu strony, zmianie podstrony lub przejściu do płatności? Zobacz, jak krok po kroku sprawdzić cookies, sesje, cache, domenę, SSL, moduły i logi PrestaShop bez narażania zamówień klientów.

Masz problem z koszykiem w PrestaShop?

Możemy zdiagnozować cookies, sesje, cache, domenę, SSL, moduły i inne przyczyny problemów z koszykiem oraz przywrócić prawidłowe działanie procesu zakupowego.

NAPRAWA KOSZYKA PRESTASHOP

Klient dodaje produkt, widzi poprawny komunikat, a chwilę później trafia do pustego koszyka. Innym razem zawartość znika dopiero po odświeżeniu strony, zalogowaniu albo przejściu do płatności. Taki problem jest szczególnie groźny, ponieważ nie zawsze powoduje widoczny błąd techniczny. Sklep może działać szybko i wyglądać poprawnie, a mimo to skutecznie uniemożliwiać złożenie zamówienia.

Naprawa PrestaShop w tej sytuacji nie powinna zaczynać się od przypadkowego wyłączania modułów ani usuwania danych z bazy. Najpierw trzeba ustalić dokładny moment utraty koszyka i sprawdzić, czy przeglądarka, aplikacja oraz serwer rozpoznają klienta jako tę samą sesję podczas kolejnych żądań.

Jak dokładnie objawia się problem z koszykiem?

Określenie „koszyk się opróżnia” może opisywać kilka odmiennych usterek. Ich rozróżnienie znacząco skraca diagnostykę. Warto sprawdzić, czy:

  • produkt znika natychmiast po dodaniu,
  • licznik w nagłówku pokazuje inną wartość niż strona koszyka,
  • zawartość przepada dopiero po odświeżeniu strony,
  • koszyk resetuje się przy przejściu z kategorii do produktu,
  • zmiana ilości nie zapisuje się lub wraca do poprzedniej wartości,
  • problem pojawia się po zalogowaniu albo wylogowaniu klienta,
  • produkty znikają po przekierowaniu do operatora płatności lub po powrocie do sklepu,
  • usterka dotyczy tylko jednej wersji językowej, waluty, subdomeny albo urządzeń mobilnych.

W PrestaShop identyfikacja bieżącego koszyka jest powiązana z danymi przechowywanymi po stronie przeglądarki i rekordami w bazie. Jeżeli identyfikator koszyka nie zostanie zapisany, nie wróci w kolejnym żądaniu albo zostanie zastąpiony, użytkownik może otrzymać nowy, pusty koszyk. Niekiedy dane nadal znajdują się w bazie, lecz sklep przestaje łączyć je z konkretną wizytą.

Zacznij od testu, który można powtórzyć

Przed zmianą konfiguracji przygotuj prosty scenariusz testowy. Otwórz kartę produktu, dodaj jedną sztukę, przejdź do koszyka, zmień ilość, odśwież stronę, odwiedź kategorię i wróć do zamówienia. Następnie powtórz te same czynności po zalogowaniu.

Test wykonaj przynajmniej w:

  • zwykłym oknie używanej przeglądarki,
  • trybie incognito lub prywatnym,
  • drugiej przeglądarce,
  • telefonie korzystającym z innego połączenia internetowego.

Jeżeli problem występuje tylko w zwykłym oknie, podejrzenie pada na stare cookies, rozszerzenie przeglądarki, blokadę skryptów albo dane zapisane przez wcześniejszą wersję sklepu. Jeśli usterka pojawia się wszędzie, należy skupić się na konfiguracji PrestaShop, domenie i warstwie serwerowej.

Test incognito nie stanowi jednak dowodu, że przyczyną są wyłącznie cookies. W tym trybie często nie działają niektóre rozszerzenia, a przeglądarka rozpoczyna wizytę bez istniejących danych. To narzędzie porównawcze, a nie gotowa diagnoza.

Cookies: czy sklep rozpoznaje ten sam koszyk?

W narzędziach deweloperskich przeglądarki można sprawdzić, jakie cookies ustawia sklep oraz czy ich wartości zmieniają się podczas przechodzenia między podstronami. Szczególną uwagę należy zwrócić na zakres domeny, ścieżkę, termin ważności oraz atrybut Secure.

Typowym sygnałem błędu jest powstanie dwóch podobnych cookies dla różnych hostów, na przykład osobno dla domeny z „www” i bez „www”. Przeglądarka może wówczas wysyłać inny zestaw danych zależnie od adresu podstrony. Podobny efekt wystąpi, gdy cookie ma zbyt wąską ścieżkę i nie jest dostępne w całym sklepie.

W witrynie działającej wyłącznie przez HTTPS cookies wymagające bezpiecznego połączenia powinny być obsługiwane konsekwentnie. Naprzemienne otwieranie adresów HTTP i HTTPS, błędne wykrywanie protokołu za reverse proxy albo niepełne przekierowania mogą przerwać ciągłość wizyty.

Trzeba też skontrolować moduł zgód cookies. Narzędzie do zarządzania zgodami nie powinno blokować danych koniecznych do działania koszyka. Jeżeli po odrzuceniu marketingu nie można utrzymać produktu w koszyku, konfiguracja kategorii cookies lub sposób wstrzykiwania skryptów wymaga sprawdzenia.

Sesje PHP i zapis danych na serwerze

Sam mechanizm koszyka PrestaShop nie powinien być automatycznie utożsamiany wyłącznie z sesją PHP. Rdzeń sklepu korzysta z własnego kontekstu, cookie i danych zapisanych w bazie. Sesje PHP mogą jednak uczestniczyć w działaniu dodatkowych modułów, integracji płatniczych, niestandardowego checkoutu lub warstwy uwierzytelniania.

Jeżeli używany element zależy od sesji PHP, należy sprawdzić między innymi miejsce zapisu sesji, uprawnienia katalogu, czas ich przechowywania oraz sposób działania na wielu serwerach. Przy infrastrukturze z load balancerem kolejne żądania mogą trafiać do różnych węzłów. Jeśli serwery nie współdzielą magazynu sesji i nie zastosowano odpowiedniego mechanizmu kierowania ruchu, klient może raz widzieć zapisany stan, a za chwilę trafić do pustej sesji.

Warto również sprawdzić wolne miejsce na dysku i komunikaty o braku możliwości zapisu. Skrócenie czasu życia sesji, automatyczne czyszczenie katalogu tymczasowego albo różne ustawienia PHP dla strony i zaplecza mogą powodować usterki pojawiające się dopiero po określonym czasie.

Cache może pokazywać cudzy lub nieaktualny stan

Cache jest potrzebny, ale koszyk i elementy zależne od konkretnego klienta wymagają ostrożnego traktowania. Problem może powstać na kilku poziomach: w cache Smarty, module optymalizacyjnym, reverse proxy, konfiguracji hostingu albo sieci CDN.

Jeśli pełna odpowiedź HTML zostanie zapisana bez uwzględnienia cookies, użytkownik może zobaczyć stronę wygenerowaną dla pustego koszyka. Z kolei pamięć podręczna odpowiedzi AJAX może sprawić, że licznik w nagłówku nie odpowiada rzeczywistym danym zapisanym w bazie.

Podczas testu sprawdź nagłówki odpowiedzi oraz wpisy HIT, MISS, BYPASS lub podobne oznaczenia stosowane przez daną usługę. Strony koszyka, logowania i finalizacji zamówienia powinny być wyłączone z agresywnego cache. Reguły mogą również omijać pamięć podręczną po wykryciu cookie identyfikującego aktywną wizytę. Nie należy jednak kopiować gotowej konfiguracji bez sprawdzenia nazw cookies i architektury konkretnego sklepu.

Konflikty modułów i skryptów JavaScript

Jeśli żądanie dodania produktu nie jest wysyłane albo kończy się błędem, przyczyną może być JavaScript. W konsoli przeglądarki należy szukać wyjątków pojawiających się bezpośrednio po kliknięciu przycisku. W zakładce Network warto natomiast sprawdzić status odpowiedzi, jej treść, adres docelowy oraz występujące przekierowania.

Najczęściej podejrzane są moduły:

  • minikoszyka i szybkich zakupów,
  • jednostronicowego checkoutu,
  • płatności i rat,
  • zarządzania zgodami cookies,
  • łączenia, opóźniania i minimalizacji JavaScript,
  • dynamicznych cen, zestawów i stanów magazynowych,
  • obsługi wielu walut lub krajów,
  • zewnętrznej synchronizacji produktów.

Nie zakładaj, że winny jest ostatnio zainstalowany moduł. Aktualizacja mogła ujawnić wcześniejszy konflikt, a zmiana cache lub PHP mogła wpłynąć na rozszerzenie działające od miesięcy. Test polega na kontrolowanym wyłączaniu pojedynczych elementów i powtarzaniu identycznego scenariusza, najlepiej na kopii sklepu.

Domena, SSL i przekierowania www/non-www

W ustawieniach adresu sklepu domena główna, domena SSL i katalog bazowy muszą odpowiadać rzeczywistemu adresowi instalacji. Należy wybrać jeden wariant hosta i konsekwentnie kierować do niego cały ruch.

Sprawdź kolejno adres produktu, żądanie dodania do koszyka, stronę koszyka i checkout. Żaden etap nie powinien samoczynnie zmieniać hosta, protokołu ani katalogu instalacji. Szczególnie niebezpieczne są łańcuchy przekierowań typu HTTP → HTTPS → www → adres bez www. Każdy dodatkowy krok zwiększa ryzyko rozbieżności w obsłudze cookies i utrudnia analizę.

Przy CDN lub reverse proxy trzeba dodatkowo potwierdzić, że PrestaShop prawidłowo rozpoznaje pierwotne połączenie HTTPS. Błędna konfiguracja nagłówków przekazywanych przez proxy może prowadzić do generowania nieprawidłowych adresów lub niewłaściwych atrybutów cookies.

Co sprawdzić w logach PrestaShop i serwera?

Logi analizuj z dokładnym czasem wykonania testu. Zapisz godzinę, adres produktu, użyte konto i kolejność czynności. Dzięki temu można zestawić błąd widoczny w przeglądarce z wpisem aplikacji, PHP, serwera WWW lub proxy.

Warto przejrzeć:

  • logi aplikacyjne PrestaShop,
  • rejestr zdarzeń dostępny w panelu administracyjnym,
  • log błędów PHP,
  • logi Apache albo Nginx,
  • logi reverse proxy i CDN,
  • logi modułu płatności lub checkoutu.

Szukaj błędów zapisu cookies i sesji, wyjątków modułów, odpowiedzi 403 i 500, nieoczekiwanych przekierowań oraz przekroczeń limitów. Tryb debugowania może dostarczyć dodatkowych informacji, ale na działającym sklepie powinien być włączany na krótko i pod kontrolą. Komunikaty techniczne nie mogą być pozostawione publicznie, a po zakończeniu testów debug należy wyłączyć.

Bezpieczna procedura naprawy koszyka

  1. Zapisz stan początkowy. Zanotuj objawy, godziny testów i ostatnie zmiany w sklepie.
  2. Wykonaj kopię plików i bazy danych. Upewnij się, że backup można odtworzyć, a nie tylko pobrać.
  3. Nie usuwaj tabel koszyków ani zamówień. Puste rekordy nie są zwykle źródłem problemu, a masowe czyszczenie może zniszczyć materiał diagnostyczny.
  4. Utwórz środowisko testowe. Ogranicz wysyłkę wiadomości i połączenia z produkcyjnymi płatnościami.
  5. Sprawdź domenę, HTTPS i cookies. Napraw podstawową ciągłość identyfikacji przed zmianami w modułach.
  6. Wyłącz cache stron dynamicznych. Wyczyść właściwe warstwy pamięci podręcznej i ponów test.
  7. Testuj moduły pojedynczo. Po każdej zmianie wykonuj ten sam scenariusz zakupowy.
  8. Przenieś tylko potwierdzoną poprawkę. Nie wdrażaj na produkcji całego zestawu eksperymentalnych zmian.
  9. Wykonaj test końcowy. Sprawdź gościa, zalogowanego klienta, urządzenie mobilne, zmianę ilości i powrót z płatności.

Dobra diagnostyka koszyka polega na ustaleniu, na którym etapie sklep traci ciągłość kontekstu klienta. Dopiero wtedy wiadomo, czy potrzebna jest korekta cookies, reguł cache, konfiguracji serwera czy kodu modułu. Taka kolejność ogranicza czas niedostępności i chroni dane, które są najważniejsze w każdym sklepie: koszyki, konta klientów i zamówienia.

Najczęściej zadawane pytania (FAQ)

Dlaczego koszyk w PrestaShop znika po dodaniu produktu lub odświeżeniu strony?

Jeśli identyfikator koszyka nie zostanie zapisany, nie wróci w kolejnym żądaniu albo zostanie zastąpiony, sklep może wyświetlić nowy, pusty koszyk. Dane mogą nadal znajdować się w bazie, ale sklep przestaje łączyć je z konkretną wizytą.

Od czego zacząć diagnostykę znikającego koszyka?

Przygotuj powtarzalny test: dodaj produkt, przejdź do koszyka, zmień ilość, odśwież stronę i wróć do zamówienia po odwiedzeniu kategorii. Powtórz go po zalogowaniu oraz w trybie prywatnym, drugiej przeglądarce i na telefonie korzystającym z innego połączenia. Sam poprawny wynik w incognito nie dowodzi, że winne są wyłącznie cookies.

Co sprawdzić w cookies i adresach sklepu, gdy koszyk się opróżnia?

Sprawdź domenę, ścieżkę, termin ważności i atrybut Secure cookies oraz to, czy nie powstają osobne cookies dla adresów z www i bez www. Produkt, dodawanie do koszyka i checkout nie powinny samoczynnie zmieniać hosta, protokołu ani katalogu instalacji. Skontroluj też, czy moduł zgód nie blokuje danych koniecznych do działania koszyka.

Czy cache może powodować wyświetlanie pustego koszyka?

Tak, zapisanie pełnej odpowiedzi HTML bez uwzględnienia cookies może spowodować wyświetlenie strony wygenerowanej dla pustego koszyka. Cache odpowiedzi AJAX może też sprawić, że licznik w nagłówku nie odpowiada danym w bazie. Strony koszyka, logowania i finalizacji zamówienia powinny być wyłączone z agresywnego cache.