Archiwa PrestaShop

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 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.

Programista PrestaShop czy agencja w Poznaniu – jak wybrać wykonawcę sklepu internetowego?

Freelancer i agencja mogą skutecznie wdrożyć sklep PrestaShop, ale różnią się organizacją pracy, dostępnością i zakresem kompetencji. Sprawdź, jak porównać doświadczenie, wyceny, umowy oraz wsparcie techniczne wykonawców z Poznania i całej Polski.

Wybór wykonawcy sklepu internetowego nie powinien sprowadzać się do prostego pytania: freelancer czy agencja? Doświadczony programista PrestaShop może sprawnie zrealizować rozbudowane wdrożenie, a firma przedstawiająca się jako agencja nie zawsze dysponuje wszystkimi potrzebnymi kompetencjami wewnątrz organizacji. Może być też odwrotnie: przy projekcie wymagającym grafiki, migracji danych, integracji i testów jeden specjalista nie zapewni odpowiedniej dostępności.

Znacznie lepiej porównać konkretne osoby, zakres odpowiedzialności, sposób prowadzenia projektu oraz warunki późniejszej opieki. Lokalizacja w Poznaniu może ułatwić warsztaty i szkolenia, ale sama w sobie nie stanowi potwierdzenia jakości. Poniższe kryteria pozwolą ocenić oferty według tego, co faktycznie otrzyma przedsiębiorca.

Freelancer i agencja PrestaShop – na czym polega różnica?

Freelancer zwykle sam prowadzi analizę, programuje sklep, kontaktuje się z klientem i rozwiązuje problemy techniczne. Zaletą takiego modelu bywa bezpośrednia komunikacja z osobą wykonującą prace. Decyzje nie muszą przechodzić przez kilku opiekunów, a wykonawca dobrze zna kod i historię projektu.

Trzeba jednak sprawdzić, co stanie się podczas jego urlopu, choroby lub równoległej realizacji większego zlecenia. Deklaracja stałej dostępności nie zastępuje procedury zastępstwa ani określonych godzin przyjmowania zgłoszeń. Szczególne znaczenie ma to po uruchomieniu sklepu, gdy awaria płatności albo procesu zamówienia wymaga szybkiej diagnozy.

Agencja może przydzielić do projektu kilka osób: programistę, projektanta interfejsu, specjalistę od integracji, testera i opiekuna projektu. Nie należy jednak zakładać, że każdy taki zespół rzeczywiście istnieje. Warto zapytać, kto konkretnie będzie pracował nad sklepem, które zadania zostaną przekazane podwykonawcom i z kim klient będzie omawiał kwestie techniczne.

Najważniejsza różnica dotyczy więc nie nazwy wykonawcy, lecz organizacji odpowiedzialności. Zarówno freelancer, jak i agencja powinni jasno wskazać osobę prowadzącą projekt, specjalistów realizujących poszczególne obszary oraz sposób postępowania w razie nieobecności członka zespołu.

Kiedy wystarczy jeden programista PrestaShop?

Jeden specjalista może być dobrym wyborem, gdy projekt ma ograniczony i dobrze opisany zakres. Przykładem jest uruchomienie sklepu na gotowym motywie, skonfigurowanie typowych metod płatności i dostawy, import uporządkowanego katalogu produktów czy wprowadzenie niewielkich zmian w wyglądzie. Warunkiem jest potwierdzenie, że wykonawca zna wszystkie obszary potrzebne do realizacji.

Zaangażowanie szerszego zespołu warto rozważyć, jeśli sklep wymaga:

indywidualnego projektu graficznego i przemyślanej ścieżki zakupowej,
migracji klientów, produktów, zamówień i adresów URL ze starego systemu,
integracji z ERP, CRM, magazynem, hurtowniami lub platformami sprzedażowymi,
niestandardowych reguł cenowych, podatkowych albo logistycznych,
równoległego prowadzenia prac projektowych, programistycznych i testów,
ściśle określonego terminu uruchomienia oraz zapewnionych zastępstw.

Zespołu nie musi zapewniać wyłącznie agencja. Freelancer może stale współpracować z grafikiem i innymi programistami. Klient powinien jednak wiedzieć, kto odpowiada za rezultat całego wdrożenia, a nie tylko za własny fragment prac.

Jak zweryfikować doświadczenie wykonawcy?

Portfolio warto analizować pod kątem podobieństwa do planowanego sklepu. Duża liczba miniaturek nie mówi jeszcze, czy kandydat projektował prezentowane serwisy, programował je od podstaw, wdrażał gotowy motyw, tworzył pojedynczy moduł czy jedynie przejął późniejszą obsługę techniczną.

Wybierz dwie lub trzy zbliżone realizacje i zapytaj o datę prac, zakres odpowiedzialności, zastosowane moduły, wykonane integracje oraz najtrudniejsze problemy. W przypadku rozbudowanego projektu przydatna będzie rozmowa z osobą techniczną, a za zgodą wcześniejszego klienta także potwierdzenie referencji.

Oficjalny katalog ekspertów PrestaShop pozwala sprawdzać agencje oraz deklarowane specjalizacje, takie jak tworzenie sklepów, migracje, integracje, optymalizacja czy utrzymanie. Obecność w katalogu może być dodatkowym punktem kontrolnym, lecz nie zastępuje weryfikacji zespołu przydzielonego do konkretnego zlecenia.

Podczas rozmowy technicznej można też zapytać o sposób tworzenia modyfikacji. Dokumentacja PrestaShop zwraca uwagę, że nadpisania klas i kontrolerów, określane jako overrides, mogą powodować konflikty między modułami. Nie oznacza to, że każde ich zastosowanie jest błędem. Dobry wykonawca powinien jednak umieć uzasadnić decyzję, wskazać alternatywy, opisać testy oraz udokumentować zmianę z myślą o przyszłych aktualizacjach.

Jak porównywać ceny wykonania sklepu?

Dwie wyceny opiewające na różne kwoty mogą dotyczyć zupełnie innego zakresu. Jedna obejmie projekt graficzny, import danych, testy i szkolenie, a druga wyłącznie instalację systemu oraz konfigurację motywu. Dlatego nie należy porównywać samej wartości końcowej.

Poproś o rozbicie oferty przynajmniej na analizę, grafikę, wdrożenie, import produktów, integracje, testy, szkolenie, uruchomienie, hosting i opiekę powdrożeniową. Osobno powinny zostać pokazane koszty modułów, motywów, licencji i ich późniejszych odnowień. Przy każdej pozycji warto wskazać, czy jest jednorazowa, cykliczna, czy rozliczana według czasu pracy.

W przypadku integracji opis powinien określać, jakie dane będą synchronizowane, w którym kierunku i jak często. Trzeba również ustalić, kto diagnozuje sytuację, gdy błąd może leżeć po stronie sklepu, modułu, zewnętrznego API albo systemu magazynowego.

Zakup dodatku z usługą Business Care nie jest równoznaczny z pełną obsługą techniczną sklepu. Mechanizm ten zapewnia przez określony okres dostęp do aktualizacji i pomocy dotyczącej danego produktu, ale nie obejmuje indywidualnego programowania. Modyfikacja kodu modułu lub motywu może również wpływać na zakres wsparcia jego producenta. Oferta wdrożeniowa powinna zatem oddzielać cenę dodatku, koszt odnowienia oraz wynagrodzenie za instalację, konfigurację i rozwiązywanie konfliktów.

Jak powinna wyglądać współpraca podczas wdrożenia?

Niezależnie od tego, czy wybierzesz programistę PrestaShop, czy agencję, ustal harmonogram podzielony na mierzalne etapy. Zamiast informacji, że projekt jest ukończony w 70 procentach, lepiej otrzymać dostęp do wersji demonstracyjnej i zobaczyć działające elementy: katalog, koszyk, płatność, wysyłkę lub integrację.

Przed rozpoczęciem prac uzgodnij częstotliwość prezentacji, sposób zgłaszania uwag, narzędzie do śledzenia zadań oraz osobę uprawnioną do podejmowania decyzji po obu stronach. Regularne demonstracje ograniczają ryzyko, że rozbieżności zostaną odkryte dopiero przed uruchomieniem.

Dla firmy z Poznania lokalny wykonawca może być wygodny, jeśli projekt wymaga warsztatów na miejscu, szkolenia pracowników lub spotkania odbiorowego. W ofercie warto jednak doprecyzować, ile takich spotkań obejmuje cena i czy uczestniczy w nich programista, czy wyłącznie handlowiec. Przy dobrze zorganizowanej komunikacji wiele wdrożeń może być skutecznie prowadzonych zdalnie, dlatego lokalność należy traktować jako korzyść organizacyjną, a nie gwarancję kompetencji.

Umowa, odbiór sklepu i dostęp do infrastruktury

Umowa powinna opisywać rezultat, a nie tylko ogólne wykonanie sklepu internetowego. Załącznik funkcjonalny może wskazywać obsługiwane płatności, metody dostawy, typy produktów, zasady importu, integracje oraz wspierane scenariusze zakupowe. Do każdego etapu należy przypisać kryteria akceptacji i termin na zgłoszenie uwag.

Przed odbiorem warto przetestować między innymi zakup na telefonie, poprawną i odrzuconą płatność, naliczanie dostawy, wiadomości e-mail, warianty produktów, kupony oraz przekazywanie zamówień do systemów zewnętrznych. Konkretna lista zależy od funkcji sklepu i powinna powstać przed końcem projektu.

Dokumenty muszą również regulować rozliczanie zmian wykraczających poza pierwotny zakres. Dobrą praktyką jest przedstawienie wpływu zmiany na cenę i termin przed rozpoczęciem dodatkowych prac.

Klient powinien otrzymać dostęp administracyjny do sklepu, hostingu, domeny, kopii zapasowych, kont integracyjnych i licencji kupionych na jego rzecz. Trzeba też oddzielić prawa do indywidualnie przygotowanego kodu i grafiki od zasad korzystania z platformy oraz zewnętrznych modułów. Rdzeń PrestaShop i jego elementy są udostępniane na określonych licencjach, a komercyjne dodatki mogą mieć własne warunki. Określenie sklep na własność nie oznacza więc automatycznie wyłącznych praw do całego użytego oprogramowania.

Wsparcie po uruchomieniu sklepu

Uruchomienie sprzedaży nie kończy prac technicznych. Sklep wymaga monitorowania, kopii zapasowych, aktualizacji, reagowania na błędy oraz dostosowywania integracji do zmian po stronie zewnętrznych usług.

Porównując warunki opieki, sprawdź czas pierwszej reakcji, godziny obsługi, kanał zgłoszeń, sposób kwalifikowania awarii i przewidywany tryb rozwiązania problemu. Czas reakcji nie jest tym samym co czas naprawy. Warto też ustalić, co obejmuje gwarancja na wykonane prace, a co będzie płatnym rozwojem lub interwencją wynikającą ze zmiany zewnętrznego systemu.

Jeżeli dostępność ma kluczowe znaczenie, uzgodnienia powinny być mierzalne. SLA może określać zakres usług, odpowiedzialność stron, godziny świadczenia pomocy oraz zasady postępowania w razie niedotrzymania parametrów. Nawet prostszy pakiet opieki powinien jasno odpowiadać na pytanie, kto zajmie się pilnym zgłoszeniem i w jakim czasie je podejmie.

Programista czy agencja – ostateczna decyzja

Freelancer będzie rozsądnym wyborem, gdy zakres jest jasno zdefiniowany, projekt nie wymaga wielu równoległych specjalizacji, a wykonawca zapewnia odpowiednią dostępność. Agencja może lepiej pasować do przedsięwzięcia obejmującego indywidualną grafikę, liczne integracje, migrację i długoterminowe utrzymanie, o ile rzeczywiście przydzieli do niego kompetentny zespół.

Przed podpisaniem umowy porównaj nie tylko cenę, ale również skład zespołu, podobne realizacje, kompletność wyceny, sposób kontroli postępów, kryteria odbioru i warunki wsparcia. W przypadku wykonawcy z Poznania oceń dodatkowo realną dostępność spotkań oraz udział osoby technicznej. Najlepszym partnerem nie jest automatycznie największa agencja ani najtańszy programista, lecz ten, który potrafi przełożyć potrzeby firmy na sprawdzalny zakres, bezpieczne wdrożenie i przewidywalną opiekę nad sklepem.

Najczęściej zadawane pytania (FAQ)

Kiedy wybrać jednego programistę PrestaShop, a kiedy agencję?

Jeden programista może wystarczyć przy jasno opisanym zakresie, np. sklepie na gotowym motywie z typowymi płatnościami i dostawą. Szerszy zespół warto rozważyć przy indywidualnej grafice, migracji, licznych integracjach i równoległych pracach. Trzeba jednak sprawdzić rzeczywiste kompetencje, dostępność i podział odpowiedzialności wykonawców.

Czy warto wybrać wykonawcę sklepu z Poznania?

Lokalny wykonawca może ułatwić organizację warsztatów, szkoleń i spotkań odbiorowych, ale lokalizacja nie gwarantuje jakości. Warto ustalić, ile spotkań obejmuje cena i czy uczestniczy w nich osoba techniczna. Przy dobrze zorganizowanej komunikacji wiele wdrożeń można skutecznie prowadzić zdalnie.

Jak porównać wyceny wykonania sklepu PrestaShop?

Porównuj zakres prac, a nie tylko końcową kwotę. Poproś o rozbicie kosztów na analizę, grafikę, wdrożenie, import danych, integracje, testy, szkolenie, uruchomienie, hosting i opiekę. Osobno sprawdź ceny modułów, motywów, licencji i odnowień oraz to, które opłaty są jednorazowe, cykliczne lub zależne od czasu pracy.

Co ustalić w sprawie wsparcia po uruchomieniu sklepu?

Ustal godziny obsługi, kanał zgłoszeń, czas pierwszej reakcji, sposób kwalifikowania awarii i tryb rozwiązywania problemów. Czas reakcji nie jest tym samym co czas naprawy. Sprawdź też zakres gwarancji, zasady płatnych interwencji oraz to, kto podejmie pilne zgłoszenie podczas nieobecności wykonawcy.

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

Zapisz stan początkowy. Zanotuj objawy, godziny testów i ostatnie zmiany w sklepie.
Wykonaj kopię plików i bazy danych. Upewnij się, że backup można odtworzyć, a nie tylko pobrać.
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.
Utwórz środowisko testowe. Ogranicz wysyłkę wiadomości i połączenia z produkcyjnymi płatnościami.
Sprawdź domenę, HTTPS i cookies. Napraw podstawową ciągłość identyfikacji przed zmianami w modułach.
Wyłącz cache stron dynamicznych. Wyczyść właściwe warstwy pamięci podręcznej i ponów test.
Testuj moduły pojedynczo. Po każdej zmianie wykonuj ten sam scenariusz zakupowy.
Przenieś tylko potwierdzoną poprawkę. Nie wdrażaj na produkcji całego zestawu eksperymentalnych zmian.
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:

zapisz aktualny stan plików oraz bazy, nawet jeśli sklep jest uszkodzony,
sprawdź dokładną godzinę ostatniego poprawnego zamówienia,
przywróć zgodną wersję PHP lub skieruj ruch na sprawną instancję,
prowadź diagnostykę na kopii albo serwerze testowym,
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.

Migracja sklepu z PrestaShop do WooCommerce bez utraty zamówień i widoczności w Google

Przeniesienie sklepu z PrestaShop do WooCommerce może uprościć rozwój serwisu, ale wymaga czegoś więcej niż skopiowania produktów. Wyjaśniamy, jak zaplanować migrację danych, integracji i adresów URL, aby ograniczyć ryzyko utraty zamówień, klientów oraz ruchu z Google.

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

Migracja sklepu z PrestaShop do WooCommerce bez utraty zamówień i widoczności w Google – Grafika wygenerowana przez AI. — Grafika wygenerowana przez AI.

Migracja sklepu internetowego nie polega na zainstalowaniu WooCommerce, zaimportowaniu katalogu i zmianie domeny wskazującej na nowy serwer. W działającym e-commerce trzeba zachować ciągłość sprzedaży, historię klientów, poprawne stany magazynowe, integracje oraz adresy, pod którymi Google i użytkownicy znają poszczególne produkty.

Przejście z PrestaShop do WooCommerce może być dobrą decyzją, szczególnie gdy sklep ma zostać mocniej połączony z rozbudowaną stroną firmową opartą na WordPressie. Nie jest jednak uniwersalnym lekarstwem na problemy techniczne. O powodzeniu projektu decydują audyt, sposób mapowania danych i dobrze zaplanowany moment uruchomienia nowego systemu.

Kiedy przeniesienie sklepu z PrestaShop do WooCommerce ma sens?

Sama niechęć do obecnego panelu nie jest wystarczającym powodem do migracji. Zmiana platformy oznacza koszt wdrożenia, ponowną konfigurację procesów i okres wzmożonej kontroli po uruchomieniu. Powinna więc odpowiadać na konkretny problem biznesowy lub techniczny.

Migrację warto rozważyć, gdy:

firma korzysta już z WordPressa i chce zarządzać stroną, blogiem, landing page’ami oraz sprzedażą w jednym środowisku;
rozwój obecnego sklepu wymaga coraz większej liczby trudnych do utrzymania modyfikacji;
używane moduły PrestaShop są niekompatybilne, porzucone lub blokują aktualizację środowiska;
publikowanie treści poradnikowych i tworzenie rozbudowanych podstron jest ważną częścią strategii SEO;
planowane integracje są dostępne lub łatwiejsze do wdrożenia w WooCommerce;
zespół zna WordPressa i chce ograniczyć liczbę osobnych paneli administracyjnych.

Z kolei poprawnie działającego, szybkiego sklepu PrestaShop nie należy przenosić wyłącznie dlatego, że WooCommerce wydaje się prostszy. Jeśli sklep obsługuje nietypowe reguły cenowe, rozbudowany multistore, konfiguratory albo mocno zmodyfikowany proces zamówienia, najpierw trzeba sprawdzić, czy ich odtworzenie będzie ekonomicznie uzasadnione.

Jakie dane można przenieść do WooCommerce?

Zakres migracji powinien powstać przed wyborem narzędzia. Eksport CSV może wystarczyć dla prostego katalogu, ale przy wieloletnim sklepie z tysiącami zamówień zwykle potrzebne jest mapowanie baz danych, wykorzystanie interfejsów API albo dedykowany skrypt.

Najczęściej przenosi się:

kategorie, produkty, opisy, ceny, numery SKU i stany magazynowe;
atrybuty oraz warianty, na przykład rozmiary, kolory i przypisane do nich ceny;
zdjęcia główne, galerie oraz powiązania plików z produktami;
konta klientów, adresy rozliczeniowe i adresy dostawy;
zamówienia wraz z datami, pozycjami, kwotami, podatkami i statusami;
opinie produktowe, oceny i informacje o ich autorach;
kody rabatowe oraz wybrane dane dodatkowe używane przez moduły.

Nie każda informacja ma bezpośredni odpowiednik w nowym systemie. PrestaShop i WooCommerce inaczej przechowują część danych, dlatego nie wystarczy porównać liczby rekordów. Trzeba również sprawdzić relacje: czy wariant jest przypisany do właściwego produktu, zdjęcie do odpowiedniej wersji, a zamówienie do klienta.

Osobnej decyzji wymagają hasła klientów. Nie należy zakładać, że będzie można przenieść je bez zmian. Zależy to od zastosowanej metody migracji i sposobu uwierzytelniania. Jeśli zachowanie logowania nie jest bezpiecznie możliwe, należy przygotować procedurę ustawienia nowego hasła oraz czytelną komunikację dla klientów.

Audyt przed migracją: nie tylko produkty i zamówienia

Dobry audyt zaczyna się od kopii bazy danych i plików starego sklepu. Następnie powstaje spis elementów, które wpływają na sprzedaż. Dotyczy to zarówno widocznych funkcji, jak i procesów wykonywanych automatycznie w tle.

Warto zinwentaryzować moduły płatności, dostawy, fakturowania, księgowości, integracje z ERP, systemem magazynowym, porównywarkami cen, marketplace’ami, newsletterem oraz narzędziami analitycznymi. Każdy element powinien otrzymać jeden z trzech statusów: do odtworzenia, do zastąpienia albo do usunięcia.

Audyt techniczny powinien objąć również wersję PrestaShop, PHP i bazy danych, konfigurację serwera, zadania cykliczne, wielkość katalogu oraz niestandardowe tabele tworzone przez moduły. Nowe środowisko należy porównać z aktualnymi wymaganiami WordPressa, WooCommerce i wszystkich wybranych rozszerzeń. Nie powinno się dobierać wersji PHP wyłącznie na podstawie tego, co działało na starym serwerze.

To także właściwy moment na kontrolę bezpieczeństwa. Jeżeli stary sklep był zainfekowany, bezrefleksyjne kopiowanie plików, skryptów śledzących czy zawartości opisów może przenieść szkodliwy kod do nowej witryny. Przed migracją warto więc przeprowadzić skan bazy i plików oraz wyjaśnić nietypowe przekierowania, konta administratorów i modyfikacje szablonu.

Adresy URL i przekierowania 301: najważniejszy etap dla SEO

Zmiana silnika sklepu często powoduje zmianę struktury adresów. Produkt dostępny wcześniej pod adresem zawierającym identyfikator i kategorię może w WooCommerce otrzymać znacznie krótszy URL. Dla Google są to jednak dwa różne adresy, nawet jeśli prezentują identyczny produkt.

Przed wdrożeniem należy zebrać wszystkie wartościowe adresy starego sklepu. Źródłem mogą być mapa witryny, eksport z narzędzia indeksującego, dane Google Search Console, system analityczny, raport linków zewnętrznych i baza produktów. Następnie tworzy się mapę wskazującą dokładny nowy odpowiednik każdego starego URL-a.

Przekierowania 301 powinny prowadzić możliwie bezpośrednio:

stary produkt → ten sam produkt w WooCommerce;
stara kategoria → odpowiadająca jej nowa kategoria;
wycofany produkt → bliski następca lub właściwa kategoria, jeśli taki odpowiednik rzeczywiście istnieje;
ważny poradnik → jego nowa wersja w WordPressie.

Nie należy kierować wszystkich nieistniejących stron na stronę główną. Takie przekierowanie jest mało użyteczne dla klienta i może zostać potraktowane przez wyszukiwarkę jak pozorny błąd 404. Trzeba też unikać łańcuchów, w których stary adres prowadzi przez kilka kolejnych przekierowań.

Po publikacji należy sprawdzić kody odpowiedzi, linkowanie wewnętrzne, adresy kanoniczne, dyrektywy indeksowania oraz nową mapę XML. Google zaleca utrzymywanie przekierowań po migracji co najmniej przez rok, a z punktu widzenia użytkowników często warto pozostawić je znacznie dłużej.

Płatności, dostawy, faktury i magazyn trzeba skonfigurować od nowa

Przeniesienie historii zamówień nie oznacza automatycznego przeniesienia działających integracji. Bramki płatnicze wymagają instalacji odpowiednich rozszerzeń, wprowadzenia danych dostępowych, konfiguracji powiadomień zwrotnych i wykonania transakcji testowych. Trzeba sprawdzić nie tylko płatność zakończoną sukcesem, ale również jej anulowanie, odrzucenie oraz zwrot.

W WooCommerce metody dostawy są przypisywane do stref. Należy odtworzyć obsługiwane kraje, regiony i kody pocztowe, progi darmowej przesyłki, dopłaty oraz ograniczenia dotyczące gabarytów. Test powinien objąć kilka różnych adresów, ponieważ jedna poprawna przesyłka nie potwierdza działania wszystkich reguł.

Integracja fakturowa musi zachować poprawny obieg dokumentów, ale historycznych faktur nie należy generować ponownie bez analizy konsekwencji księgowych. Często lepszym rozwiązaniem jest pozostawienie bezpiecznego archiwum starego systemu lub zaimportowanie numerów i odnośników do dokumentów w trybie informacyjnym.

Kluczowa jest też odpowiedź na pytanie, który system stanowi główne źródło stanów magazynowych. Jeśli zapasami zarządza ERP, WooCommerce powinien otrzymywać dane właśnie z niego. Równoległe aktualizowanie stanów w dwóch sklepach podczas migracji może doprowadzić do sprzedaży produktu, którego faktycznie już nie ma.

Testy nowego sklepu przed publikacją

Nowy sklep powinien działać na środowisku testowym, niedostępnym dla przypadkowych użytkowników i wyszukiwarek. Testowanie wyłącznie przez administratora jest niewystarczające. Należy przejść pełną ścieżkę klienta, najlepiej na kilku urządzeniach i przy różnych scenariuszach koszyka.

Lista kontrolna powinna obejmować:

wyszukiwanie, filtry, warianty i prezentację dostępności;
dodawanie, zmianę liczby i usuwanie produktów z koszyka;
zakupy z kontem oraz bez rejestracji;
kupony, podatki, koszty dostawy i próg darmowej przesyłki;
płatności testowe oraz właściwe zmiany statusów zamówienia;
zmniejszanie i przywracanie stanów magazynowych;
wiadomości e-mail wysyłane do klienta i obsługi sklepu;
faktury, etykiety przewozowe i przekazywanie danych do zewnętrznych systemów;
działanie na telefonach, tabletach i popularnych przeglądarkach.

Warto również skontrolować sposób przechowywania zamówień w WooCommerce i zgodność używanych rozszerzeń z aktualnym mechanizmem HPOS. Wtyczka może poprawnie wyświetlać ustawienia, a jednocześnie nie obsługiwać prawidłowo danych zamówień, dlatego test musi kończyć się w systemie magazynowym, księgowym lub kurierskim, a nie na stronie podziękowania.

Jak uruchomić WooCommerce bez utraty nowych zamówień?

Największe ryzyko pojawia się między wykonaniem pierwszej kopii danych a przełączeniem sklepu. W tym czasie klienci nadal kupują w PrestaShop, więc w nowym systemie brakuje najnowszych zamówień, zmian stanów oraz nowych kont.

Bezpieczny proces można podzielić na kilka etapów:

Wykonanie pełnej migracji próbnej na środowisko testowe.
Porównanie liczby i jakości przeniesionych rekordów.
Poprawienie skryptów oraz ponowne przetestowanie integracji.
Ustalenie momentu granicznego i wykonanie migracji różnicowej obejmującej nowe dane.
Krótkie zablokowanie możliwości składania zamówień, jeśli synchronizacja w czasie rzeczywistym nie jest dostępna.
Przełączenie domeny lub konfiguracji serwera na WooCommerce.
Wykonanie zamówienia kontrolnego już w środowisku produkcyjnym.
Monitorowanie błędów, płatności, wiadomości i indeksowania po publikacji.

Najlepiej przeprowadzić przełączenie w okresie najmniejszego ruchu, ale nie powinien to być moment, w którym zespół techniczny i pracownicy sklepu są niedostępni. Stara instalacja powinna pozostać zabezpieczona jako archiwum, bez możliwości przyjmowania nowych zamówień i bez publicznego indeksowania.

Migracja to projekt biznesowy, nie jednorazowy import

Udane przejście z PrestaShop do WooCommerce wymaga połączenia prac programistycznych, administracji serwerem, SEO i znajomości codziennej obsługi sklepu. Najwięcej problemów nie wynika z samego kopiowania produktów, lecz z pominiętych zależności: numeracji zamówień, reguł dostawy, integracji magazynowej, wiadomości e-mail albo starych adresów URL.

Firma realizująca tworzenie sklepów WooCommerce lub modernizację stron WordPress powinna rozpocząć pracę od audytu, a nie od wyboru szablonu. Dotyczy to zarówno dużych wdrożeń, jak i lokalnych projektów, na przykład dla firm z Poznania. Dopiero po poznaniu danych i procesów można ocenić, czy migracja rzeczywiście uprości rozwój sklepu oraz ile czasu potrzeba na jej bezpieczne wykonanie.

Najczęściej zadawane pytania (FAQ)

Jakie dane można przenieść z PrestaShop do WooCommerce?

Najczęściej przenosi się produkty, kategorie, warianty, zdjęcia, ceny, stany magazynowe, konta klientów i historię zamówień. Migracja może objąć także opinie, kody rabatowe i wybrane dane dodatkowe modułów. Możliwość zachowania haseł klientów zależy od metody migracji i sposobu uwierzytelniania.

Jak ograniczyć ryzyko utraty widoczności w Google po migracji?

Przed wdrożeniem trzeba zebrać wartościowe stare adresy URL i przygotować przekierowania 301 do ich dokładnych nowych odpowiedników. Nie należy kierować wszystkich usuniętych stron na stronę główną ani tworzyć łańcuchów przekierowań. Po publikacji trzeba sprawdzić kody odpowiedzi, linkowanie wewnętrzne, adresy kanoniczne, dyrektywy indeksowania i mapę XML.

Jak uniknąć utraty zamówień składanych w trakcie migracji?

Po migracji próbnej należy ustalić moment graniczny i wykonać migrację różnicową obejmującą nowe dane. Jeśli synchronizacja w czasie rzeczywistym nie jest dostępna, trzeba na krótko zablokować składanie zamówień. Po przełączeniu na WooCommerce należy wykonać zamówienie kontrolne i monitorować działanie sklepu.

Czy integracje płatności, dostaw i fakturowania przeniosą się razem z zamówieniami?

Nie, przeniesienie historii zamówień nie oznacza automatycznego przeniesienia działających integracji. Płatności, dostawy, fakturowanie i magazyn trzeba skonfigurować od nowa oraz przetestować. Historycznych faktur nie należy generować ponownie bez analizy konsekwencji księgowych.