Odwirusowywanie PrestaShop – jak ocenić zakres i skuteczność naprawy sklepu?

Samo usunięcie podejrzanego pliku nie oznacza, że sklep jest bezpieczny. Sprawdź, co powinna obejmować usługa odwirusowywania PrestaShop, jak odebrać wykonane prace i ustalić zasady ponownej interwencji.

Odwirusowywanie PrestaShop – jak ocenić zakres i skuteczność naprawy sklepu?

Odwirusowywanie PrestaShop nie powinno sprowadzać się do uruchomienia skanera i skasowania kilku plików oznaczonych jako podejrzane. W przypadku sklepu internetowego trzeba jednocześnie zadbać o bezpieczeństwo danych, ciągłość przyjmowania zamówień oraz prawidłowe działanie płatności, dostaw i panelu administracyjnego. Konieczne jest też ustalenie, w jaki sposób doszło do włamania i czy napastnik nie pozostawił dodatkowych mechanizmów dostępu.

Ocena takiej usługi bywa trudna, ponieważ właściciel sklepu zazwyczaj widzi jedynie zewnętrzne objawy. Może to być przekierowanie, ostrzeżenie przeglądarki albo zmieniona strona płatności. Nie wie jednak, ile elementów zostało naruszonych i czy usunięcie widocznego problemu rzeczywiście zamknęło incydent. Dlatego jeszcze przed zleceniem prac warto ustalić zakres diagnostyki, sposób ochrony bieżących danych i kryteria odbioru naprawy.

Kiedy zlecić odwirusowywanie PrestaShop?

Powodem do kontroli powinno być każde nietypowe zachowanie sklepu, którego nie można wyjaśnić wprowadzoną zmianą. Typowe sygnały to przekierowania na obce domeny, dodatkowe treści w wynikach wyszukiwania, nieznane pliki i konta administratorów, samoczynne zmiany ustawień, ostrzeżenia hostingu, przeglądarki lub Google Search Console, a także nieprawidłowości pojawiające się podczas składania zamówienia.

Szczególnie poważnie należy traktować zmiany dotyczące płatności. Złośliwy skrypt może podmieniać przyciski, prezentować fałszywy formularz albo uruchamiać się wyłącznie na określonym etapie zakupów. Udokumentowane przypadki pokazują również, że infekcja może ukrywać swoje działanie przed zalogowanym administratorem. Samodzielne otwarcie sklepu w tej samej przeglądarce, w której działa panel, nie jest więc miarodajnym testem.

Przed rozpoczęciem prac warto przekazać wykonawcy:

  • adres sklepu i przykładowe podstrony, na których występuje problem,
  • zrzuty ekranu oraz treść otrzymanych ostrzeżeń,
  • przybliżony moment zauważenia pierwszych objawów,
  • wersję PrestaShop, informacje o motywie i używanych modułach,
  • listę ostatnich aktualizacji, instalacji i zmian programistycznych,
  • informacje o dostępnych logach serwera oraz kopiach zapasowych,
  • opis nietypowych zdarzeń związanych z zamówieniami i płatnościami.

Adresy pokazane przez Google należy traktować jako przykłady, a nie pełny spis zainfekowanych miejsc. Rzetelna analiza nie może ograniczać się tylko do podstron wymienionych w raporcie bezpieczeństwa.

Co powinna obejmować oferta odwirusowywania?

Oferta powinna jasno odróżniać diagnostykę, czyszczenie i zabezpieczenie sklepu. Skanowanie plików jest przydatnym narzędziem, ale nie stanowi kompletnej usługi. Złośliwy kod może znajdować się w rdzeniu PrestaShop, module, motywie, plikach pamięci podręcznej, bazie danych albo konfiguracji środowiska. Kontrola wyłącznie plików PHP może zatem pozostawić część problemu bez rozpoznania.

Kompletny zakres powinien obejmować co najmniej:

  • ustalenie skali incydentu i elementów wymagających analizy,
  • kontrolę plików, bazy danych, modułów, motywu i kont użytkowników,
  • usunięcie złośliwego kodu oraz mechanizmów utrzymujących dostęp,
  • porównanie podejrzanych komponentów z czystymi kopiami, jeżeli są dostępne,
  • analizę możliwej drogi włamania,
  • naprawę lub wyłączenie wykorzystanej podatności,
  • ponowną kontrolę po zakończeniu czyszczenia,
  • testy techniczne i biznesowe działającego sklepu.

Wykonawca powinien rozdzielać potwierdzone ustalenia od hipotez. Jeżeli logi zostały usunięte, są niepełne albo obejmują zbyt krótki okres, nie zawsze da się jednoznacznie wskazać drogę włamania. Uczciwy raport opisuje takie ograniczenia, zamiast przedstawiać przypuszczenie jako pewną przyczynę.

Ważna jest również kolejność prac. Aktualizacja podatnego komponentu może zamknąć konkretną lukę, ale nie musi usunąć kodu pozostawionego wcześniej przez atakującego. Producent PrestaShop zwracał już uwagę, że samo zainstalowanie poprawki w przejętym sklepie nie jest równoznaczne z jego oczyszczeniem.

Jak chronić działający sklep i nowe zamówienia?

Przed modyfikacją środowiska specjalista powinien zabezpieczyć materiał do analizy. Potrzebna jest kopia plików i bazy danych wykonana przed czyszczeniem, przechowywana poza publicznie dostępnym katalogiem. Taka kopia może zawierać infekcję, dlatego nie należy uznawać jej automatycznie za bezpieczny punkt odtworzenia. Pozwala jednak zachować stan sklepu potrzebny do analizy zdarzeń.

Osobnym problemem są dane powstające już podczas naprawy. Jeżeli sklep nadal przyjmuje zamówienia, proste odtworzenie starszej bazy może usunąć nowsze transakcje, konta klientów, zmiany stanów magazynowych i statusy płatności. Przed rozpoczęciem prac trzeba zatem ustalić punkt odtworzenia oraz sposób zachowania zapisów powstałych później.

Nie zawsze da się obiecać naprawę bez przerwy w sprzedaży. Gdy istnieje podejrzenie aktywnego przechwytywania danych płatniczych, ograniczenie szkód jest ważniejsze niż utrzymanie checkoutu za wszelką cenę. Zlecenie powinno wskazywać, kto może podjąć decyzję o czasowym wyłączeniu płatności lub całego sklepu oraz kto zatwierdza ponowne uruchomienie sprzedaży.

Od czego zależą cena i czas realizacji?

Nie istnieje jedna uczciwa stawka za każde odwirusowywanie PrestaShop. Koszt zależy od rozmiaru sklepu, skali infekcji, wieku instalacji, liczby modułów, indywidualnych modyfikacji i jakości dostępnych kopii. Znaczenie ma również to, czy wykonawca otrzyma kompletne logi oraz czyste wersje zmodyfikowanych plików.

Więcej pracy może wymagać sklep korzystający ze starego motywu lub porzuconych modułów, ponieważ usunięcie podatności może spowodować problemy ze zgodnością. Wtedy zlecenie obejmuje nie tylko czyszczenie, lecz także aktualizacje, naprawy programistyczne i testy regresji. Czas zajmuje również samo kopiowanie dużej liczby plików oraz wykonywanie i weryfikowanie kopii bazy.

Czytelna wycena powinna osobno wskazywać diagnostykę, usunięcie infekcji, aktualizacje, naprawy zgodności, testy oraz ewentualny monitoring. Jeśli pełnego zakresu nie da się określić przed analizą, rozsądnym rozwiązaniem jest wycena etapowa z przedstawieniem ustaleń przed rozpoczęciem dodatkowych prac.

Jak sprawdzić skuteczność wykonanej usługi?

Brak widocznego przekierowania nie jest wystarczającym dowodem. Po naprawie klient powinien otrzymać raport opisujący znalezione zagrożenia, zmienione lub usunięte elementy, wykonane aktualizacje, wyniki kontroli oraz nierozwiązane ryzyka. Raport nie musi ujawniać każdej wewnętrznej procedury wykonawcy, ale powinien umożliwić ocenę, co faktycznie zostało zrobione.

Odbiór warto podzielić na dwa niezależne obszary. Pierwszym jest kontrola bezpieczeństwa, obejmująca ponowne sprawdzenie plików, bazy, kont i oznak pozostawionego dostępu. Drugim są testy działania sklepu. Należy przeprowadzić pełne zamówienie w czystej sesji klienta, najlepiej bez aktywnego logowania administratora, a następnie sprawdzić płatność, status transakcji, wiadomości e-mail, zmianę stanu magazynowego oraz widoczność zamówienia w panelu.

Trzeba także przetestować logowanie administratora, zarządzanie produktami i podstawowe operacje wykonywane przez obsługę. Jeżeli Google zgłosiło problem bezpieczeństwa, po usunięciu wszystkich wykrytych kategorii zagrożeń należy skorzystać z właściwej procedury weryfikacji. Samo wysłanie prośby o ponowne sprawdzenie nie zastępuje wcześniejszego oczyszczenia całego sklepu.

Co ogranicza ryzyko nawrotu infekcji?

Usunięcie jednego złośliwego skryptu nie dowodzi, że napastnik nie pozostawił innych furtek. Po czyszczeniu wykonawca powinien sprawdzić alternatywne mechanizmy dostępu, nieznane konta, zmodyfikowane zadania cykliczne, podejrzane moduły i pliki uruchamiane automatycznie.

Kolejny etap to aktualizacja lub usunięcie podatnych komponentów. Raport powinien wskazywać, które elementy zostały zaktualizowane, wyłączone albo pozostawione do późniejszej przebudowy. Sam zapis „zalecamy aktualizację” nie oznacza, że aktualizacja została wykonana.

Po incydencie należy również zmienić dane dostępowe do panelu PrestaShop, hostingu, FTP lub SFTP, SSH i bazy danych. Zmiana hasła bazy wymaga jednoczesnego poprawienia konfiguracji sklepu. Warto usunąć nieużywane konta, przypisać osobne konta pracownikom i wykonawcom oraz ograniczyć role administracyjne do rzeczywistych obowiązków.

Jak ustalić odpowiedzialność po zakończeniu prac?

Warunki ponownej interwencji najlepiej uzgodnić jeszcze przed rozpoczęciem naprawy. Umowa lub ustalenia mailowe powinny określać długość monitorowania, zakres kontroli po wdrożeniu oraz sposób zgłaszania kolejnych objawów. Nie ma jednego standardowego okresu gwarancji odpowiedniego dla wszystkich incydentów.

Trzeba też odróżnić nawrót tej samej infekcji od nowego zdarzenia. Powrót usuniętego kodu przez pozostawioną furtkę może świadczyć o niepełnym oczyszczeniu. Nowe włamanie wykorzystujące inną podatność, ujawnioną już po zakończeniu prac, może natomiast stanowić osobny incydent. Ocena wymaga analizy technicznej, dlatego zasady kwalifikowania takich przypadków powinny być opisane z góry.

Dobrze wykonane odwirusowywanie PrestaShop kończy się nie tylko działającym sklepem, lecz także dokumentacją, testami i ograniczeniem ryzyka ponownego przejęcia. W PRODO realizujemy naprawy i zabezpieczenia sklepów dla firm z Poznania oraz klientów z całej Polski. Niezależnie od wybranego wykonawcy warto wymagać konkretnego zakresu prac, ochrony bieżących zamówień i mierzalnych kryteriów odbioru usługi.

Najczęściej zadawane pytania (FAQ)

Czy samo skanowanie plików wystarczy do odwirusowania PrestaShop?

Nie, złośliwy kod może znajdować się także w bazie danych, modułach, motywie lub konfiguracji środowiska. Usługa powinna obejmować usunięcie infekcji i mechanizmów dostępu, analizę możliwej drogi włamania oraz naprawę lub wyłączenie wykorzystanej podatności.

Czy podczas odwirusowywania sklep może nadal przyjmować zamówienia?

Nie zawsze można przeprowadzić naprawę bez przerwy w sprzedaży, szczególnie przy podejrzeniu przechwytywania danych płatniczych. Jeśli sklep nadal przyjmuje zamówienia, trzeba ustalić sposób zachowania nowych zapisów, aby odtworzenie starszej bazy ich nie usunęło.

Jak sprawdzić, czy odwirusowanie PrestaShop było skuteczne?

Należy wymagać raportu z wykonanych prac oraz ponownej kontroli plików, bazy danych, kont i oznak pozostawionego dostępu. Trzeba też przeprowadzić pełne zamówienie w czystej sesji klienta i sprawdzić płatność, status transakcji, e-maile, stan magazynowy oraz widoczność zamówienia w panelu. Sam brak przekierowania nie wystarcza do potwierdzenia skuteczności naprawy.

Co należy zrobić, aby ograniczyć ryzyko nawrotu infekcji?

Po czyszczeniu trzeba sprawdzić alternatywne mechanizmy dostępu oraz zaktualizować lub usunąć podatne komponenty. Należy również zmienić dane dostępowe do panelu, hostingu, FTP lub SFTP, SSH i bazy danych, a zmianę hasła bazy uwzględnić w konfiguracji sklepu. Warto usunąć nieużywane konta i ograniczyć role administracyjne do rzeczywistych obowiązków.

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 ze sklepem WooCommerce?

Możemy zdiagnozować błędy sklepu, płatności, koszyka, checkoutu, wtyczek i aktualizacji oraz przywrócić prawidłowe działanie sprzedaży.

POMOC WOOCOMMERCE

Koszyk PrestaShop znika po dodaniu produktu? Diagnostyka cookies, domeny i cache – Grafika wygenerowana przez AI.
Grafika wygenerowana przez AI.

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.

PrestaShop przestał działać po zmianie PHP? Checklista bezpiecznej naprawy sklepu

Błąd 500, biała strona lub niedziałający panel po zmianie PHP nie muszą oznaczać długiego przestoju. Zobacz, jak zabezpieczyć dane, znaleźć niezgodny moduł i sprawdzić cały proces zakupowy przed ponownym uruchomieniem sklepu.

Masz problem ze sklepem WooCommerce?

Możemy zdiagnozować błędy sklepu, płatności, koszyka, checkoutu, wtyczek i aktualizacji oraz przywrócić prawidłowe działanie sprzedaży.

POMOC WOOCOMMERCE

PrestaShop przestał działać po zmianie PHP? Checklista bezpiecznej naprawy sklepu – Grafika wygenerowana przez AI.
Grafika wygenerowana przez AI.

Zmiana wersji PHP w panelu hostingu trwa zwykle kilkanaście sekund. Jeżeli jednak sklep korzysta ze starszego modułu, zmodyfikowanego motywu albo własnych rozszerzeń, równie szybko może pojawić się błąd 500, biała strona lub niedostępny panel administracyjny. Problem nie zawsze leży w samym PrestaShop. Często ujawnia się kod, który działał w poprzednim środowisku, ale nie jest zgodny z nowym interpreterem PHP.

W takiej sytuacji najważniejsza jest kolejność działań. Chaotyczne aktualizowanie wszystkich modułów, usuwanie katalogów i przywracanie przypadkowych kopii może zwiększyć zakres awarii. Poniższa checklista pomaga ograniczyć przerwę w sprzedaży, zachować nowe zamówienia i znaleźć rzeczywistą przyczynę błędu.

Jak wygląda awaria PrestaShop po zmianie PHP?

Najbardziej oczywistym objawem jest komunikat HTTP 500 albo całkowicie pusta strona. Awaria może jednak dotyczyć tylko fragmentu sklepu. Strona główna otwiera się prawidłowo, ale problem pojawia się dopiero po przejściu do koszyka, wybraniu płatności lub zalogowaniu do panelu.

Po aktualizacji PHP warto zwrócić uwagę na następujące symptomy:

  • błąd 500 w całym sklepie lub na wybranych podstronach,
  • biała strona bez widocznego komunikatu,
  • zapętlenie przekierowań albo problemy z logowaniem do panelu,
  • brak możliwości zapisania produktu, ustawień lub statusu zamówienia,
  • niedziałający koszyk, wybór dostawy albo finalizacja zamówienia,
  • zniknięcie metod płatności lub dostawy,
  • błędy w szablonie i brak części elementów strony,
  • niewysyłanie wiadomości e-mail,
  • ostrzeżenia o braku klasy, niezgodnej deklaracji metody albo wymaganym rozszerzeniu PHP.

Zakres problemu jest ważną wskazówką. Jeśli nie działa wyłącznie płatność, podejrzenie pada przede wszystkim na moduł operatora. Gdy błąd występuje zarówno w sklepie, jak i w panelu, trzeba sprawdzić rdzeń, globalne override, zależności Composer oraz konfigurację serwera.

Dlaczego nowa wersja PHP powoduje błędy?

PHP rozwija się niezależnie od PrestaShop. Kolejne wydania mogą zaostrzać kontrolę typów, zmieniać obsługę błędów, oznaczać starsze konstrukcje jako przestarzałe lub usuwać mechanizmy, z których korzystał dawny kod. Przykładem są właściwości dynamiczne, których używanie zostało ograniczone w nowszych wydaniach PHP.

Sam rdzeń sklepu może być zgodny z wybraną wersją PHP, podczas gdy jeden z dodatkowych elementów nadal używa starszych rozwiązań. Dotyczy to zwłaszcza:

  • modułów, które od dawna nie były aktualizowane,
  • indywidualnych modyfikacji wykonanych bez dokumentacji,
  • plików override zmieniających klasy i kontrolery PrestaShop,
  • motywów nadpisujących szablony oraz zasoby modułów,
  • bibliotek znajdujących się w katalogu vendor,
  • brakujących rozszerzeń PHP, na przykład obsługi bazy danych, XML, grafiki, archiwów lub komunikacji sieciowej.

Nie należy więc wybierać najwyższej dostępnej wersji PHP tylko dlatego, że pokazuje ją hosting. Najpierw trzeba sprawdzić oficjalną tabelę zgodności dla konkretnej gałęzi PrestaShop, a następnie wymagania każdego krytycznego modułu i motywu.

Najpierw ogranicz przestój i zabezpiecz zamówienia

Jeżeli hosting pozwala natychmiast przywrócić poprzednią wersję PHP, może to być najszybszy sposób odzyskania sprzedaży. Jest to jednak rozwiązanie awaryjne, a nie końcowa naprawa. Po cofnięciu zmiany należy przygotować kopię sklepu w środowisku testowym i dopiero tam usunąć niezgodności.

Jeżeli sklep częściowo działa, nie przywracaj od razu starej bazy danych. Mogłoby to usunąć zamówienia, konta klientów i zmiany stanów magazynowych zapisane po wykonaniu kopii. Bezpieczniejszy plan wygląda następująco:

  1. zapisz aktualny stan plików oraz bazy, nawet jeśli sklep jest uszkodzony,
  2. sprawdź dokładną godzinę ostatniego poprawnego zamówienia,
  3. przywróć zgodną wersję PHP lub skieruj ruch na sprawną instancję,
  4. prowadź diagnostykę na kopii albo serwerze testowym,
  5. wdrażaj na produkcję tylko sprawdzone poprawki.

Tryb konserwacji powinien być możliwie krótki. Jeżeli awaria dotyczy jedynie panelu, a klienci nadal mogą składać zamówienia, wyłączenie całego sklepu może być niepotrzebne. Trzeba jednak potwierdzić, że koszyk, płatność i zapis zamówienia rzeczywiście działają.

Kopia plików i bazy przed rozpoczęciem naprawy

Pełna kopia PrestaShop składa się z dwóch nierozłącznych części. Pliki zawierają między innymi rdzeń, motyw, moduły, zdjęcia, konfigurację i własne modyfikacje. Baza danych przechowuje produkty, klientów, zamówienia, koszyki, ustawienia oraz powiązania między modułami.

Przed naprawą wykonaj:

  • archiwum całego katalogu sklepu,
  • eksport kompletnej bazy danych do pliku SQL,
  • kopię konfiguracji połączenia z bazą,
  • zapis bieżącej i poprzedniej wersji PHP,
  • listę aktywnych rozszerzeń PHP,
  • zrzut listy modułów wraz z ich wersjami, jeżeli panel jest dostępny.

Kopię trzeba przechowywać poza katalogiem publicznym sklepu. Sam fakt utworzenia archiwum nie daje jeszcze pewności, że da się je odtworzyć. Przy ważnym sklepie warto sprawdzić kopię na osobnej bazie i zabezpieczonej subdomenie.

Włącz debugowanie, ale nie pokazuj błędów klientom

Tryb debugowania pozwala zastąpić ogólny błąd 500 dokładniejszym komunikatem. Jeśli panel działa, można go włączyć w ustawieniach wydajności. Przy niedostępnym zapleczu w typowej instalacji robi się to w pliku config/defines.inc.php, zmieniając wartość stałej _PS_MODE_DEV_.

Debugowanie na działającym sklepie niesie jednak ryzyko ujawnienia ścieżek serwera, nazw klas i innych informacji technicznych. Najlepiej aktywować je na kopii testowej. Jeśli diagnoza musi odbyć się na produkcji, dostęp do komunikatów należy ograniczyć, na przykład do określonego adresu IP, a po zakończeniu prac natychmiast wyłączyć tryb debugowania.

Czytając komunikat, zwróć uwagę na trzy elementy: rodzaj błędu, nazwę pliku oraz numer linii. Ścieżka prowadząca do katalogu modules zwykle wskazuje konkretny moduł. Katalog motywu sugeruje problem z szablonem, a override – konflikt z własnym rozszerzeniem klasy lub kontrolera. Warto również sprawdzić logi PrestaShop, PHP-FPM oraz serwera WWW.

Sprawdź zgodność całego środowiska, nie tylko rdzenia

Diagnostykę zacznij od ustalenia pełnego zestawu wersji: PrestaShop, PHP, motywu, modułów płatności, dostawy, integracji magazynowej i systemu księgowego. Następnie porównaj je z dokumentacją producentów.

Sprawdź również konfigurację PHP. Po zmianie interpretera hosting może korzystać z innego pliku konfiguracyjnego albo osobnego zestawu rozszerzeń. W efekcie nowa wersja PHP jest aktywna, ale brakuje biblioteki potrzebnej do komunikacji z bazą, obsługi obrazów, XML, ZIP lub połączeń z zewnętrznymi API.

Jeżeli sklep korzysta z Composera, pomocne jest polecenie composer check-platform-reqs. Weryfikuje ono wymagania dotyczące PHP i rozszerzeń w środowisku, w którym polecenie zostało uruchomione. Trzeba pamiętać, że wersja PHP dostępna w terminalu może różnić się od tej używanej przez stronę przez PHP-FPM.

Naprawa modułów, override, cache i Composera

Podejrzany moduł

Jeżeli błąd wskazuje moduł, zacznij od sprawdzenia dostępnej aktualizacji oraz jej zgodności z używaną wersją PrestaShop. Nie aktualizuj od razu wszystkich dodatków. Zmienisz wtedy zbyt wiele elementów jednocześnie i utrudnisz wskazanie przyczyny.

Moduł można tymczasowo wyłączyć na kopii sklepu, a następnie powtórzyć scenariusz wywołujący błąd. Szczególnej ostrożności wymagają płatności, dostawy i integracje synchronizujące dane. Ich wyłączenie może przywrócić stronę, ale równocześnie zablokować finalizację zakupu.

Pliki override

Override ma pierwszeństwo przed standardowym zachowaniem części klas lub kontrolerów. Po zmianie PHP nieaktualny podpis metody albo przestarzała konstrukcja może zatrzymać całą aplikację. Co więcej, dwa moduły próbujące zmienić ten sam element mogą tworzyć trudny do przewidzenia konflikt.

Nie usuwaj całego katalogu override bez analizy. Najpierw ustal, który moduł lub wykonawca utworzył dany plik, wykonaj jego kopię i przeprowadź próbę na środowisku testowym. Po każdej zmianie wyczyść cache oraz indeks klas.

Cache PrestaShop

Stare pliki cache mogą odwoływać się do klas wygenerowanych przed zmianą środowiska. W nowszych instalacjach cache znajduje się zazwyczaj w katalogu var/cache. Usuń zawartość odpowiedniego środowiska, a nie przypadkowe katalogi aplikacji. Po ponownym uruchomieniu PrestaShop odtworzy potrzebne pliki.

Zależności Composer

Brak klasy lub błąd pliku platform_check.php może oznaczać niezgodność zależności z PHP albo niekompletny katalog vendor. Nie uruchamiaj pochopnie composer update na produkcji, ponieważ może ono zmienić wiele pakietów. Bezpieczniej korzystać z zatwierdzonego pliku blokady, odtworzyć zależności w zgodnym środowisku i dopiero po testach wdrożyć kompletny zestaw plików. Po naprawie można ponownie wygenerować zoptymalizowany autoloader poleceniem composer dump-autoload -o.

Testy po przywróceniu sklepu

Otwarcie strony głównej nie oznacza jeszcze, że sklep działa. Przed zakończeniem prac wykonaj pełny test zakupowy, najlepiej na produkcie fizycznym i – jeśli występują w ofercie – produkcie wirtualnym.

  • Dodaj produkt do koszyka i zmień jego liczbę.
  • Sprawdź rabaty, podatki, waluty oraz koszt dostawy.
  • Załóż nowe konto i złóż zamówienie jako gość, jeśli taka opcja jest dostępna.
  • Przetestuj każdą aktywną metodę płatności, najlepiej w trybie testowym operatora.
  • Potwierdź utworzenie zamówienia, zmianę statusu i aktualizację stanu magazynowego.
  • Sprawdź powrót klienta z bramki płatniczej oraz obsługę powiadomień serwerowych.
  • Zweryfikuj wiadomości dla klienta i administratora, reset hasła oraz formularz kontaktowy.
  • Przejrzyj nowe wpisy w logach po wykonaniu testów.

Na końcu wyłącz debugowanie, włącz docelowe mechanizmy cache i sprawdź sklep w prywatnym oknie przeglądarki oraz na urządzeniu mobilnym.

Jak uniknąć kolejnej awarii po zmianie PHP?

Aktualizacja PHP powinna być traktowana jak wdrożenie techniczne, a nie pojedyncze kliknięcie w panelu hostingu. Bezpieczny proces obejmuje kopię zapasową, klon sklepu, kontrolę zgodności, test zamówienia i przygotowaną możliwość szybkiego wycofania zmiany.

Jeżeli sklep zawiera własne modyfikacje, stare moduły albo niestandardowy proces płatności, warto zlecić wcześniejszy audyt. Profesjonalna naprawa PrestaShop nie polega na ukrywaniu komunikatu błędu. Jej celem jest usunięcie niezgodnego kodu, zabezpieczenie danych i potwierdzenie, że sprzedaż działa od dodania produktu do koszyka aż po zaksięgowanie płatności i wysłanie wiadomości.

Najczęściej zadawane pytania (FAQ)

Dlaczego PrestaShop przestał działać po zmianie wersji PHP?

Przyczyną może być niezgodność modułu, motywu, plików override lub bibliotek z nową wersją PHP. Problem mogą też powodować brakujące rozszerzenia PHP, nawet jeśli sam rdzeń PrestaShop jest zgodny z wybraną wersją.

Co zrobić najpierw, gdy sklep nie działa po zmianie PHP?

Zapisz aktualny stan plików i bazy danych oraz sprawdź godzinę ostatniego poprawnego zamówienia. Jeśli hosting na to pozwala, przywróć poprzednią wersję PHP, aby szybko odzyskać sprzedaż. Dalszą diagnostykę i naprawę prowadź na kopii testowej.

Czy przywrócenie starej bazy danych jest bezpiecznym sposobem naprawy?

Przywrócenie starej bazy może usunąć zamówienia, konta klientów i zmiany stanów magazynowych zapisane po wykonaniu kopii. Jeśli sklep częściowo działa, nie przywracaj jej od razu — najpierw zabezpiecz aktualne pliki i bazę danych.

Jak sprawdzić, czy sklep po naprawie działa prawidłowo?

Wykonaj pełny test zakupowy obejmujący koszyk, dostawę i każdą aktywną metodę płatności. Potwierdź zapis zamówienia, zmianę statusu, aktualizację stanu magazynowego oraz wysyłkę wiadomości. Przejrzyj nowe wpisy w logach, a na końcu wyłącz debugowanie i sprawdź sklep także na urządzeniu mobilnym.