Aktualizacja i bezpieczeństwo sklepu PrestaShop

Publikacja: 9 września 2026 · Grzegorz Rapczyński

Sklep bez aktualizacji nie psuje się z dnia na dzień. Psuje się powoli, a odkrywa się to zwykle w momencie, w którym klient nie może zapłacić. Ten tekst opisuje, co i jak często aktualizować w PrestaShop, jak przygotować się do dużej aktualizacji i co zrobić, żeby sklep nie stał się celem automatycznych ataków.

Dlaczego to nie jest opcjonalne

PrestaShop to oprogramowanie na Twoim serwerze. Nikt nie zaktualizuje go automatycznie, jak dzieje się to w platformach abonamentowych. W praktyce oznacza to trzy zagrożenia:

• Bezpieczeństwo. Nieaktualny sklep z nieaktualnymi modułami to najczęstszy cel automatycznych ataków. Boty nie wybierają sklepów - skanują wszystko i uderzają tam, gdzie znajdą znaną lukę.
• Zgodność. Aktualizacja PHP po stronie hostingu potrafi unieruchomić starsze moduły. Bez nadzoru dowiadujesz się o tym, gdy coś przestaje działać.
• Rosnący koszt. Im dłużej sklep stoi bez aktualizacji, tym większym projektem staje się jej wykonanie. Po dwóch latach bliżej jej do migracji niż do kliknięcia „aktualizuj”.

Włamanie do sklepu to nie tylko przestój. To także dane klientów, wpis w rejestrze bezpiecznego przeglądania Google i ostrzeżenie wyświetlane każdemu, kto próbuje wejść.

Trzy rodzaje aktualizacji

Poprawki bezpieczeństwa

Najważniejsze i najmniej ryzykowne. Wgrywa się je na bieżąco, bo dotyczą znanych publicznie luk - a publicznie znana luka jest skanowana przez boty w ciągu dni od ujawnienia.

Aktualizacje w obrębie tej samej wersji

Zwykle bezpieczne, ale nadal robione z kopią zapasową i sprawdzeniem sklepu po zakończeniu. Warto je wgrywać regularnie, żeby nie zbierać zaległości.

Przejście na nową dużą wersję

To jest projekt, nie zadanie. Zmienia się rdzeń, część modułów wymaga aktualizacji lub wymiany, szablon może wymagać poprawek. Planuje się to jak wdrożenie, z testami na kopii i wyznaczonym terminem.

Jak przygotować się do dużej aktualizacji

1. Zrób pełną kopię plików i bazy danych. Sprawdź, czy da się ją odtworzyć - kopia, której nikt nie przywrócił, to założenie, nie zabezpieczenie.
2. Postaw kopię sklepu na osobnym środowisku i tam przeprowadź aktualizację najpierw.
3. Wypisz wszystkie moduły i sprawdź zgodność każdego z docelową wersją. Te bez wsparcia autora wymagają decyzji: zamiana, dostosowanie albo rezygnacja.
4. Sprawdź szablon. Własny motyw prawie zawsze wymaga poprawek przy dużej zmianie wersji.
5. Spisz wszystkie modyfikacje w kodzie. Każda zmiana zrobiona poza modułami może zostać nadpisana.
6. Sprawdź wymagania serwera. Nowa wersja może wymagać nowszego PHP - opisałem to przy hostingu pod PrestaShop.
7. Ustal termin poza szczytem sprzedaży. Nie w listopadzie, jeśli sprzedajesz w listopadzie.

Przebieg aktualizacji

Po testach na kopii, na produkcji:

• Świeża kopia zapasowa bezpośrednio przed startem.
• Tryb serwisowy na czas prac.
• Aktualizacja rdzenia, potem modułów, potem szablonu.
• Wyczyszczenie cache i regeneracja plików.
• Pełny test: listing, karta produktu, koszyk, płatność, dostawa, e-maile transakcyjne, panel administracyjny.
• Sprawdzenie logów błędów przez kolejne dni.

Zawsze miej plan powrotu. Jeśli po godzinie od aktualizacji koszyk nie działa, przywrócenie kopii jest lepszą decyzją niż naprawianie na żywym sklepie.

Bezpieczeństwo na co dzień

Rzeczy, które nie wymagają wiedzy technicznej, a odcinają większość typowych problemów:

• Zmień domyślny adres panelu administracyjnego. Boty próbują standardowych ścieżek.
• Silne, unikalne hasła do panelu, bazy i FTP. Menedżer haseł, nie kartka.
• Osobne konta dla każdej osoby z dostępem, z uprawnieniami dopasowanymi do roli. Wspólne konto „admin” uniemożliwia ustalenie, kto co zrobił.
• Usuwaj dostępy osobom, które przestały współpracować. Najczęściej pomijany punkt na tej liście.
• Wyłącz tryb debugowania na produkcji - pokazuje ścieżki i szczegóły konfiguracji.
• Usuń pliki instalacyjne i testowe po wdrożeniu.
• Uwierzytelnianie dwuskładnikowe tam, gdzie to możliwe.
• Przeglądaj listę modułów. Nieużywany moduł to niepotrzebna powierzchnia ataku - szerzej przy tym, jakie moduły są naprawdę potrzebne.

Dwie rzeczy warto ustawić, zanim w ogóle pomyślisz o aktualizacji: kopię testową sklepu, na której robisz to pierwszy raz, oraz podstawowe zabezpieczenie panelu. Pierwsza zdejmuje ryzyko samej operacji, druga powód, dla którego aktualizacje są konieczne.

Kopie zapasowe, które faktycznie działają

Trzy pytania, na które trzeba znać odpowiedź, zanim będzie potrzebna:

1. Jak daleko wstecz sięgają? Kopia z ostatniej doby nie pomoże, jeśli problem powstał tydzień temu i nikt go nie zauważył.
2. Czy leżą poza serwerem sklepu? Kopia na tym samym serwerze ginie razem z nim.
3. Czy kiedykolwiek zostały odtworzone? To jedyny sposób, żeby wiedzieć, że działają.

Rozsądne minimum to kopia dzienna z retencją kilku tygodni, przechowywana poza serwerem, sprawdzana raz na jakiś czas przez faktyczne odtworzenie.

Najczęstszym objawem nieudanej aktualizacji albo niezgodnego modułu jest pusta strona z kodem 500. Kolejność sprawdzania opisałem osobno w tekście o błędzie 500.

Objawy, że coś jest nie tak

• Nieznane pliki w katalogach sklepu, zwłaszcza z dziwnymi nazwami.
• Konta administratorów, których nie zakładałeś.
• Przekierowania na obce strony - często widoczne tylko dla użytkowników z wyszukiwarki albo z telefonu.
• Nagły wzrost zużycia zasobów serwera bez wzrostu sprzedaży.
• Ostrzeżenie w Search Console o zagrożeniu bezpieczeństwa.
• Skargi klientów na treści, których nie widzisz. Część ataków ukrywa się przed zalogowanym administratorem.

Przy podejrzeniu włamania: najpierw zmień wszystkie hasła, potem szukaj przyczyny. Odtworzenie kopii bez zamknięcia luki kończy się powtórką za kilka dni.

Sklep zaniedbany od lat

Jeśli sklep stoi na bardzo starej wersji, aktualizacja bywa większym projektem niż zwykła opieka. Realistycznie masz trzy drogi:

• Aktualizacja etapami - wolniej, bezpieczniej, więcej pracy.
• Przeniesienie na czystą instalację z importem danych. Czasem tańsze niż walka ze starym sklepem - bliżej temu do migracji niż do aktualizacji.
• Zostawienie jak jest - tylko jeśli sklep ma być wygaszony. W każdym innym przypadku to odkładanie rachunku, który rośnie.

Decyzję podejmuje się po przeglądzie: wersja sklepu, lista modułów, stan szablonu, wymagania serwera.

Przed każdą większą aktualizacją warto zabezpieczyć jedną rzecz, o której łatwo zapomnieć: własne szablony maili. Aktualizacja nadpisuje je wersją domyślną i dowiadujesz się o tym zwykle od klienta.

Te same zasady dotyczą zwykłych stron firmowych. Co obejmuje stała opieka nad stroną internetową i czym różni się od hostingu, rozpisałem osobno.

Najczęstsze pytania

Jak często aktualizować PrestaShop?

Poprawki bezpieczeństwa na bieżąco. Aktualizacje w obrębie wersji regularnie, z kopią zapasową. Duże wersje jako zaplanowany projekt, nie przy okazji.

Czy aktualizacja może zepsuć sklep?

Może, dlatego robi się ją najpierw na kopii, z pełną kopią zapasową i planem powrotu. Ryzyko rośnie z liczbą modułów i stopniem modyfikacji szablonu.

Co jeśli moduł nie jest zgodny z nową wersją?

Trzy opcje: poczekać na aktualizację od autora, zastąpić go innym albo dostosować samodzielnie. Przy module porzuconym zostaje druga lub trzecia.

Czy hosting nie dba o bezpieczeństwo sklepu?

Hosting dba o serwer, nie o Twoją aplikację. Aktualizacje PrestaShop i modułów są po Twojej stronie.

Ile kosztuje utrzymanie sklepu w aktualnym stanie?

Zależy od wielkości sklepu i liczby modułów, ale zawsze mniej niż nadrobienie dwóch lat zaległości naraz. Zakres opisałem przy opiece nad sklepem.

Czytaj też: po zmianie hostingu albo aktualizacji potrafią przestać docierać wiadomości ze sklepu. Co wtedy sprawdzić, opisałem w tekście o mailach ze sklepu w spamie.

Sprawdzę stan Twojego sklepu

Przegląd to wersja PrestaShop, lista modułów, stan kopii zapasowych, błędy w logach i wymagania serwera - a na koniec lista tego, co wymaga uwagi w pierwszej kolejności. Napisz przez formularz kontaktowy, jeśli chcesz wiedzieć, na czym stoisz.