Aktualizacja PrestaShop: co sprawdzić przed wyceną?

Do rzetelnej wyceny aktualizacji PrestaShop potrzebne są pełna wersja sklepu, środowisko serwera, motyw, kluczowe moduły i opis własnych zmian. Sam numer wersji nie określa zakresu pracy. Dwa sklepy na tej samej wersji mogą wymagać zupełnie innego przygotowania, jeśli jeden korzysta ze standardowych funkcji, a drugi ma zmodyfikowany checkout, integrację magazynową i własne reguły cen.

Ten poradnik pomaga przygotować zapytanie o aktualizację oraz uzgodnić kryteria odbioru. Nie jest instrukcją uruchomienia aktualizatora bez wcześniejszej kopii i sprawdzenia zależności.

Wersja PrestaShop i PHP muszą tworzyć wspierany zestaw

Zapisz pełne oznaczenie obecnej i planowanej wersji sklepu. Sprawdź PHP obsługujące witrynę oraz PHP używane przez CRON i polecenia konsolowe. Hosting może udostępniać różne wersje dla tych sposobów uruchamiania. Zmiana ustawienia w panelu domeny nie musi zmienić interpretera używanego przez zadania cykliczne.

W dokumentacji sprawdzonej 13 września 2026 PrestaShop 9.0 obsługuje PHP 8.1–8.4, a PrestaShop 9.1 — PHP 8.1–8.5. Zalecane wersje PHP również różnią się między tymi gałęziami. To przykład, dlaczego informacja „obsługuje PrestaShop 9” jest niewystarczająca przy doborze środowiska. Źródło: oficjalne wymagania PrestaShop 9.

Wspierane środowisko samego silnika sklepu nie potwierdza jeszcze zgodności motywu ani modułów. Przed podniesieniem PHP sprawdź także ich wymagania, rozszerzenia serwera, limity pamięci i sposób wykonywania integracji. Nie zaczynaj od zmiany PHP na produkcji tylko dlatego, że nowszy numer wygląda korzystniej.

Inwentaryzacja: zacznij od funkcji krytycznych

Lista wszystkich modułów jest przydatna, ale wykonawca powinien przede wszystkim wiedzieć, które funkcje utrzymują codzienną sprzedaż. Wskaż płatności, dostawy, punkty odbioru, fakturowanie, magazyn, importy cen i stanów, rezerwacje oraz specjalne reguły B2B. Dodaj informację, kto utrzymuje każdą integrację.

Na etapie pierwszego kontaktu wystarczą informacje techniczne i opis procesu. Haseł, kluczy API ani danych klientów nie wpisuj do ogólnodostępnego dokumentu. Jeśli potrzebny będzie dostęp do kopii, uzgodnij sposób jego przekazania i zakres uprawnień.

Co zostaje, co aktualizujemy, a co wymieniamy?

Każdy ważny element powinien dostać decyzję oraz jej uzasadnienie. „Zostaje” oznacza potwierdzoną przydatność w planowanej konfiguracji. „Do sprawdzenia” jest poprawnym statusem przed analizą; udawana pewność utrudnia wycenę i późniejszy odbiór.

Nie oceniaj modułu wyłącznie po tym, czy daje się zainstalować. Instalacja nie potwierdza obliczania rabatu, zapisu punktu odbioru ani zakończenia komunikacji z magazynem. Podobnie poprawna strona główna nie jest dowodem poprawnej aktualizacji sklepu.

Własne zmiany: największe ryzyko bywa niewidoczne w panelu

Zapytaj osoby utrzymujące sklep o modyfikacje, które powstały przez lata: dodatkowe pola, nietypowe statusy zamówień, zmiany ceny, wyłączenia przewoźników czy specjalne eksporty. Część może istnieć poza modułami widocznymi w panelu.

Przydatny jest krótki opis zachowania: „dla tej grupy klientów cena liczy się tak”, „te produkty wykluczają tego przewoźnika”, „po tym statusie wysyłamy dokument do systemu”. Z takiego opisu da się przygotować próbę odbiorczą. Sama nazwa pliku override nie wyjaśnia jego znaczenia biznesowego.

Odtworzenie brakującej funkcji może wymagać osobnej pracy. Powinno być rozpoznane w zakresie lub jawnie oznaczone jako zależność do wyjaśnienia, zamiast pojawiać się dopiero po przełączeniu sklepu.

Kopia testowa i kryteria odbioru

Aktualizację najpierw przeprowadza się na kopii z kontrolowanymi integracjami. Przygotowanie kopii obejmuje również ochronę dostępu, zatrzymanie produkcyjnych wysyłek oraz rozdzielenie konfiguracji zewnętrznych usług. Kopia ma umożliwić próbę procesu, a nie nieświadomie powielać działanie sklepu produkcyjnego.

Oficjalny przewodnik aktualizacji z panelu opisuje obsługę narzędzia aktualizującego. Zakres odbioru powinien dodatkowo odzwierciedlać funkcje sklepu; punktem odniesienia jest lista kontroli po aktualizacji.

• Porównaj wybrane produkty, kombinacje, ceny i stany.
• Sprawdź konto klienta, koszyk, adresy oraz ważne metody dostawy i płatności.
• Skontroluj wynik zamówienia w panelu i w systemach, do których powinno trafić.
• Uruchom kontrolowane próby importów, eksportów i zadań CRON.
• Porównaj istotne adresy, canonicale, przekierowania, wersje językowe i mapy witryny.
• Zapisz błędy, decyzje i warunki akceptacji, a nie tylko ogólne „testy zakończone”.

Dokładniejszą kartę kontroli zakupu znajdziesz w poradniku o zmianie checkoutu. Przy pracach nad adresami wykorzystaj również istniejący tekst o zachowaniu starych linków i przekierowaniach.

Plan przełączenia i powrotu musi uwzględniać nowe zamówienia

Przed pracami ustal moment wykonania końcowej kopii plików i bazy, sposób ograniczenia zmian danych oraz kolejność zatrzymania i wznowienia integracji. Wyznacz osobę podejmującą decyzję o uruchomieniu sklepu i warunki, przy których wracacie do poprzedniej wersji.

Powrót do kopii sprzed aktualizacji może usunąć z bieżącej bazy zamówienia lub zmiany zapisane później. Dlatego backup bez ustalonego punktu odtworzenia nie jest kompletnym planem awaryjnym. Trzeba uwzględnić również płatności, które mogą zostać potwierdzone z opóźnieniem, i dane wysłane do systemów zewnętrznych.

Zasady przygotowania kopii omawia dokumentacja kopii zapasowej PrestaShop. Dla konkretnego sklepu określ dodatkowo, kto sprawdził możliwość odtworzenia i jak będą uzgadniane zmiany powstałe podczas prac. Nie zakładaj z góry aktualizacji bez przestoju.

Z czego składa się wycena?

Wycena może obejmować analizę i inwentaryzację, przygotowanie kopii, właściwą aktualizację, dostosowanie kodu i motywu, testy, przełączenie oraz wsparcie po uruchomieniu. Osobno należy wskazać licencje, płatne aktualizacje zewnętrznych modułów i funkcje wymagające odtworzenia.

Poproś o jasny zakres, zależności i kryteria zakończenia. Stała cena ma sens dla rozpoznanej pracy; przy nieznanych modyfikacjach przydatny może być najpierw etap analizy. Nie ma jednej uczciwej kwoty dla każdego sklepu oznaczonego „PrestaShop 1.7” lub „PrestaShop 8”.

Przygotuj wersję sklepu, nazwę motywu i listę kluczowych integracji. Na tej podstawie można zacząć planować aktualizację sklepu PrestaShop, określić potrzebne sprawdzenia i przygotować zakres, który da się rozliczyć.

Weryfikacja merytoryczna: 13 września 2026. Wymagania wersji sprawdzono w dokumentacji PrestaShop. Macierz decyzji jest przykładowa; docelową ścieżkę i zgodność integracji ustala się dla konkretnego sklepu.