Ten tekst opisuje, jak ten dług powstaje, po czym go poznać u siebie, ile godzin miesięcznie zjada sklep na PrestaShop i jak wygląda opieka, która długu nie pogłębia. Nie zamierzamy straszyć końcem świata na starych wersjach. Zamierzamy pokazać rachunek.
Krajobraz wersji, bez straszenia
Trzy fakty wystarczą, żeby ustawić sobie mapę. PrestaShop 8 wyszedł w październiku 2022 i wymaga PHP 8.1. PrestaShop 9 wyszedł w czerwcu 2025: Symfony 6.4, obsługa PHP do 8.4, nowe API administracyjne, nowy motyw. PrestaShop 9.1 wyszedł w kwietniu 2026. Wersje 1.6 i 1.7 są historyczne.
Nie podamy Ci daty końca wsparcia dla 1.7, bo nie mamy jej zweryfikowanej i nie zamierzamy jej zmyślać. Podamy coś praktyczniejszego: sklep na 1.7 stoi na wersji nierozwijanej, a płatne moduły przestają dostawać dla niej aktualizacje. To drugie boli szybciej niż pierwsze. Dostawca modułu płatności czy modułu przewoźnika wypuszcza nową wersję zgodną z PrestaShop 8 i 9, a dla 1.7 zostawia ostatnie wydanie sprzed lat. Dopóki nic po stronie dostawcy się nie zmienia, działa. Kiedy dostawca zmienia API, kończy się w jeden dzień.
Sprawdź to sam, zajmuje kwadrans: w panelu odczytaj wersję PrestaShop i wersję PHP, a potem otwórz listę modułów i policz, ile z nich ma ostatnią aktualizację starszą niż dwa lata. Ta liczba jest lepszym wskaźnikiem ryzyka niż sam numer wersji sklepu.
Dlaczego sklep zostaje na starej wersji
Rzadko chodzi o rdzeń. Rdzeń podnosi się relatywnie przewidywalnie. Sklep zostaje, bo zostają moduły i motyw.
Typowy sklep po kilku latach ma od 30 do 60 modułów, z czego kilkanaście to moduły płatne, dwa lub trzy pisane na zamówienie, a reszta to rzeczy dołożone przy okazji kampanii i nigdy nie wyłączone. Motyw jest kupiony i modyfikowany, często z nadpisanymi szablonami rdzenia. W momencie, gdy pojawia się pytanie o podniesienie wersji, ktoś musi odpowiedzieć na jedno konkretne pytanie dla każdej z tych pozycji: czy istnieje odpowiednik zgodny z wersją docelową, a jeżeli nie, to co dalej. Zwykle kończy się tak, że dla większości odpowiedź jest łatwa, a dla trzech pozycji brzmi "nie ma, trzeba napisać". I na tych trzech projekt staje.
Mechanizm jest nieprzyjemny, bo działa w jedną stronę. Im dłużej stoisz, tym drożej ruszasz. Sklep na PrestaShop 8, który podnosi się do 9, robi jeden skok: motyw i moduły idą przez jedną zmianę dużej wersji. Sklep na 1.7 robi skok przez dwie duże wersje naraz, więc zmiany z obu gałęzi kumulują się w jednym projekcie, a testy trzeba przeprowadzić na wszystkim naraz. Do tego dochodzi PHP: przeskok wersji języka potrafi wyłożyć starsze moduły niezależnie od samego PrestaShop. Odkładanie decyzji nie jest neutralne. To jest zaciąganie kredytu z rosnącym oprocentowaniem.
Co realnie psuje sklepy na PrestaShop
Poniżej pięć rzeczy, które w naszej praktyce najczęściej kończą się zgłoszeniem. Przy każdej podajemy rząd wielkości czasu potrzebnego na przywrócenie działania. To jest obserwacja z pracy, nie zobowiązanie umowne: gwarantujemy czas reakcji, nie czas naprawy.
Konflikt modułów po nadpisaniu tych samych plików. Objaw: po włączeniu nowego modułu znika przycisk w koszyku albo psuje się wyświetlanie cen. Przyczyna: dwa moduły nadpisują ten sam szablon albo tę samą klasę przez override, wygrywa ten wczytany później. Rząd wielkości: od 1 do 4 godzin, jeżeli wiadomo, co i kiedy zostało wgrane.
Wydajność przy dużym katalogu. Objaw: lista produktów i wyszukiwarka mielą po kilka sekund, panel administracyjny staje przy edycji produktu. Przyczyna: duża liczba kombinacji produktów i atrybutów, brakujące albo nieprzebudowane indeksy, wyłączony lub nieskuteczny cache. Rząd wielkości: od 4 do 16 godzin na diagnozę i pierwsze poprawki, bo to praca na danych, nie na przełączniku.
Integracje z hurtownią i ERP. Objaw: stany magazynowe rozjeżdżają się albo import staje w nocy i nikt tego nie widzi do rana. Przyczyna: zmiana formatu po stronie hurtowni, wygaśnięcie klucza, brak obsługi błędów w skrypcie importu. Rząd wielkości: od 2 do 8 godzin, plus czas oczekiwania na odpowiedź drugiej strony, na który nie mamy wpływu.
Płatności i moduły przewoźników po zmianach u dostawcy. Objaw: klient nie kończy zamówienia, w logach pojawia się odrzucenie z bramki, etykiety przestają się generować. Przyczyna: dostawca zmienił API albo wycofał starszą wersję modułu, a Twoja wersja sklepu nie ma zgodnego wydania. Rząd wielkości: od 2 do 6 godzin, jeżeli istnieje moduł do podmiany. Jeżeli nie istnieje, to nie jest już zgłoszenie serwisowe, tylko projekt.
Błąd 500 po aktualizacji. Objaw: biała strona albo błąd serwera zaraz po wgraniu poprawki. Przyczyna: niezgodność modułu z nową wersją PHP lub rdzenia, rzadziej uprawnienia i cache. Rząd wielkości: od 30 minut do 3 godzin, pod warunkiem że istnieje kopia zapasowa i da się cofnąć zmianę. Bez kopii rozmawiamy o zupełnie innych liczbach.
Szersze ujęcie tych kategorii opisaliśmy w tekście o najczęstszych awariach sklepów internetowych.
Jak wygląda uczciwa opieka nad PrestaShop miesiąc w miesiąc
Opieka nad sklepem PrestaShop to w praktyce pięć powtarzalnych czynności. Żadna z nich nie jest efektowna.
Po pierwsze, inwentaryzacja modułów: lista wszystkich modułów z wersją, dostawcą, datą ważności licencji i informacją, czy istnieje wydanie zgodne z kolejną dużą wersją. Ta lista jest aktualizowana, nie robiona raz. Po drugie, środowisko testowe będące kopią produkcji, na którym ląduje każda aktualizacja, zanim dotknie sklepu. Po trzecie, aktualizacje wykonywane po Twojej akceptacji i rozliczane z puli godzin, a nie po cichu w nocy. Po czwarte, pilnowanie zgodności PHP, bo to hosting zmienia wersję języka, często bez pytania, i to jest najczęstszy powód nagłego błędu 500. Po piąte, kopie zapasowe z testem odtworzenia raz na kwartał, bo kopia, której nikt nie odtworzył, jest hipotezą, nie zabezpieczeniem.
Czego tu nie ma: obietnicy, że nic się nie zepsuje. Nie składamy jej. Składamy obietnicę, że kiedy się zepsuje, będzie z czego wrócić i będzie wiadomo, co zmieniło się ostatnio.
Ile godzin zjada PrestaShop
Trzy profile z naszej praktyki, dla orientacji przy wyborze pakietu wsparcia technicznego.
Sklep stabilny: do 2 000 produktów, kilkanaście modułów, jedna integracja, zmiany głównie w treściach i banerach. Realnie od 6 do 10 godzin miesięcznie. Pakiet Basic, 950 zł, pula 10 h.
Sklep aktywny: duży katalog z kombinacjami, integracja z ERP lub hurtownią, regularne kampanie, kilka modułów płatnych z licencjami do pilnowania. Od 15 do 22 godzin. Pakiet Advanced, 1 900 zł, pula 20 h.
Sklep złożony: wielojęzyczny lub wielosklepowy, kilka integracji, moduły pisane na zamówienie, częste zmiany w procesie zakupowym. Od 30 do 40 godzin. Pakiet Premium, 3 800 zł, pula 40 h.
Jedna uwaga, którą warto wziąć na poważnie przy planowaniu budżetu: sklep w trakcie migracji wersji zużywa od dwóch do trzech razy więcej godzin niż zwykle, przez cały okres projektu i jeszcze przez kilka tygodni po przełączeniu. Jeżeli planujesz migrację, zaplanuj też wyższą pulę na ten okres. Godzina w pakiecie kosztuje 95 zł, godzina ponad pulę 150 zł, więc nadmiarowe godziny rozliczone doraźnie są po prostu droższe. Jak liczyć sumaryczny koszt utrzymania, rozpisaliśmy w osobnym tekście o kosztach utrzymania sklepu internetowego.
Migracja wersji to projekt, nie zadanie z puli
Migracji nie wrzucamy do abonamentu i nie udajemy, że zmieści się w puli godzin. Wyceniamy ją osobno, bo jej zakres wynika z inwentaryzacji, a nie z kalendarza.
Składa się z pięciu części. Audyt modułów i motywu: co ma odpowiednik, co ma odpowiednik płatny, co trzeba napisać od nowa, a co po prostu wyłączyć, bo nikt tego nie używa od trzech lat. Decyzje biznesowe na podstawie tego audytu, podejmowane przez Ciebie, nie przez nas. Motyw: dostosowanie albo budowa na nowym motywie. Dane: migracja i weryfikacja katalogu, zamówień, klientów, przekierowań. Testy na środowisku kopiującym produkcję, ze ścieżką zakupową i płatnościami włącznie. Na końcu przełączenie z zaplanowanym oknem i gotowym wariantem powrotu.
I rzecz praktyczna: nie rób migracji w listopadzie. Ani w drugiej połowie października. Każda migracja generuje falę drobnych usterek w pierwszych dwóch tygodniach po przełączeniu, a to jest dokładnie ten czas, w którym nie chcesz dzielić uwagi między sezon a poprawki. Najlepsze okna to styczeń, luty oraz okres od maja do sierpnia.
Lista kontrolna do sprawdzenia u obecnego dostawcy
Siedem pytań. Odpowiedzi powiedzą Ci więcej niż jakakolwiek prezentacja.
- Kto figuruje jako właściciel licencji modułów płatnych: Ty czy agencja? Jeżeli agencja, to przy rozstaniu zostajesz bez prawa do aktualizacji.
- Czy kod sklepu jest w repozytorium i czy masz do niego dostęp?
- Czy istnieje spis override'ów i modyfikacji poza standardem, czy trzeba go dopiero odtwarzać z plików?
- Kto ma dostęp do serwera i panelu hostingu, i czy Ty jesteś na tej liście?
- Czy ktokolwiek czyta logi błędów, czy czekamy na zgłoszenie od klienta?
- Kiedy ostatnio odtwarzano kopię zapasową na środowisku testowym?
- Jaka jest data ważności najstarszej licencji modułu i kto ją pilnuje?
Jeżeli na trzy z tych pytań nie ma odpowiedzi, opieka nad sklepem jest reakcją na awarie, a nie utrzymaniem. To nie zawsze musi być zmiana dostawcy, czasem wystarczy uzupełnienie brakujących elementów. Ale warto wiedzieć, za co się płaci, i czy w ogóle lepszy będzie abonament, czy rozliczanie godzinowe.
Porównaj zakresy i ceny pakietów na stronie /pl/sla-help-desk i wybierz ten, który odpowiada Twojemu profilowi godzinowemu. Jeżeli chcesz najpierw zobaczyć, na czym stoi Twój sklep, uruchom Tester eCommerce: podajesz adres sklepu i dostajesz bezpłatną diagnozę, bez rozmowy handlowej na start.