Migracja do PrestaShop 9: Kompletny przewodnik aktualizacji

Dlaczego warto zaktualizować PrestaShop do wersji 9

PrestaShop 9 to największa zmiana architektoniczna od przejścia z wersji 1.6 na 1.7. To nie jest zwykła aktualizacja numeru wersji — to fundamentalna modernizacja platformy. Jeśli korzystasz z PrestaShop 1.7 lub 8.x, pytanie nie brzmi czy powinieneś zaktualizować, ale kiedy i jak zrobić to prawidłowo.

Oto co PrestaShop 9 wnosi:

Symfony 6.4 LTS pod maską

PrestaShop 9 aktualizuje Symfony z wersji 4.4 (PS 8.x) do Symfony 6.4 LTS. To wydanie z długoterminowym wsparciem, co oznacza łatki bezpieczeństwa i poprawki błędów do listopada 2027. Aktualizacja Symfony przynosi nowoczesne wstrzykiwanie zależności, ulepszone trasowanie, lepszą obsługę błędów i znacząco szybszy cykl życia żądań.

Dla właścicieli sklepów oznacza to stabilniejszą i bezpieczniejszą podstawę. Dla programistów oznacza to dostęp do nowoczesnych komponentów Symfony i wzorcach, wokół których zestandaryzował się ekosystem PHP.

Wymagany PHP 8.2+

PrestaShop 9 wymaga minimum PHP 8.2, z pełnym wsparciem dla PHP 8.3. To nie jest przypadkowe — PHP 8.2+ przynosi klasy readonly, fibery, ulepszony system typów i znaczącą poprawę wydajności. Benchmarki pokazują 5-15% szybsze wykonanie w porównaniu z PHP 7.4, przy niższym zużyciu pamięci na całej linii.

Jeśli nadal korzystasz z PHP 7.4 lub 8.0, sama aktualizacja do PHP 8.2+ znacząco przyspieszy Twój sklep — jeszcze zanim ruszysz PrestaShop.

Panel administracyjny przesuwa się w stronę Symfony i Twig

Migracja panelu administracyjnego ze Smarty na Twig idzie naprzód, ale nie jest ukończona w 100%. Nowe strony admina używają Symfony/Twig, natomiast legacy kontrolery administracyjne i ich szablony Smarty nadal działają przez warstwę kompatybilności LegacyController. Kierunek jest jasny, ale przy aktualizacji trzeba testować oba światy.

Hummingbird jako domyślny motyw w świeżych instalacjach PS 9.1

W świeżych instalacjach PS 9.1 Hummingbird zastępuje Classic jako domyślny motyw front office. Zaktualizowane sklepy zachowują dotychczasowy motyw. Hummingbird jest zbudowany na Bootstrap 5.3, używa nowoczesnych właściwości niestandardowych CSS i jest znacznie lżejszy niż Classic. Został zaprojektowany z myślą o wydajności — mniejsze pliki CSS, mniej JavaScript i lepsze wyniki Core Web Vitals od razu po instalacji.

Ulepszenia bezpieczeństwa

Symfony 6.4 przynosi całkowicie przebudowany komponent bezpieczeństwa. Haszowanie haseł używa nowoczesnych algorytmów (bcrypt/argon2), ochrona CSRF jest bardziej solidna, a system uwierzytelniania opiera się na pakiecie bezpieczeństwa Symfony, a nie na starym podejściu PrestaShop opartym na ciasteczkach. Luki SQL injection i XSS w starych ścieżkach kodu zostały systematycznie wyeliminowane.

PrestaShop 9 to nie kosmetyczna aktualizacja. Zmienia sposób działania platformy w samym jej rdzeniu. Dlatego właśnie musisz podejść do aktualizacji metodycznie — nagrodą jest szybszy, bezpieczniejszy i łatwiejszy w utrzymaniu sklep, ale tylko wtedy, gdy przeprowadzisz migrację prawidłowo.

Zanim zaczniesz: lista kontrolna wymagań wstępnych

Nie dotykaj działającego sklepu, dopóki nie zweryfikujesz każdego punktu na tej liście. Pomijanie wymagań wstępnych to najczęstsza przyczyna nieudanych aktualizacji.

Włącz tryb konserwacji przed ryzykownym etapem

W panelu administracyjnym Shop Parameters > General > Maintenance wyłączysz sklep, dodasz swój adres IP do wyjątków i wpiszesz komunikat serwisowy. Używaj tego przy próbach na stagingu i podczas krótkiego przełączenia produkcji.

To zrzut z prawdziwego sklepu deweloperskiego PS9.1. Ważny jest proces, a nie kopiowanie przykładowego IP lub tekstu.

Wymagania serwerowe

• PHP 8.2 lub 8.3 — sprawdź komendą php -v na swoim serwerze. PHP 8.1 NIE zadziała.
• MySQL 8.0+ lub MariaDB 10.4+ — sprawdź komendą mysql --version. MySQL 5.7 nie jest już wspierany.
• Wymagane rozszerzenia PHP: intl, gd, curl, zip, mbstring, openssl, pdo_mysql, fileinfo, dom, json
• Composer 2.x — potrzebny do zarządzania zależnościami podczas aktualizacji
• Co najmniej 256MB memory_limit w PHP — proces aktualizacji wymaga dużo pamięci
• max_execution_time co najmniej 600 sekund — duże sklepy potrzebują czasu na migracje bazy danych

Aby szybko sprawdzić konfigurację PHP:

# Sprawdź wersję PHP
php -v

# Sprawdź załadowane rozszerzenia
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Sprawdź limit pamięci i czas wykonywania
php -i | grep -E "(memory_limit|max_execution_time)"

# Sprawdź wersję MySQL
mysql --version

Sprawdź rzeczywiste środowisko, nie opis hostingu

W PrestaShop 9 strona Advanced Parameters > Information pokazuje faktycznie działający stack: wersję PHP, wersję bazy danych, limit pamięci, wersję sklepu i aktywny motyw. Zrób taki zrzut na stagingu przed planowaniem aktualizacji.

Ten zrzut pochodzi ze sklepu deweloperskiego PS9.1.0 z PHP 8.5, MySQL 8.0, limitem pamięci 512 MB i motywem Hummingbird.

Wymagania dotyczące wersji PrestaShop

• Musisz najpierw być na PrestaShop 8.1 lub 8.2. Bezpośrednie aktualizacje z wersji 1.7.x lub 1.6.x do 9.x nie są obsługiwane.
• Jeśli jesteś na PS 1.7.x, najpierw zaktualizuj do 8.2, ustabilizuj, a potem aktualizuj do 9.x.
• Jeśli jesteś na PS 1.6.x — stop. Potrzebujesz pełnej przebudowy, a nie aktualizacji. Zobacz sekcję „Czysta instalacja” poniżej.

Audyt kompatybilności modułów

To tutaj większość aktualizacji kończy się niepowodzeniem. Przed aktualizacją musisz wiedzieć, które z Twoich modułów są kompatybilne z PS9, a które nie.

1. Sporządź pełną listę każdego zainstalowanego modułu (Panel administracyjny → Moduły → Menedżer modułów)
2. Dla każdego modułu zewnętrznego skontaktuj się z dostawcą i zapytaj: „Czy wersja X.Y jest kompatybilna z PrestaShop 9?”
3. Dla każdego modułu, który nie ma potwierdzonej kompatybilności, potrzebujesz planu: zaktualizuj go, zamień lub usuń
4. Zwróć szczególną uwagę na moduły płatności — niekompatybilna bramka płatnicza oznacza zerowe przychody

Nie zakładaj, że moduł jest kompatybilny, bo „działał na PS 8.” PrestaShop 9 usuwa API i zmienia zachowanie rdzenia. Moduł, który działał bez problemów na 8.2, może się zawiesić na 9.0, ponieważ wywołuje funkcję, która już nie istnieje.

Sprawdź zainstalowane moduły w prawdziwym Module Managerze

Back Office > Modules > Module Manager pokazuje nazwy modułów, wersje, dostawców, status i informacje o aktualizacjach. Arkusz migracji buduj na realnym stanie sklepu, nie na pamięci ani starej kopii FTP.

Najpierw sprawdź moduły płatności, checkoutu, wysyłki, ERP i feedów, bo awaria w tych miejscach zatrzymuje sprzedaż lub obsługę zamówień.

Kompatybilność motywu

• Jeśli używasz domyślnego motywu Classic, musisz przejść na Hummingbird lub motyw zewnętrzny kompatybilny z PS9
• Jeśli używasz zakupionego motywu, zweryfikuj kompatybilność z PS9 u twórcy motywu
• Niestandardowe motywy oparte na Classic będą wymagały znacznych przebudowań — struktura szablonów się zmieniła
• Motywy potomne Hummingbird to zalecana ścieżka naprzód

Termin biznesowy

• Nigdy nie aktualizuj w okresach szczytowej sprzedaży (Black Friday, Boże Narodzenie, duże promocje)
• Zaplanuj aktualizację w okresie najniższego ruchu — zazwyczaj w środku tygodnia, wcześnie rano
• Zapewnij co najmniej 48 godzin czasu monitorowania po aktualizacji przed kolejnym szczytem
• Przygotuj plan przywracania (opisany poniżej)

Najpierw zrób kopię zapasową wszystkiego

To nie jest opcjonalne. To nie jest „zalecane.” To najważniejszy krok. Jeśli aktualizacja się nie powiedzie i nie masz kopii zapasowej, tracisz swój sklep. Kropka.

Kopia zapasowa bazy danych

Baza danych zawiera wszystko, co się liczy — produkty, klientów, zamówienia, konfiguracje, ustawienia modułów. Zrób jej kopię za pomocą mysqldump:

# Standardowy mysqldump — działa na każdym serwerze
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# Jeśli baza danych jest duża (>1GB), dodaj kompresję
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop | gzip > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql.gz

Jeśli Twój PrestaShop działa w Docker:

docker exec <your-shop>-db mysqldump -u root -p'YOUR_PASSWORD' --single-transaction --quick prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

Wyjaśnienie flag:

• --single-transaction — tworzy spójny snapshot bez blokowania tabel (krytyczne dla InnoDB)
• --quick — pobiera wiersze pojedynczo zamiast buforować je w pamięci (niezbędne dla dużych tabel)
• --lock-tables=false — unika blokowania tabel podczas zrzutu, dzięki czemu sklep pozostaje online

Zweryfikuj, czy kopia zapasowa działa, importując ją do testowej bazy danych:

# Utwórz testową bazę danych i zaimportuj kopię
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Sprawdź, czy import przebiegł poprawnie
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"

# Posprzątaj
mysql -u root -p -e "DROP DATABASE prestashop_backup_test;"

Kopia zapasowa plików

Zrób kopię całego katalogu PrestaShop — wszystkich plików PHP, motywów, modułów, wgranych obrazów, wszystkiego:

# Pełna kopia plików przez tar
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# Jeśli chcesz pominąć cache i logi (i tak zostaną odtworzone)
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz \
  --exclude='var/cache' \
  --exclude='var/logs' \
  /var/www/html/

Dla sklepów opartych na Docker, zrób kopię zamontowanego wolumenu:

tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /path/to/docker/html/

Przechowuj kopie zapasowe w co najmniej dwóch lokalizacjach — na samym serwerze ORAZ w lokalizacji zewnętrznej (Twój lokalny komputer, magazyn w chmurze lub inny serwer). Kopia zapasowa istniejąca wyłącznie na tym samym dysku co Twój sklep to nie jest prawdziwa kopia zapasowa.

Notatki dotyczące konfiguracji

Przed rozpoczęciem udokumentuj te ustawienia (będziesz ich potrzebować, jeśli będziesz musiał ponownie skonfigurować):

• Twój plik app/config/parameters.php (dane logowania do bazy danych, konfiguracja poczty, klucz cookie)
• Twój plik .htaccess (szczególnie jeśli dodałeś niestandardowe reguły rewrite)
• Konfiguracja SMTP/email z panelu administracyjnego
• Klucze API i ustawienia bramek płatności
• Konfiguracje zadań cron
• Wszelkie niestandardowe konfiguracje serwera (reguły Nginx, ustawienia puli PHP-FPM)

Zrób zrzuty ekranu krytycznych stron ustawień panelu administracyjnego. Gdy coś pójdzie nie tak podczas aktualizacji, posiadanie wizualnego odniesienia „jak to wyglądało wcześniej” jest bezcenne.

Proces aktualizacji krok po kroku

Istnieją dwie prawidłowe ścieżki do PrestaShop 9: aktualizacja w miejscu za pomocą oficjalnego modułu lub czysta instalacja z migracją danych. Każda ma swoje zastosowanie.

Podejście 1: Moduł Auto-Upgrade (aktualizacja 1-Click)

Oficjalna ścieżka aktualizacji wykorzystuje moduł autoupgrade (nazywany również „1-Click Upgrade”). Ten moduł automatycznie obsługuje wymianę plików, migrację bazy danych i czyszczenie po aktualizacji.

Przygotowanie

1. Zainstaluj lub zaktualizuj moduł 1-Click Upgrade do najnowszej wersji z PrestaShop Marketplace
2. Przejdź do Panel administracyjny → Moduły → 1-Click Upgrade
3. Moduł pokaże Twoją aktualną wersję i dostępne wersje docelowe
4. Uruchom listę kontrolną przed aktualizacją — moduł sprawdzi kompatybilność serwera i wskaże potencjalne problemy

Włącz tryb konserwacji

# Albo zrób to z panelu administracyjnego: Shop Parameters → General → Maintenance → Enable
# Upewnij się, że Twój własny adres IP jest na allowliście

To jest kluczowe. Nie chcesz, żeby klienci składali zamówienia, gdy baza danych jest w trakcie migracji.

Uruchom aktualizację

1. W module 1-Click Upgrade wybierz wersję docelową (PrestaShop 9.x)
2. Wybierz „Major upgrade” jako kanał aktualizacji
3. Przejrzyj opcje aktualizacji:
   • Kopia zapasowa plików i bazy danych — włącz to (dodatkowe zabezpieczenie, nawet jeśli już zrobiłeś kopię ręcznie)
   • Dezaktywacja modułów niestandardowych — włącz to, aby zapobiec konfliktom modułów podczas aktualizacji
   • Regeneracja szablonów email — włącz, jeśli ich nie dostosowałeś
4. Kliknij „Upgrade PrestaShop now”
5. NIE zamykaj karty przeglądarki, NIE nawiguj gdzie indziej — czekaj na zakończenie procesu

Aktualizacja może trwać od 5 minut (mały sklep) do ponad 30 minut (duży katalog, wiele modułów). Zobaczysz dziennik postępu pokazujący każdy krok.

Po zakończeniu aktualizacji

# Wyczyść cały cache — to nie jest opcjonalne
rm -rf var/cache/*

# Jeśli używasz CLI (zalecane):
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Napraw uprawnienia plików
chown -R www-data:www-data /var/www/html/var/
chown -R www-data:www-data /var/www/html/themes/
chmod -R 755 /var/www/html/var/

Włączaj moduły jeden po drugim

Jeśli zdecydowałeś się na dezaktywację modułów niestandardowych podczas aktualizacji, nie włączaj ich wszystkich naraz. Włączaj je po jednym:

1. Włącz moduł
2. Sprawdź front office i panel administracyjny pod kątem błędów
3. Jeśli działa, przejdź do następnego modułu
4. Jeśli coś psuje, wyłącz go i skontaktuj się z dostawcą modułu

To metodyczne podejście pozwala dokładnie określić, który moduł spowodował problem, zamiast wpatrywać się w zepsuty sklep z 30 włączonymi modułami bez pojęcia, który jest winowajcą.

Podejście 2: Czysta instalacja + migracja danych

Czasami najczystszą ścieżką naprzod jest zaczynanie od nowa. Zainstaluj PrestaShop 9 od zera i migruj dane do nowego sklepu. To podejście wymaga więcej pracy, ale daje czystą instalację bez żadnego dziedzictwa.

Kiedy wybrać czystą instalację

• Aktualizujesz z PS 1.6.x (aktualizacja w miejscu nie jest obsługiwana dla tak dużych skoków)
• Twój obecny sklep ma lata nagromadzonych nadpisań, poprawek i porzuconych tabel modułów
• I tak chcesz zmienić motyw
• Twoja baza danych rozrosła się od porzuconych koszyków, starych logów i osieroconych danych
• Poprzednie próby aktualizacji nie powiodły się

Proces

1. Zainstaluj PrestaShop 9 od nowa w nowym katalogu lub na nowym serwerze
2. Skonfiguruj swój motyw (Hummingbird lub motyw kompatybilny z PS9)
3. Zainstaluj swoje moduły (wyłącznie wersje kompatybilne z PS9)
4. Migruj swoje dane za pomocą:
   • Importu CSV PrestaShop dla produktów, kategorii i klientów
   • Bezpośredniej migracji bazy danych za pomocą niestandardowych skryptów SQL
   • Narzędzi migracyjnych zewnętrznych producentów
5. Skonfiguruj ponownie bramki płatności, wysyłkę, podatki i email
6. Przetestuj wszystko na nowej instalacji
7. Przełącz DNS lub zamień katalog główny dokumentu, gdy będziesz gotowy

Migracja danych przez import CSV

Wbudowane narzędzie importu PrestaShop (Panel administracyjny → Zaawansowane parametry → Import) obsługuje:

• Kategorie
• Produkty (z kombinacjami, zdjęciami, cechami i stanem magazynowym)
• Klientów
• Adresy
• Producentów i dostawców

Wyeksportuj ze starego sklepu, oczyść pliki CSV i zaimportuj do nowego. To jest żmudne dla dużych katalogów, ale daje najczystszy rezultat.

Migracja danych przez SQL

Dla doświadczonych programistów bezpośrednia migracja SQL jest szybsza dla dużych zbiorów danych:

# Wyeksportuj konkretne tabele ze starej bazy danych
mysqldump -u root -p old_prestashop \
  ps_product ps_product_lang ps_product_shop \
  ps_category ps_category_lang ps_category_shop \
  ps_customer ps_address \
  ps_image ps_image_lang ps_image_shop \
  ps_stock_available \
  > ~/migration_data.sql

# Musisz przejrzeć i dostosować SQL do zmian schematu między wersjami
# Nazwy kolumn, struktury tabel i klucze obce mogą się różnić

Migracja SQL wymaga głębokiej wiedzy o schemacie bazy danych PrestaShop. Jeśli nie czujesz się pewnie pisząc i debugując złożone zapytania SQL, użyj metody importu CSV lub zatrudnij programistę. Nieudana migracja SQL może uszkodzić Twoje dane w sposób, który jest niezwykle trudny do naprawienia.

Które podejście jest lepsze?

Dla większości właścicieli sklepów korzystających z PS 8.x z rozsądną liczbą dobrze utrzymanych modułów, auto-upgrade to właściwy wybór. Czysta instalacja ma sens, gdy przychodzisz z bardzo starej wersji lub chcesz wykorzystać okazję do porządków.

Kompatybilność modułów: co się psuje w PrestaShop 9

Ta sekcja jest dla programistów i technicznie ciekawych właścicieli sklepów. Zrozumienie co się zmieniło pomaga ocenić, czy Twoje moduły przetrwają aktualizację.

Migracja panelu administracyjnego z Smarty na Twig

To ważna zmiana, ale migracja panelu admina nadal nie jest kompletna. W PS 8.x starsze kontrolery administracyjne mogły używać szablonów Smarty (plików .tpl) dla swoich stron panelu administracyjnego. W PS 9 nowe strony admina są oparte na Symfony/Twig, a starsze kontrolery nadal działają przez wrapper LegacyController.

Co to oznacza w praktyce:

• Moduły z niestandardowymi stronami admina używające AdminController + Smarty nadal działają, ale są renderowane wewnątrz nowego układu Twig przez warstwę kompatybilności
• Nadpisania szablonów admina (pliki w override/controllers/admin/templates/) mogą nie działać zgodnie z oczekiwaniami
• Zmienne Smarty przypisane w initContent() mogą zostać utracone, ponieważ LegacyController opakowuje renderowanie inaczej — zmienna Smarty content musi zostać jawnie ponownie przypisana
• Metoda display() z AdminController może zachowywać się inaczej na stronach opakowanych przez LegacyController i nie występuje w nowych stronach Symfony — przetestuj każdy legacy kontroler osobno

Zmiany w systemie nadpisań

PrestaShop odradza używanie nadpisań od PS 1.7, a PS 9 jeszcze bardziej zaostrza ograniczenia:

• Nadpisania klas rdzenia nadal technicznie działają, ale są coraz bardziej kruche, w miarę jak coraz więcej kodu rdzenia przechodzi na usługi Symfony
• Nadpisania kontrolerów są zawodne — warstwa trasowania Symfony może ich nie załadować zgodnie z oczekiwaniami
• Nadpisania szablonów w katalogach override/ są przestarzałe dla stron administracyjnych
• Zalecanym podejściem są teraz hooki, dekoratory Symfony i subskrybenci zdarzeń

Jeśli masz moduły, które silnie polegają na nadpisaniach, to one najprawdopodobniej zepsują się podczas aktualizacji. Sprawdź katalog override/ w folderze każdego modułu.

Zmiany w hookach

PrestaShop 9 dodaje nowe hooki i modyfikuje niektóre istniejące:

• Kilka starszych hooków w obszarze administracyjnym zostało usuniętych lub przemianowanych
• Nowe hooki są dostępne dla stron administracyjnych opartych na Symfony
• Hooki front office pozostają w dużej mierze kompatybilne (Hummingbird używa tych samych punktów hookowania co Classic)
• Kolejność wykonywania hooków może się w niektórych przypadkach zmienić — jeśli Twój moduł zależy od wywołania przed lub po innym hooku, przetestuj to

Przestarzałe starsze kontrolery

Kilka wzorcow kontrolerów administracyjnych, które działały w PS 8.x, zachowuje się inaczej w PS 9:

• $this->l() (funkcja tłumaczenia) została usunięta z kontrolerów administracyjnych — użyj zamiast tego $this->module->l('string', 'ControllerClassName')
• Tools::displayPrice() zostało usunięte — użyj Context::getContext()->getCurrentLocale()->formatPrice($amount, $currencyIsoCode)
• W kontrolerze administracyjnym $this->meta_title, $this->fields_list i $this->bulk_actions muszą być przypisane PO wywołaniu parent::__construct(), ponieważ referencja do modułu nie jest dostępna wcześniej
• Katalog admina to teraz domyślnie backoffice/ (nie admin-dev ani losowy ciąg) — zakodowane na sztywno ścieżki admina przestaną działać

Jak sprawdzić, czy Twoje moduły są gotowe na PS9

Dla każdego zainstalowanego modułu:

1. Sprawdź stronę dostawcy — szukaj wyraźnych deklaracji kompatybilności z PS 9
2. Sprawdź nadpisania — zajrzyj do modules/yourmodule/override/. Jakiekolwiek pliki tam są sygnałem ostrzegawczym.
3. Sprawdź wywołania przestarzałych funkcji — przeszukaj pliki PHP modułu pod kątem:
   • Tools::displayPrice(
   • $this->l( w plikach kontrolerów administracyjnych
   • Klasy AdminController ze złożonymi metodami display()
   • Zakodowane na sztywno ścieżki katalogu admina
4. Sprawdź plik config.xml modułu lub główny plik PHP pod kątem ustawienia ps_versions_compliancy — czy obejmuje 9.x?

# Szybkie polecenie do znalezienia potencjalnych problemów PS9 w module
# Uruchom je z katalogu modułu

# Sprawdź override'y
find override/ -type f 2>/dev/null && echo "WARNING: Module uses overrides"

# Sprawdź usunięte funkcje
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Sprawdź deklarację kompatybilności wersji
grep -A2 "ps_versions_compliancy" *.php

Potraktuj aktualizacje modułów jako część migracji

Ekran Module updates pokazuje moduły, które wymagają uwagi jeszcze przed aktualizacją rdzenia. Aktualizuj je najpierw na stagingu, a potem testuj checkout, płatności, wysyłkę i zamówienia.

Nie klikaj na produkcji „upgrade all” w trakcie migracji. Aktualizacje modułów powinny być w tej samej kontrolowanej macierzy testów co aktualizacja PrestaShop.

Migracja motywu: Hummingbird jest domyślny w świeżych instalacjach PS 9.1

Świeże instalacje PS 9.1 dostają Hummingbird jako domyślny motyw. Sklepy aktualizowane z wcześniejszych wersji zachowują dotychczasowy motyw, ale jeśli używasz Classic lub motywu opartego na Classic, potrzebujesz planu testów i ewentualnej migracji.

Najpierw sprawdź Theme & Logo

W prawdziwym sklepie deweloperskim PS9.1 ekran Design > Theme & Logo pokazuje Hummingbird jako aktywny motyw, Classic jako nadal dostępny oraz zainstalowany motyw potomny Hummingbird. Najpierw sprawdź stan konkretnego sklepu.

Jeśli utrzymujesz własne szablony, zacznij od motywu potomnego Hummingbird zamiast edytować bezpośrednio motyw nadrzędny.

Co się zmieniło w Hummingbird

• Bootstrap 5.3 zastępuje Bootstrap 4 — nazwy klas, system siatki i klasy narzędziowe się zmieniły
• Właściwości niestandardowe CSS są szeroko wykorzystywane do tworzenia motywów — kolory, odstępy i typografia są konfigurowane za pomocą zmiennych CSS, a nie zmiennych SCSS
• Mniej JavaScript — Hummingbird polega bardziej na natywnych funkcjach przeglądarki i mniej na wtyczkach jQuery
• Nowoczesny system budowania — kompilacja zasobów oparta na Webpack z prawidłowym tree shaking
• Projekt responsywny — układ mobilny jest bazą, wersja desktopowa jest ulepszeniem (w przeciwieństwie do Classic, który był zaprojektowany najpierw pod desktop)

Jeśli używasz motywu Classic

Motyw Classic nie jest dołączony do PS 9. Twoje opcje to:

1. Przejdź na Hummingbird — najprostsza ścieżka. Utwórz motyw potomny dla swoich personalizacji.
2. Kup motyw kompatybilny z PS9 — wielu dostawców motywów wydało wersje dla PS9.
3. Przenieś swoje personalizacje Classic do motywu potomnego Hummingbird — wymaga to pracy nad frontendem, ale daje najlepszy długoterminowy rezultat.

Tworzenie motywu potomnego Hummingbird

Motyw potomny pozwala dostosować Hummingbird bez modyfikowania plików rdzenia motywu (dzięki czemu Twoje zmiany przetrwają aktualizacje motywu):

# Utwórz strukturę katalogów motywu potomnego
mkdir -p themes/my-child-theme/assets/css
mkdir -p themes/my-child-theme/templates

Utwórz plik themes/my-child-theme/config/theme.yml:

parent: hummingbird
name: my-child-theme
display_name: My Custom Theme
version: 1.0.0
author:
  name: Your Name

Dodaj swoje niestandardowe style w themes/my-child-theme/assets/css/custom.css. Hummingbird automatycznie ładuje custom.css z motywów potomnych z najniższym priorytetem (ładuje się jako ostatni), więc Twoje style nadpiszą motyw nadrzędny.

Aby nadpisać konkretny szablon, skopiuj go z themes/hummingbird/templates/ do tej samej względnej ścieżki w motywie potomnym. Kopiuj tylko pliki, które musisz zmienić — wszystko inne automatycznie przechodzi do motywu nadrzędnego.

Jeśli używasz zakupionego motywu

Skontaktuj się z dostawcą motywu i zadaj te konkretne pytania:

• Czy jest dostępna wersja kompatybilna z PS9?
• Czy jest oparta na Hummingbird, czy to samodzielny motyw?
• Czy moja obecna licencja na motyw obejmie wersję PS9?
• Jaka jest ścieżka migracji z obecnej wersji?

Jeśli dostawca nie ma wersji PS9 i nie może podać harmonogramu, zacznij planować przejście na Hummingbird już teraz.

Lista kontrolna po aktualizacji

Ukończyłeś aktualizację i panel administracyjny się ładuje. Nie świętuj jeszcze. Systematycznie zweryfikuj każdą krytyczną funkcję swojego sklepu.

Testowanie front office

Testowanie panelu administracyjnego

Weryfikacja bramek płatności

To zasługuje na własną sekcję, ponieważ bezpośrednio wpływa na przychody. Dla KAŻDEJ metody płatności:

1. Złóż prawdziwe zamówienie testowe (lub użyj trybu sandbox, jeśli jest dostępny)
2. Zweryfikuj, czy płatność jest przechwycona w panelu dostawcy płatności
3. Zweryfikuj, czy status zamówienia aktualizuje się poprawnie w PrestaShop
4. Przetestuj zwroty, jeśli Twój workflow ich wymaga
5. Sprawdź adresy URL webhook/IPN — aktualizacja mogła zmienić struktury URL

Weryfikacja wysyłki

• Zweryfikuj, czy wszyscy przewoźnicy wyświetlają prawidłowe stawki dla różnych stref
• Przetestuj progi darmowej wysyłki
• Jeśli używasz obliczania stawek przewoźnika w czasie rzeczywistym (przez API), zweryfikuj, czy połączenie nadal działa
• Sprawdź, czy wprowadzanie numerów śledzenia przesyłek i emaile powiadomień działają

Zadania cron

Sprawdź każde zautomatyzowane zadanie uruchamiane według harmonogramu:

• Emaile o porzuconych koszykach
• Synchronizacja stanów magazynowych
• Generowanie feedów (Google Shopping, Facebook itp.)
• Generowanie mapy witryny
• Aktualizacje kursów walut
• Wszelkie niestandardowe skrypty cron

Adresy URL zadań cron często zmieniają się między głównymi wersjami. Zaktualizuj wpisy w crontab:

# Sprawdź bieżące zadania cron
crontab -l

# URL-e cronów w PS 9 mogły się zmienić — sprawdź, czy każdy ładuje się poprawnie
curl -s -o /dev/null -w "%{http_code}" "https://yourshop.com/modules/yourmodule/cron.php?token=XXXXX"

Weryfikacja SEO

• Sprawdź, czy przyjazne adresy URL nadal działają (strony kategorii, strony produktów)
• Zweryfikuj, czy mapa witryny generuje się poprawnie
• Sprawdź, czy robots.txt jest poprawny
• Przetestuj kluczowe strony docelowe, które są dobrze pozycjonowane — upewnij się, że nadal istnieją pod tymi samymi adresami URL
• Jeśli adresy URL się zmieniły, natychmiast skonfiguruj przekierowania 301

Typowe problemy z aktualizacją i ich rozwiązania

Biały ekran śmierci

Najczęstszy problem po aktualizacji. Widzisz pustą białą stronę bez komunikatu o błędzie.

Rozwiązanie:

1. Włącz tryb debugowania, edytując config/defines.inc.php:

   define('_PS_MODE_DEV_', true);

2. Odśwież stronę — powinieneś teraz zobaczyć właściwy błąd PHP
3. Jeśli nadal widzisz biały ekran, sprawdź logi błędów PHP:

   # Apache
   tail -50 /var/log/apache2/error.log
   
   # Nginx + PHP-FPM
   tail -50 /var/log/php-fpm/error.log
   
   # Własny log PrestaShop
   tail -50 /var/www/html/var/logs/prod.log

4. Najczęstsze przyczyny:
   • Wyczerpana pamięć PHP — zwiększ memory_limit w php.ini do 512M
   • Brakujące rozszerzenie PHP — zainstaluj wymagane rozszerzenie i zrestartuj PHP
   • Problem z uprawnieniami plików — uruchom chown -R www-data:www-data /var/www/html/var/

Błąd 500 Internal Server Error

Zwykle spowodowany problemami z .htaccess lub konfiguracją PHP po aktualizacji.

Rozwiązanie:

# Sprawdź, czy problemem jest .htaccess — tymczasowo zmień jego nazwę
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# Jeśli strona ładuje się bez .htaccess, wygeneruj go ponownie z panelu:
# Shop Parameters → Traffic & SEO → Generate .htaccess file

# Albo ręcznie przywróć domyślny plik .htaccess z PS 9

Sprawdź również:

• Apache mod_rewrite jest włączony: a2enmod rewrite && systemctl restart apache2
• Twój virtual host Apache pozwala na nadpisywanie .htaccess: AllowOverride All
• Wersja PHP to faktycznie 8.2+ dla procesu webowego (nie tylko CLI)

Konflikty modułów po aktualizacji

Objawy: panel administracyjny ładuje się częściowo, błędy w określonych sekcjach, błędy JavaScript w konsoli.

Rozwiązanie — metoda izolacji:

1. Wyłącz WSZYSTKIE moduły niestandardowe:

   # Przez bazę danych, jeśli panel administracyjny jest uszkodzony
   mysql -u root -p prestashop -e "UPDATE ps_module SET active = 0 WHERE name NOT IN ('ps_banner','ps_contactinfo','ps_emailsubscription','ps_featuredproducts','ps_imageslider','ps_linklist','ps_mainmenu','ps_searchbar','ps_sharebuttons','ps_socialfollow','ps_wirepayment','ps_checkpayment');"

2. Wyczyść cache: rm -rf var/cache/*
3. Zweryfikuj, że sklep działa tylko z natywnymi modułami
4. Włączaj moduły po jednym, czyszcząc cache między każdym
5. Gdy znajdziesz problematyczny moduł, zaktualizuj go, zamień lub skontaktuj się z dostawcą

Brakujące lub uszkodzone tłumaczenia

Po aktualizacji niektóre ciągi tłumaczeń mogą brakować lub wyświetlać się jako surowe klucze (np. Modules.YourModule.SomeString).

Rozwiązanie:

• Przejdź do Międzynarodowy → Tłumaczenia i wyeksportuj/zaimportuj swój pakiet językowy
• Dla tłumaczeń modułów, zresetuj tłumaczenia modułu: odinstaluj i ponownie zainstaluj moduł (uwaga: to może zresetować konfigurację — najpierw zrób kopię zapasową)
• PrestaShop 9 intensywniej używa systemu tłumaczeń Symfony — pliki tłumaczeń w starym stylu (w modules/yourmodule/translations/) mogą wymagać konwersji

Problemy z cache

Przestarzały cache jest przyczyną zaskakująco wielu problemów po aktualizacji. W razie wątpliwości wyczyść wszystko:

# Radykalne czyszczenie cache
rm -rf var/cache/*

# Przebudowa cache Symfony
php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod --no-optional-warmers

# Napraw właściciela plików po przebudowie cache
chown -R www-data:www-data var/

# Wyczyść też cache przeglądarki — stary JS/CSS z cache może powodować pozorne problemy

Obrazy się nie wyświetlają

Ścieżki obrazów lub system pobierania obrazów mogą się zmienić między wersjami.

Rozwiązanie:

• Wygeneruj ponownie miniaturki: Wygląd → Ustawienia obrazów → Wygeneruj ponownie miniaturki
• Sprawdź, czy uprawnienia katalogu img/ są prawidłowe
• Jeśli używasz CDN, wyczyść cache CDN
• Zweryfikuj, czy nowy format URL obrazów odpowiada temu, czego oczekuje Twój motyw

Logowanie do panelu administracyjnego nie działa

Algorytmy haszowania haseł zmieniły się w PS 9 (MigratingPasswordHasher Symfony z bcrypt/argon2). W większości przypadków istniejące hasła będą działać, ponieważ hasher automatycznie migruje przy pierwszym logowaniu. Ale jeśli jesteś zablokowany:

# Zresetuj hasło administratora — PS 9 wymaga password hashera Symfony
# NIE używaj surowego MD5 ani bezpośredniego SQL UPDATE na polu hasła

# Zamiast tego użyj CLI PrestaShop (jeśli jest dostępne):
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Albo utwórz tymczasowy skrypt PHP, aby poprawnie zresetować hasło
# (usuń ten plik natychmiast po użyciu!)

Nigdy nie zostawiaj skryptów resetowania hasła na serwerze. Utwórz je, użyj i usuń — wszystko w jednej sesji. Zapomniany skrypt resetowania to luka bezpieczeństwa.

Kiedy zatrudnić programistę, a kiedy zrobić to samodzielnie

Bądź szczery co do swoich umiejętności technicznych. Nieudana aktualizacja może kosztować Cię dni przychodów i zaufanie klientów. Oto realistyczny przewodnik:

Prawdopodobnie możesz to zrobić sam, jeśli:

• Aktualizujesz z PS 8.2 do 9.x (skok o jedną wersję)
• Masz mniej niż 10 modułów zewnętrznych, wszystkie z potwierdzoną kompatybilnością z PS9
• Używasz standardowego motywu (Classic → Hummingbird lub zakupionego motywu ze wsparciem PS9)
• Czujesz się swobodnie z SSH, linią poleceń i operacjami na bazie danych
• Masz działające środowisko staging do wcześniejszego przetestowania
• Twój sklep nie ma niestandardowych nadpisań ani modyfikacji rdzenia

Powinieneś zatrudnić programistę, jeśli:

• Aktualizujesz z PS 1.6.x lub wczesnego 1.7.x (duża różnica wersji)
• Masz 20+ modułów, szczególnie jeśli niektóre używają nadpisań
• Masz niestandardowy motyw, który wymaga przeniesienia na Hummingbird
• Twój sklep ma niestandardowe modyfikacje rdzenia lub pliki nadpisań
• Nie czujesz się swobodnie z linią poleceń lub operacjami na bazie danych
• Twój sklep generuje znaczące dzienne przychody i przestoje są kosztowne
• Próbowałeś aktualizacji na stagingu i natrafiłeś na problemy, których nie możesz rozwiązać

Na co zwrócić uwagę u programisty

• Konkretne doświadczenie z PrestaShop — nie tylko „programista PHP” czy „programista e-commerce.” Architektura PrestaShop jest unikalna, a ogólni programiści spędzą płatne godziny na uczeniu się rzeczy, które specjalista PS już zna.
• Doświadczenie konkretnie z PS 9 — zapytaj, czy realizowali już aktualizacje do PS 9. Migracja Symfony 6.4 ma specyficzne pułapki.
• Jasny plan projektu — powinni zaproponować: audyt → aktualizacja na stagingu → testowanie → aktualizacja produkcji → monitorowanie.
• Wsparcie po aktualizacji — problemy często pojawiają się 1-2 tygodnie po aktualizacji, gdy uruchamiane są przypadki brzegowe. Upewnij się, że wsparcie jest wliczone.

Typowe przedziały cenowe

To są przybliżone szacunki oparte na stawkach rynkowych z lat 2025-2026:

• Prosta aktualizacja (PS 8.x → 9.x, kilka modułów, standardowy motyw): 500-1500 EUR
• Średnia aktualizacja (PS 1.7.x → 9.x, przeniesienie niestandardowego motywu, umiarkowana liczba modułów): 2000-5000 EUR
• Złożona aktualizacja (PS 1.6.x → 9.x, pełna przebudowa, wiele niestandardowych modułów): 5000-15000+ EUR

Te ceny odzwierciedlają rzeczywistość, że aktualizacja głównej wersji to nie operacja na jedno kliknięcie. Jeśli ktoś wyceni Ci aktualizację z PS 1.6 na PS 9 na 200 EUR, albo nie rozumie zakresu prac, albo zamierza iść na skróty, które będą Cię później więcej kosztować.

Plan przywracania: gdy coś pójdzie nie tak

Zrobiłeś kopie zapasowe (prawda?). Oto jak ich użyć, jeśli aktualizacja skończy się katastrofalnie.

Przywracanie z Auto-Upgrade

Jeśli użyłeś modułu 1-Click Upgrade i stworzył on własną kopię zapasową:

1. Przejdź do Panel administracyjny → Moduły → 1-Click Upgrade
2. Kliknij „Rollback” i wybierz kopię zapasową sprzed aktualizacji
3. Moduł przywróci zarówno pliki, jak i bazę danych

Jeśli panel administracyjny jest całkowicie niedostępny, musisz przywrócić ręcznie:

Ręczne przywracanie — baza danych

# Usuń bieżącą (uszkodzoną) bazę danych i utwórz ją ponownie
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Zaimportuj kopię zapasową
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Dla Dockera:
docker exec -i <your-shop>-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i <your-shop>-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Ręczne przywracanie — pliki

# Usuń zaktualizowane pliki
rm -rf /var/www/html/*

# Przywróć z kopii zapasowej
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Napraw uprawnienia
chown -R www-data:www-data /var/www/html/

# Wyczyść cache
rm -rf /var/www/html/var/cache/*

Zweryfikuj, czy przywracanie się powiodło

1. Wejdź na front office — czy sklep się ładuje?
2. Wejdź do panelu administracyjnego — czy możesz się zalogować?
3. Sprawdź kilka zamówień — czy dane są nienaruszone?
4. Złóż testowe zamówienie — czy checkout działa?
5. Wyłącz tryb konserwacji, gdy wszystko jest potwierdzone jako działające

Po przywracaniu NIE podejmuj natychmiast kolejnej próby aktualizacji. Najpierw przeanalizuj, co poszło nie tak. Sprawdź logi aktualizacji, zidentyfikuj krok, który zawiodł, zbadaj konkretny błąd i napraw przyczynę na środowisku staging, zanim ponownie dotkniesz produkcji.

Sytuacja awaryjna „bez kopii zapasowej”

Jeśli nie zrobiłeś kopii zapasowych (zdarza się — nie udawajmy, że nie), Twoje opcje są ograniczone, ale nie zerowe:

• Kopie zapasowe hostingodawcy: Wielu hostingodawców przechowuje dzienne kopie zapasowe przez 7-30 dni. Sprawdź panel hostingowy lub natychmiast skontaktuj się ze wsparciem.
• Logi binarne bazy danych: Jeśli logowanie binarne MySQL jest włączone, odzyskiwanie do określonego punktu w czasie może być możliwe. Wymaga to wiedzy eksperckiej.
• Kopia zapasowa modułu autoupgrade: Jeśli zaznaczyłeś „utwórz kopię zapasową” podczas aktualizacji, szukaj w /admin/autoupgrade/backup/ plików kopii zapasowej modułu.
• Zaakceptuj i idź naprzód: Jeśli odzyskanie nie jest możliwe, skup się na naprawieniu zaktualizowanego sklepu zamiast próbować cofnąć. Czasami jedyną drogą jest droga naprzód.

Podsumowanie: ścieżka aktualizacji w skrócie

1. Audyt — sprawdź wymagania serwerowe, kompatybilność modułów, kompatybilność motywu
2. Kopia zapasowa — baza danych (mysqldump), pliki (tar), notatki konfiguracyjne
3. Staging — przetestuj całą aktualizację najpierw na środowisku staging
4. Harmonogram — wybierz okno z niskim ruchem z zapasem czasu na problemy
5. Aktualizacja — włącz tryb konserwacji, uruchom aktualizację, wyczyść cache
6. Testowanie — front office, panel administracyjny, checkout, płatności, wysyłka, emaile
7. Monitorowanie — obserwuj logi błędów przez 48 godzin po uruchomieniu
8. Porządki — wyłącz tryb debugowania, usuń pliki tymczasowe, zaktualizuj dokumentację

PrestaShop 9 to znacząca poprawa w stosunku do swoich poprzedników. Fundament Symfony 6.4, wymaganie PHP 8.2+ i panel administracyjny stopniowo migrowany do Symfony/Twig tworzą bardziej stabilną, szybszą i łatwiejszą w utrzymaniu platformę. Aktualizacja wymaga starannego planowania, ale rezultat jest wart wysiłku — nowoczesny silnik e-commerce, który będzie Ci dobrze służyć przez lata.

Nie śpiesz się, testuj dokładnie i nie pomijaj kopii zapasowych. Twój przyszły „ja” będzie Ci wdzięczny.