PrestaShop 9 requirements w jednej tabeli: minimum vs. zalecane

Zanim wgrasz paczkę na serwer, sprawdź cztery wartości: wersję PHP, wersję bazy, memory_limit i obecność HTTPS. Reszta wyjdzie w kroku 2 instalatora. Tabela celowo rozdziela dwie rzeczy, które hostingi lubią mieszać: minimum techniczne — instalator w ogóle wystartuje — oraz minimum, przy którym sklep nie muli, czyli zapis produktu z 20 kombinacjami nie trwa 4 sekund, a import 5 tys. SKU nie kończy się timeoutem.

Trzy pułapki z realnych wdrożeń:

• IIS nie jest wspierany. Jeśli panel oferuje wyłącznie Windows/IIS, zmień plan hostingu — walka z regułami przepisywania na IIS to stracony tydzień.
• HTTPS to nie opcja. Bez TLS 1.2+ bramki płatnicze nie przyjmą callbacków, cookies z flagą Secure nie zadziałają, a SEO dostaje sygnał ostrzegawczy. Certyfikat Let’s Encrypt jest darmowy — problemem bywa jego brak, nie koszt.
• 256 MB to nie komfort. Na 256 MB bez OPcache strona kategorii z 60 produktami i kilkoma modułami potrafi dobić do limitu i zwrócić białe tło zamiast treści.

Jeśli hosting deklaruje „PrestaShop obsługujemy”, ale nie potrafi podać wersji PHP i rozmiaru bazy, traktuj to jak brak odpowiedzi. Zakres prac po stronie serwera opisujemy w sekcji wdrożenia PrestaShop.

PHP 8.1–8.3: próg, który wycina część polskich hostingów

PrestaShop 9 sprawdza wersję PHP na starcie instalatora. Na 7.4 nie zobaczysz nawet formularza konfiguracji bazy — dostaniesz komunikat o niespełnionych wymaganiach. To twarde odcięcie, nie ostrzeżenie: kod PS9 używa typów zwracanych i konstrukcji z PHP 8, więc obejścia nie ma.

Na moment premiery 9.0 wspierane są PHP 8.1, 8.2 i 8.3. PHP 8.4 bywa jeszcze poza oficjalną matrycą — część modułów i bibliotek Composera nie ma dla niego wydania. Aktualną tabelę znajdziesz w dokumentacji deweloperskiej PrestaShop; sprawdź ją przed każdym przełączeniem produkcji, bo lista zmienia się między wydaniami 9.x.

Weryfikacja przez SSH zajmuje minutę:

• php -v — wersja CLI; jeśli różni się od tej w panelu, CLI i FPM mają osobne konfiguracje i to FPM obsługuje sklep.
• php -m — lista rozszerzeń; szukaj intl, mbstring, curl, gd, zip, openssl, pdo_mysql.
• php -i | grep memory_limit — limit dla CLI; dla FPM zajrzyj do /etc/php/8.3/fpm/php.ini albo do podglądu w panelu.

Gdzie zmienić wersję bez ticketu: DirectAdmin — Domeny → wybrana domena → PHP Version; cPanel — MultiPHP Manager → wybór domeny → 8.3; Plesk — Domeny → PHP Settings (tam też memory_limit); CyberPanel — Websites → Manage → Change PHP Version.

OPcache ustaw konkretnie: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, na produkcji opcache.validate_timestamps=0 — pamiętaj wtedy o systemctl reload php8.3-fpm po każdym deployu, inaczej wdrożysz pliki, których PHP nie widzi. Na stagingu zostaw 1 z revalidate_freq=2. JIT (opcache.jit=tracing, jit_buffer_size=64M) daje na typowym sklepie 0–5%, bo wąskim gardłem jest baza, nie interpreter — nie licz na przełom.

Baza danych: MySQL 5.7 vs. MariaDB — wersje i ustawienia, które mają znaczenie

Warstwa bazy wywala migracje częściej niż PHP. Dwa powody: silnik tabel i charset.

InnoDB jest wymogiem. PS9 zapisuje zamówienie w transakcji i korzysta z kluczy obcych — MyISAM tego nie potrafi. Po migracji ze starej wersji zostają tabele MyISAM od modułów, których już nie używasz. Sprawdź to jednym zapytaniem: SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='twoja_baza' AND ENGINE<>'InnoDB'; Pusta lista = OK.

Charset utf8mb4 i collation utf8mb4_unicode_ci (lub utf8mb4_general_ci). utf8mb4_unicode_ci sortuje polskie znaki przewidywalnie w listach produktów, general_ci jest szybsze, ale przy porównaniach bywa mniej precyzyjne. Kluczowa różnica to emoji: przy starym, 3-bajtowym utf8 nazwa produktu z ikoną kończy się błędem 1366 „Incorrect string value”.

Parametry do sprawdzenia przed startem:

• innodb_buffer_pool_size — minimum 512M, na serwerze dedykowanym 50–70% RAM. Na współdzielonym hostingu często wynosi 128M i wtedy każdy raport roczny skanuje dysk.
• max_allowed_packet — 64M, inaczej import CSV albo wgranie dumpa padnie w połowie.
• wait_timeout — 120–300 s; zbyt niska wartość zrywa długie zadania cron.
• max_connections — sprawdź, ile dostajesz w pakiecie; 10 połączeń to za mało przy kilku równoległych importach.

Wersję odczytasz przez SELECT VERSION(); w kliencie MySQL lub na stronie głównej phpMyAdmin („Serwer: MariaDB 10.6.x”).

Ostrzeżenie o bazach współdzielonych z limitem 1 GB: sklep z 10 tys. produktów, wariantami i logami modułów zajmuje realnie 300–800 MB, a każdy dump zajmuje miejsce podwójnie. Do migracji użyj mysqldump --single-transaction --routines --triggers --default-character-set=utf8mb4 — bez --single-transaction zablokujesz tabele na czas zrzutu. Sam przebieg przenosin opisujemy w artykule wdrożenie PrestaShop krok po kroku.

Wymagane rozszerzenia PHP i limity, o których nie pisze cennik hostingu

Komunikat o niespełnionych wymaganiach w kroku 2 instalatora PS9 w większości przypadków nie oznacza za starego serwera, a jedno brakujące rozszerzenie PHP. Instalator sprawdza listę przed utworzeniem bazy, więc wystarczy jeden czerwony krzyżyk, żeby przerwać proces. Oto co musi być włączone:

• curl — połączenia z API, płatnościami i kurierami,
• gd z FreeType i JPEG — miniatury produktów; bez FreeType nie wygenerujesz znaków wodnych i tekstu na zdjęciach, bez JPEG nie przetworzysz plików z aparatu,
• intl — formatowanie liczb, walut i dat; brak tego rozszerzenia to najczęstsza przyczyna stopu na shared hostingu,
• mbstring — polskie znaki w nazwach i opisach,
• openssl — HTTPS i szyfrowanie,
• zip — import modułów i paczek tłumaczeń,
• fileinfo — walidacja wysyłanych plików,
• simplexml/dom — pliki XML (kanały sprzedaży, płatności),
• pdo_mysql — samo połączenie z bazą,
• iconv — konwersja kodowania przy importach CSV.

Weryfikacja to jedna komenda: php -m | grep -E '^(curl|gd|intl|mbstring|openssl|zip|fileinfo|simplexml|dom|pdo_mysql|iconv) . Jeśli wypisze mniej niż 11 linii, wiesz, czego brakuje. Przy wdrożeniach PrestaShop sprawdzamy to przed zakupem hostingu, nie po — patrz nasza oferta wdrożeń PrestaShop.

Limity: upload_max_filesize i post_max_size. Moduły ważą 5–30 MB, zdjęcia produktowe po 2–5 MB, a import CSV z 10 tys. wierszy potrafi przekroczyć limit czasu. Minimum to 20M, realnie ustaw 64M, przy czym post_max_size musi być równe lub większe od upload_max_filesize. max_execution_time podnieś do 300 s na czas importu.

OPcache nie jest wymagany, ale przy 5–10 tys. SKU skraca czas odpowiedzi odczuwalnie: PHP nie kompiluje tych samych plików przy każdym żądaniu. Ustaw opcache.memory_consumption=128 i opcache.max_accelerated_files=20000 — domyślne 10000 jest za niskie dla PS9. Wpływa to na TTFB, a więc i na Core Web Vitals.

Jak w 5 minut sprawdzić, czy serwer spełnia wymagania (komendy + punktacja)

Masz SSH? Cztery komendy wystarczą:

• php -v — musi pokazać 8.1 lub wyżej,
• php -m — porównaj z listą 11 rozszerzeń powyżej,
• php -i | grep -E 'memory_limit|max_execution_time|upload_max_filesize|post_max_size',
• mysql --version (lub mariadb --version) — próg to MySQL 5.7 / MariaDB 10.4.

Bez SSH: wgraj przez FTP lub menedżer plików panelu plik info.php z treścią <?php phpinfo();, otwórz go w przeglądarce i usuń po 10 minutach. Publiczny phpinfo() zdradza wersje bibliotek, ścieżki katalogów i bywa łakomym celem dla botów.

Punktacja startowa 10 pkt:

Co PrestaShop 9 zmienia w architekturze: Symfony 6.4, Hummingbird i nowe API

Spełnienie wymagań to warunek konieczny, nie wystarczający. PS9 stoi na Symfony 6.4 LTS i to jest zmiana, która odbija się na starszych modułach. Moduły pisane pod 1.6/1.7 często korzystały z legacy kontrolerów i klas pomocniczych. Część z tego nadal działa przez warstwę kompatybilności, ale zachowania zależne od starych hooków w adminie potrafią przestać reagować po aktualizacji — bez błędu w logach, po prostu przycisk nic nie robi.

Hummingbird jest domyślnym motywem PS9. Jeśli masz customowy szablon z 1.7 zbudowany na Classicu i override'ach plików .tpl, nie przeniesie się 1:1 — struktura i nazwy szablonów są inne. Praktyka: najpierw uruchom czysty Hummingbird, potem załóż child theme i przenoś zmiany pojedynczo, porównując wygląd na staging. Przenoszenie całego szablonu hurtem kończy się tygodniem poprawek CSS w produkcji.

Nowe Admin API oparte o API Platform to inna warstwa niż stary webservice z kluczem ws_key. Dla integracji z ERP i systemem magazynowym oznacza to nowe endpointy, inną paginację i inny sposób autoryzacji. Przed migracją ustal z dostawcą ERP, które operacje (stany, zamówienia, ceny) są już przeniesione, a które nadal wymagają starej ścieżki — reszta to pole minowe.

Moduł, który „działał na 1.7”, nie znaczy „zadziała na 9”. Test kompatybilności: sprawdź changelog dostawcy pod kątem wersji wspierającej PS9, a potem na staging zainstaluj moduł, skonfiguruj, wykonaj jedną transakcję testową i sprawdź hooki po zmianie motywu. Opinia z forum, że „u mnie śmiga”, nie jest testem. Punkt odniesienia to dokumentacja deweloperska PrestaShop — tam widać, które API jest aktualne, a które wygaszane.

Migracja z 1.7 lub 8.x na PrestaShop 9: ścieżka, blokery i testy przed wdrożeniem

Migracja na PrestaShop 9 to nie jeden przycisk w panelu. Wybór sprowadza się do dwóch dróg, a decyzję podejmuje się po inwentaryzacji sklepu — tak wyglądają nasze wdrożenia PrestaShop w praktyce.

Ścieżka A: 1.7 → 8.x → 9 przez moduł Upgrade. Sensowna, gdy sklep jest blisko „czystego” PrestaShop: brak override'ów, moduły od aktywnych wydawców, motyw z niewielkimi zmianami. To dwa skoki, nie jeden — po 8.x robisz pełne testy i dopiero potem atakujesz 9. Zanim zaczniesz, sprawdź w dokumentacji deweloperskiej PrestaShop, jaki jest aktualny stan wsparcia modułu dla skoku 8 → 9. To zmienia się między wydaniami.

Ścieżka B: czysta instalacja 9 + eksport/import. Wybierasz ją, gdy sklep ma balast: dziesiątki plików w /override, moduły pisane pod PHP 5.6, tysiące kombinacji produktów. Przenosisz katalog, klientów, zamówienia i konfigurację, a kod bierzesz od nowa. Trwa dłużej, ale wynik jest przewidywalny.

Blokery do sprawdzenia przed startem:

• override — policz pliki w /override i /modules/*/override; każdy trzeba przepisać pod PHP 8.1+
• moduły płatności i kurierów — InPost, DPD, DHL: sprawdź u wydawcy, czy istnieje wersja zgodna z 9
• integracja z ERP — web service albo moduł; testuj na kopii z prawdziwym plikiem wymiany
• motyw — szablony z 1.7 rzadko wchodzą 1:1

Backup: dump bazy i plików, a potem test odtworzenia na osobnym hostingu. Backup, którego nie odtworzyłeś, nie jest backupem.

Testy akceptacyjne: koszyk, każda metoda płatności, e-mail z potwierdzeniem, faktura, stany magazynowe po zamówieniu i anulowaniu, feed Google Shopping, poprawność transakcji w GA4.

Widełki dla MŚP: sklep 500–3000 SKU z kilkoma modułami to zwykle 3–10 dni roboczych. Wyceniamy z liczby godzin po audycie, nie z cennika z sufitu. Cały proces opisujemy w tekście o wdrożeniu PrestaShop krok po kroku.

Hosting pod PrestaShop 9: shared, VPS czy dedyk — co wybrać przy jakiej skali

„Spełnia wymagania” i „będzie szybko działać” to dwie różne rzeczy. 256 MB na proces PHP wystarcza, żeby instalator doszedł do końca — nie wystarcza, żeby sklep z 10 tys. produktów i nocnym importem z ERP pracował bez timeoutów. Pełną listę progów PHP i MySQL znajdziesz w artykule o wymaganiach serwera PrestaShop.

Redis albo Memcached. W PrestaShop 9 cache można oprzeć na Redisie — wtedy każde wejście na kategorię i koszyk generuje mniej zapytań do bazy. Redis ma więcej możliwości, Memcached jest prostszy we wdrożeniu. Jeśli hosting shared nie daje żadnego z nich, przy większym katalogu odczujesz to na TTFB, a nie na „ładności” panelu.

CDN. Obrazy, CSS i JS zdejmujesz z serwera jednym ustawieniem DNS. To realnie skraca LCP, ale nie naprawi wolnego TTFB ani zbyt ciężkiego zdjęcia w sekcji hero. Sposób pomiaru masz w web.dev – Web Vitals.

Opieka po wdrożeniu. Monitoring dostępności co 1–5 minut, alert na błędy PHP, kopie dzienne z retencją 14–30 dni, aktualizacje bezpieczeństwa rdzenia i modułów, SLA reakcji np. 4 h w dni robocze. To pozycja w koszcie, nie dodatek — bez niej pierwszy błąd po aktualizacji modułu płatności zjadasz sam, w piątek po 17:00.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Wersja PHP — php -v lub panel: Domeny → PHP → wersja. Minimum 8.1, docelowo 8.3.
• Lista rozszerzeń — php -m — porównaj z listą: curl, gd, intl, mbstring, openssl, zip, fileinfo, simplexml, dom, pdo_mysql, iconv.
• memory_limit — php -i | grep memory_limit — minimum 256M, realnie 512M przy większym katalogu.
• max_execution_time — Minimum 30 s, zalecane 60–120 s — sprawdź przed importem CSV i migracją.
• upload_max_filesize i post_max_size — Minimum 20M, realnie 64M — potrzebne do importu modułów i zdjęć produktów.
• Wersja bazy danych — SELECT VERSION(); w phpMyAdmin lub SSH — MySQL 5.7+ albo MariaDB 10.4+.
• Silnik InnoDB — SHOW ENGINES; — InnoDB musi być domyślny i aktywny. MyISAM nie wchodzi w grę.
• Charset i collation — SHOW VARIABLES LIKE 'character_set_database' — oczekujesz utf8mb4 / utf8mb4_unicode_ci.
• innodb_buffer_pool_size — Sprawdź, czy nie jest to domyślne 128M przy bazie 1 GB+ — wtedy każdy zapis idzie na dysk.
• max_allowed_packet — Za niski wywali import dumpa i dużych opisów. 64M to bezpieczny start.
• HTTPS i TLS — Certyfikat aktywny, TLS 1.2+ wymuszony. Bez tego płatności i cookies działają niepewnie, a SEO cierpi.
• mod_rewrite / rewrite rules — Apache: sprawdź, czy mod_rewrite jest włączony. Nginx: reguły przepisania dla PrestaShop muszą być w konfiguracji serwera.
• OPcache — php -i | grep opcache — włączony z sensownym opcache.memory_consumption (128–256 MB) i validate_timestamps ustawionym świadomie.
• Próbna instalacja na subdomenie — Postaw PS9 na kopii zanim ruszysz produkcję — to najszybszy test, czy hosting naprawdę spełnia wymagania.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów