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.

Twig wszędzie w panelu administracyjnym

Panel administracyjny zakończył migrację ze Smarty na Twig. Każda strona admina działa teraz na szablonach Twig, co oznacza szybsze renderowanie, lepsze bezpieczeństwo (automatyczne eskejpowanie wyjścia) oraz silnik szablonów, który jest aktywnie utrzymywany i dobrze udokumentowany. Starsze kontrolery administracyjne nadal działają dzięki warstwie kompatybilności, ale kierunek jest jasny: Twig to teraźniejszość i przyszłość.

Hummingbird jako domyślny motyw

Motyw Classic został zastąpiony przez Hummingbird jako domyślny motyw front office. 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.

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:

# Check PHP version
php -v

# Check loaded extensions
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Check memory limit and execution time
php -i | grep -E "(memory_limit|max_execution_time)"

# Check MySQL version
mysql --version

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.

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:

# Standard mysqldump � works on any server
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# If your database is large (>1GB), add compression
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:

# Replace 'my-shop-db' with your actual database container name
docker exec my-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:

# Create a test database and import the backup
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Check that it imported correctly
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"

# Clean up
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:

# Full file backup with tar
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# If you want to exclude cache and logs (they're regenerated anyway)
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

# Or do it from the back office: Shop Parameters ? General ? Maintenance ? Enable
# Make sure to whitelist your own IP address

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

# Clear all caches � this is not optional
rm -rf var/cache/*

# If using CLI (recommended):
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Fix file permissions
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:

# Export specific tables from old database
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

# You'll need to review and adjust the SQL for schema changes between versions
# Column names, table structures, and foreign keys may differ

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ę.

Szablony Smarty usunięte z panelu administracyjnego

To największa przełomowa zmiana. W PS 8.x starsze kontrolery administracyjne mogły nadal używać szablonów Smarty (plików .tpl) dla swoich stron panelu administracyjnego. W PS 9 panel administracyjny jest w pełni oparty na Twig. Starsze kontrolery są opakowywane przez LegacyController Symfony, który renderuje ich wyjście przez Twig.

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 nie jest już wywoływana przez PS 9 — LegacyController całkowicie ją omija

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?

# Quick command to find potential PS9 issues in a module
# Run this from inside the module directory

# Check for overrides
find override/ -type f 2>/dev/null && echo "WARNING: Module uses overrides"

# Check for removed functions
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Check version compatibility declaration
grep -A2 "ps_versions_compliancy" *.php

Migracja motywu: Hummingbird jest teraz domyślny

PrestaShop 9 jest dostarczany z Hummingbird jako domyślnym motywem, zastępując Classic. Jeśli używasz Classic lub motywu opartego na Classic, potrzebujesz planu migracji.

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):

# Create child theme directory structure
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:

# Check your current cron jobs
crontab -l

# PS 9 cron URLs may have changed � verify each one loads correctly
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
   
   # PrestaShop's own log
   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:

# Check if .htaccess is the problem � temporarily rename it
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# If the site loads without .htaccess, regenerate it from back office:
# Shop Parameters ? Traffic & SEO ? Generate .htaccess file

# Or manually restore the default PS 9 .htaccess

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:

   # Via database if back office is broken
   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:

# Nuclear cache clear
rm -rf var/cache/*

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

# Fix ownership after cache rebuild
chown -R www-data:www-data var/

# Also clear your browser cache � old cached JS/CSS can cause phantom issues

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:

# Reset admin password � PS 9 requires Symfony's password hasher
# Do NOT use raw MD5 or direct SQL UPDATE on the password field

# Instead, use PrestaShop's CLI (if available):
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Or create a temporary PHP script to reset the password properly
# (delete this file immediately after use!)

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

# Drop the current (broken) database and recreate it
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Import your backup
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# For Docker:
docker exec -i my-shop-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i my-shop-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Ręczne przywracanie — pliki

# Remove the upgraded files
rm -rf /var/www/html/*

# Restore from your backup
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Fix permissions
chown -R www-data:www-data /var/www/html/

# Clear 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 oparty na 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.