Jak przeprowadzić aktualizację PrestaShop

Aktualizacja sklepu opartego na PrestaShop to nie tylko kosmetyczne odświeżenie, ale proces wpływający na wydajność, stabilność i bezpieczeństwo sprzedaży. Dobrze zaplanowana aktualizacja minimalizuje ryzyko przestojów, konfliktów z motywem i modułami oraz utraty danych. Poniżej znajdziesz szczegółową, techniczną instrukcję – od przygotowania i kopii zapasowych, przez różne metody przeprowadzenia procesu, aż po testy i plan ewentualnego wycofania zmian.

Przygotowanie: audyt, kopie zapasowe i środowisko testowe

Audyt wersji i zakres zmian

Zacznij od identyfikacji obecnej wersji sklepu i docelowej wersji. Sprawdź noty wydania oraz dokumentację zmian (changelog), zwłaszcza w obszarach płatności, koszyka, zamówień oraz API. Zwróć uwagę na zmiany niekompatybilne wstecz (breaking changes) oraz minimalne wymagania PHP, MySQL/MariaDB, Elasticsearch (jeśli używasz) i bibliotek. Zbadaj, czy sklep posiada modyfikacje core lub overrides, które mogą wymagać refaktoryzacji po aktualizacji.

Weryfikacja wymagań serwera

• PHP: zgodność z docelową wersją Presta (np. 7.4/8.1/8.2), ustawienia memory_limit, max_execution_time, upload_max_filesize, post_max_size.
• Rozszerzenia: intl, gd, zip, mbstring, curl, json, pdo, dom, fileinfo; sprawdź ich aktywację.
• Baza danych: wersja i silnik tabel (InnoDB), kodowanie utf8mb4, collation, rozmiar dziennika transakcji.
• Serwer WWW: Apache/Nginx, poprawne reguły przepisywania (mod_rewrite), buforowanie, limity połączeń.
• CLI: dostęp do SSH przyspieszy prace (rsync, mysqldump, narzędzia do kompresji).

Obowiązkowy backup plików i bazy

Przed jakąkolwiek ingerencją wykonaj pełny backup. To gwarancja szybkiego powrotu do działania w razie niepowodzenia.

• Pliki: katalog sklepu (w tym modules, themes, override), pliki konfiguracyjne (app/config/parameters.php lub config/settings.inc.php w starszych gałęziach), zasoby multimedialne (img, download).
• Baza: zrzut danych (mysqldump –routines –triggers –single-transaction). Sprawdź możliwość importu próbnego na lokalnym środowisku.
• Snapshot: jeżeli masz VPS/serwer w chmurze, rozważ snapshot wolumenów EBS/Block Storage.
• Walidacja: upewnij się, że kopie można przywrócić – test odtworzenia na klonie.

Środowisko testowe (staging) i kontrola dostępu

Utwórz odseparowane środowisko testowe (subdomena, osobna baza) i klon plików. Zabezpiecz je loginem i hasłem lub blokadą IP, aby roboty i klienci nie indeksowali ani nie odwiedzali testowej instancji. W panelu ustawienia SEO i URLs przypisz domenę testową, wyłącz indeksowanie, dodaj informację o trybie testowym w stopce. W komunikacji zespołowej używaj pojęcia staging – to środowisko pośrednie, na którym testujesz całość procesu.

Plan okna serwisowego i komunikacja

• Wybierz termin o niskim ruchu (np. noc lokalna, weekend poza szczytem). Oszacuj czas na aktualizację oraz testy powdrożeniowe.
• Przygotuj stronę trybu konserwacji (maintenance) oraz komunikat do klientów i działu obsługi.
• Określ kryteria sukcesu (np. poprawny proces zakupu, wystawienie faktury, działające płatności) i warunki wycofania zmian.

Metody przeprowadzenia aktualizacji rdzenia

Aktualizacja przez moduł 1‑Click Upgrade (autoupgrade)

To najczęściej wybierana metoda dla sklepów z linii 1.7.x i 8.x. Jej zaletą jest automatyzacja kroków i tworzenie kopii przed zmianami.

• Instalacja/aktualizacja modułu: w Panelu administracyjnym przejdź do Katalog modułów i wyszukaj autoupgrade/1‑Click Upgrade. Zainstaluj lub zaktualizuj moduł do najnowszej wersji kompatybilnej ze sklepem.
• Konfiguracja kanału: wybierz docelowy kanał (stabilny), określ politykę kopii zapasowych oraz opcje zachowania motywu i overrides.
• Przygotowanie: wyłącz kompilację assets, wyczyść cache, włącz tryb konserwacji na produkcji lub działaj na środowisku testowym.
• Uruchom proces: kliknij Upgrade. Monitoruj logi modułu. W razie błędów zapoznaj się z plikami logów w folderze admin/autoupgrade.
• Weryfikacja: po zakończeniu odwiedź zaplecze i front, sprawdź wersję w Informacjach o konfiguracji i przeprowadź szybki smoke test.

Aktualizacja manualna z paczki wydania

Metoda przydatna, gdy aktualizacja przez moduł nie wchodzi w grę lub występują konflikty. Wymaga większej uwagi przy kopiowaniu plików i uruchamianiu skryptów aktualizacyjnych.

• Pobierz paczkę docelowej wersji z repozytorium lub strony projektu.
• Włącz tryb konserwacji, wykonaj świeżą kopię plików i bazy (nawet jeśli masz wcześniejszy backup).
• Wyłącz overrides oraz niestandardowe moduły ryzyka. Zanotuj listę wyłączonych elementów.
• Skopiuj pliki podstawowe na serwer, uważając, aby nie nadpisać katalogów user‑generated (img, download) oraz własnych modułów i motywów, chyba że to zamierzone.
• Uruchom skrypty aktualizacyjne, jeżeli są przewidziane (np. /install/upgrade/upgrade.php w określonych wersjach), monitoruj logi PHP i serwera.
• Wyczyść foldery cache, zregeneruj klasę autoloadera, odśwież uprawnienia plików i katalogów.

Aktualizacja z użyciem Composer (projekty 8.x)

Dla projektów PrestaShop 8.x utrzymywanych jako aplikacje PHP z zależnościami w composer.json możesz prowadzić aktualizację kontrolując wersje pakietów.

• Zabezpiecz repozytorium: commituj bieżący stan i taguj wersję przed podniesieniem zależności.
• W composer.json ustaw wersję rdzenia i pakietów na docelowe constrainty (np. ^8.1). Uruchom composer update z flagą no‑dev na produkcję.
• Przebuduj assets, jeżeli projekt tego wymaga (npm/yarn build), dopasuj konfiguracje webpack/rollup.
• Wykonaj migracje bazy danych, jeśli vendor dostarcza skrypty. Monitoruj wynik poleceń i logi.
• Wyczyść i odtwórz katalogi cache/var, wykonaj warm‑up.

Migracja na nowy serwer wraz z aktualizacją

Czasem wygodniej i czyściej jest zaktualizować sklep podczas przenosin na nową platformę. Umożliwia to przygotowanie środowiska równoległego i przełączenie ruchu po testach.

• Postaw nową infrastrukturę z wymaganymi wersjami PHP/DB, skonfiguruj wstępnie wirtualny host i HTTPS.
• Zaimportuj kopie plików i bazy, zaktualizuj domenę w ustawieniach sklepu oraz pliku konfiguracyjnym parametrów połączeń.
• Przeprowadź aktualizację na klonie, dokonaj testów, a następnie przełącz DNS lub balansowanie po pomyślnej walidacji.
• Zaplanuj czas propagacji DNS i utrzymaj krótkie TTL przed cut‑over.

Motywy, moduły i kompatybilność

Ocena kompatybilności motywu

Niestandardowy motyw jest częstym źródłem konfliktów po aktualizacji. Sprawdź dokumentację autora i listę hooków. Porównaj pliki szablonów z wersją Classic lub nową wersją motywu. Zwróć uwagę na zmiany w strukturze katalogów, nazwach bloków i klas CSS/JS. Jeżeli motyw jest przestarzały, zaplanuj jego aktualizację lub refaktoryzację, a w razie potrzeby rozważ tymczasowy powrót do Classic, by utrzymać sprzedaż podczas prac.

Weryfikacja modułów krytycznych

Moduły płatności, bramki dostaw, integracje z fakturowaniem i magazynem muszą być zgodne z docelową wersją. Zbierz listę producentów i wersji, sprawdź wymagania i zalecane kolejności aktualizacji. Zaktualizuj najpierw moduły infrastrukturalne (płatności, wysyłki), potem marketingowe i poprawiające UX. Wyłącz moduły nieużywane – mniejsza powierzchnia problemów to łatwiejsza diagnoza.

Overrides i modyfikacje core

Przeanalizuj katalog override oraz wszelkie modyfikacje w plikach rdzenia. Najlepszą praktyką jest wersjonowanie zmian w systemie kontroli wersji, aby łatwo wykryć różnice po aktualizacji. Jeżeli masz nieuniknione dostosowania, rozważ przeniesienie ich do modułów (hooki, eventy) lub warstwę usług, by ograniczyć konflikt przy kolejnych wydaniach. Unikaj edycji plików vendor i core bez potrzeby.

Kompatybilność i testy integracyjne

Kompatybilność wsteczna nie zawsze jest zachowana w 100%, zwłaszcza gdy skaczesz o kilka wersji. Przygotuj listę scenariuszy integracyjnych: płatności online, kurierzy, webhooks, ERP. Testuj na danych zbliżonych do produkcyjnych (anonimizowanych), używając kluczy testowych dla PSP i operatorów logistycznych.

Tłumaczenia, waluty, podatki

Po aktualizacji sprawdź kompletność tłumaczeń i mapowanie kluczy językowych. Zsyncuj waluty, ich kursy i formaty, przejrzyj stawki VAT oraz reguły podatkowe. Upewnij się, że faktury generują się poprawnie i zawierają wymagane pola, a numery dokumentów nie dublują się po migracji.

Wydajność i cache

Po każdej zmianie oczyść i odbuduj warstwę cache: Smarty/ Twig (jeśli dotyczy), katalogi var/cache, opcache po stronie PHP, a także CDN. W panelu włącz łączenie, kompresję i minifikację (CCC), ustaw poziom kompilacji szablonów. Ustaw nagłówki HTTP dla statycznych zasobów, rozważ preload krytycznych stylów i lazy‑loading obrazów. Monitoruj TTFB i CLS/LCP po wdrożeniu.

SEO i przekierowania

Po aktualizacji sprawdź przyjazne adresy, generowanie sitemap, robots.txt oraz canonicale. Upewnij się, że nie powstały duplikaty treści. Zweryfikuj przekierowania 301/302, zwłaszcza jeśli motyw lub moduły zmieniają struktury URL. Skontroluj mikrodane (JSON‑LD, schema.org) i poprawność danych produktowych.

Dane, API i integracje zewnętrzne

Zweryfikuj stabilność integracji przez Webservice/API: autoryzację, limity, paginację oraz pola wymagane przez systemy zewnętrzne. Jeżeli aktualizacja zmienia kształt danych (np. nowe kolumny, inne typy), dostosuj mapowania w middleware. Przeprowadź testy importu/eksportu i harmonogramów CRON, sprawdź logi zadań cyklicznych i czasy wykonania.

Testy, wdrożenie produkcyjne i plan awaryjny

Testy funkcjonalne krok po kroku

• Nawigacja i wyszukiwanie: filtrowanie, sortowanie, paginacja, warianty.
• Koszyk i checkout: dodawanie/usuwanie, kody rabatowe, dostawy, podatki, płatności, regulaminy.
• Konto klienta: rejestracja, logowanie, reset hasła, historia zamówień, adresy, zwroty.
• Panel administracyjny: tworzenie produktów, kombinacji, atrybutów, stanów magazynowych, zamówień i zwrotów.
• Faktury i e‑maile transakcyjne: treść, załączniki, kodowanie znaków, poprawne szablony.
• Wydajność: czasy odpowiedzi najcięższych stron, obciążenie CPU/RAM, liczba zapytań SQL.

Testy techniczne i bezpieczeństwo

Wykonaj sanity‑check logów PHP i serwera: error.log, access.log, logi Presta w var/logs. Uruchom skan zależności (Composer audit) i upewnij się, że wszystkie biblioteki są wolne od znanych luk. Zmień uprawnienia plików i katalogów zgodnie z dobrymi praktykami, ogranicz prawa do zapisu tylko tam, gdzie to konieczne. Wymuś HTTPS, HSTS i bezpieczne ciasteczka; monitoruj nagłówki CSP. Pamiętaj, że bezpieczeństwo to proces ciągły.

Minimalizacja przestoju podczas wdrożenia

• Przygotuj paczkę wdrożeniową lub tag w repozytorium zawierający kompletny zestaw zmian.
• Włącz tryb konserwacji tuż przed przełączeniem, zablokuj składanie nowych zamówień na kilka minut.
• Wdróż pliki atomowo: rsync z –delete po weryfikacji, ewentualnie technika symlinków (current/previous) w stylu blue‑green.
• Wykonaj migracje bazy w trybie transakcyjnym, jeśli to możliwe, lub z planem locków minimalizującym czas blokad.
• Po wdrożeniu odśwież cache, wyrównaj CDN, uruchom smoke testy i dopiero potem otwórz sklep.

Plan wycofania zmian (rollback)

Jeżeli krytyczny test nie przejdzie lub sprzedaż jest zagrożona, przywróć poprzednią wersję:

• Przywróć pliki z kopii lub przełącz symlink na previous, a następnie odtwórz bazę z backupu z tego samego punktu w czasie.
• Wyczyść cache, sprawdź spójność danych (np. zamówienia z okna aktualizacji).
• Udokumentuj przyczynę, zbierz logi, przygotuj poprawkę i przetestuj ją na staging przed ponowną próbą.

Monitorowanie po wdrożeniu i utrzymanie

• Obserwuj metryki: konwersja, porzucone koszyki, błędy JS, statusy płatności, czas ładowania.
• Zbieraj feedback działu obsługi i użytkowników – zgłoszenia pomagają wykryć regresje.
• Utrzymuj cykl aktualizacji: mniejsze kroki są bezpieczniejsze niż duże skoki wersji.
• Automatyzuj: CI/CD, testy regresji, skany bezpieczeństwa pozwalają wcześniej wykrywać problemy.

Dobre praktyki konfiguracyjne po aktualizacji

• Włącz tylko potrzebne moduły, pozostałe wyłącz lub odinstaluj – ogranicza to powierzchnię ataku i konflikty.
• Skonfiguruj logowanie błędów na poziomie ostrzeżeń, aby nie zalewać logów szumem, ale nie przegapić istotnych sygnałów.
• Zweryfikuj CRON: generowanie sitemap, czyszczenie koszyków, synchronizacje z ERP – czy działają o właściwych porach i z właściwymi uprawnieniami.
• Regularnie odświeżaj certyfikaty i politykę nagłówków bezpieczeństwa, testuj je w narzędziach online.

Checklisty kontrolne do ponownego użycia

Przygotuj własne listy kontrolne na kolejne wydania. Uwzględnij warianty aktualizacji (moduł 1‑Click, manual, Composer), elementy środowiska (PHP, DB, serwer WWW), krytyczne procesy biznesowe (koszyk, płatności, dostawy), a także punkty decyzyjne (np. czy motyw wymaga pilnej aktualizacji). Standaryzacja skraca czas i zmniejsza ryzyko pomyłek.

Najczęstsze problemy i ich szybkie diagnozowanie

• Biała strona/500 po aktualizacji: sprawdź error_reporting i logi PHP; często winny jest brak zgodności modułu lub błąd w override.
• Błędy w koszyku/checkout: zderzenie JS po stronie motywu, brak zgodności z nowymi hookami; tymczasowo przełącz na motyw Classic, aby potwierdzić hipotezę.
• Niekompletne tłumaczenia lub znikające teksty: zregeneruj cache tłumaczeń, zaimportuj brakujące pliki językowe.
• Wydajność spadła: sprawdź indeksy w bazie, znacznik debug na off, CCC, a także blokujące zapytania w slow logu.
• Problemy z płatnościami: użyj trybu testowego PSP, przejrzyj webhooki i podpisy; sprawdź aktualność certyfikatów.

Jak planować przyszłe aktualizacje

Wprowadź cykl kwartalnych przeglądów: audyt wersji rdzenia, przeterminowanych zależności i statusu modułów. Trzymaj bieżącą dokumentację zmian, aby skracać czas analizy przy następnym wydaniu. Zadbaj o testy automatyczne krytycznych ścieżek i używaj środowiska staging przed każdym wdrożeniem. Dzięki temu każda kolejna aktualizacja będzie bardziej przewidywalna i szybsza w realizacji.