PrestaShop i PHP 8 — zgodność modułów i bezpieczna migracja [2026]

PrestaShop 8 i 9 wspierają PHP 8.1–8.4, ale sama platforma to dopiero połowa układanki — o zgodności decydują moduły, motyw i nadpisania (overrides). Aktualizacja PHP w sklepie PrestaShop bez przygotowania to najczęstsza przyczyna białej strony i błędów 500, a z drugiej strony sklep na PHP 7.4 traci poprawki bezpieczeństwa od 2022 roku. Ten przewodnik pokazuje, jak przeprowadzić aktualizację bezpiecznie: od audytu modułów po test transakcji na stagingu.

Najważniejsze: Kolejność dla sklepu: kopia z testem odtworzenia → aktualizacja PrestaShop i modułów na obecnym PHP → staging na docelowej wersji → test pełnej ścieżki zakupowej → produkcja poza szczytem. Sklep to system transakcyjny — transakcja testowa na stagingu nie jest opcjonalna, bo błąd w checkout kosztuje realne zamówienia.

Jaką wersję PHP wspiera PrestaShop

Zgodność platformy z wersjami PHP wygląda tak.

Wniosek dla sklepu na 1.6 lub starym 1.7: aktualizacja samego PHP nie wystarczy — najpierw migracja platformy, potem PHP. Dla sklepów na 1.7.8.x i 8.x aktualizacja PHP jest realna, ale wymaga audytu modułów.

Co dokładnie decyduje o zgodności — nie tylko platforma

Trzy warstwy, które trzeba sprawdzić przed zmianą wersji PHP.

Moduły i wtyczki. Największe źródło problemów. Moduł pisany pod PHP 7.x używa usuniętych funkcji, dynamicznych właściwości albo starego API Smarty — na PHP 8.x sypie błędami. Sprawdź każdy moduł: wersję, datę ostatniej aktualizacji, deklarowane wsparcie. Moduły porzucone (bez aktualizacji od lat) to główni kandydaci do wymiany.

Motyw i nadpisania. Motywy PrestaShop zawierają kod PHP (nie tylko szablony) — własne kontrolery, helpery, nadpisania klas (/override). Stary motyw z modyfikacjami to drugie najczęstsze źródło awarii po aktualizacji PHP.

Nadpisania rdzenia (overrides). Katalog /override nadpisuje klasy PrestaShop. Jeśli sklep ma tam zmiany pisane lata temu, przy nowym PHP (i przy aktualizacji platformy) mogą przestać działać albo konfliktować z nowymi wersjami klas. Przegląd overrides to punkt obowiązkowy audytu.

Krok po kroku — bezpieczna aktualizacja PHP w sklepie

1. Kopia zapasowa z testem odtworzenia. Pliki, baza danych, konfiguracja. Odtwórz kopię na środowisku testowym i potwierdź, że sklep działa — zanim cokolwiek zmienisz.

2. Audyt modułów i zgodności. Spisz wszystkie moduły z wersjami i datami aktualizacji. Uruchom skan zgodności kodu (PHPCompatibility) na katalogach /modules, /override i motywie. Lista modułów do aktualizacji albo wymiany to plan pracy.

3. Aktualizacje na obecnym PHP. Zaktualizuj PrestaShop do najnowszej wersji wspieranej gałęzi (1.7.8.x albo 8.x), potem moduły i motyw — wszystko na obecnej wersji PHP, gdzie potrafisz zdiagnozować problemy. Dopiero potem zmiana wersji PHP.

4. Staging na docelowej wersji PHP. Kopia sklepu na docelowym PHP (8.3/8.4) z tymi samymi rozszerzeniami co produkcja. Tu przechodzisz pełny test.

5. Test ścieżki zakupowej — obowiązkowy. Dodanie do koszyka, kupon rabatowy, wybór dostawy, wybór płatności, transakcja testowa (przelewy24/PayU w trybie sandbox), mail potwierdzający, faktura, panel zamówień w back office, zwrot. Każdy krok to miejsce, gdzie niezgodność modułu może zabić sprzedaż.

6. Produkcja poza szczytem. Wdrożenie wieczorem albo w weekend, z dostępem do panelu hostingu i planem powrotu (przełączenie wersji PHP z powrotem). Pierwsze godziny: monitoring zamówień, logów i kolejek mailowych.

Co najczęściej psuje się po aktualizacji PHP w PrestaShop

Doświadczenie z projektami pokazuje te same wzorce — warto sprawdzić je w pierwszej kolejności.

• Biała strona / błąd 500 w front office — prawie zawsze moduł albo override korzystający z usuniętych funkcji PHP. Diagnoza: tryb debug i logi.
• Błędy w back office po zalogowaniu — moduły administracyjne (statystyki, eksporty, integracje) pisane pod stare PHP.
• Problemy z płatnościami — najdroższy typ awarii: moduł płatności nie przechodzi na nowym PHP albo jego callback nie działa. Test sandbox przed produkcją jest obowiązkowy.
• Błędy Smarty i cache szablonów — stary motyw z nieaktualnym API Smarty; po aktualizacji wyczyść cache (/var/cache, cache Smarty) i skompiluj szablony od nowa.
• Deprecation w logach — dynamiczne właściwości, null w parametrach; kod działa, ale logi puchną. To lista do naprawy w kolejnych iteracjach.
• Wolniejsze działanie po zmianie — brak OPcache na nowej wersji, stary cache, niedostrojony PHP-FPM. Po aktualizacji sprawdź konfigurację serwera, nie tylko kod.

Pełne procedury naprawcze dla najczęstszych awarii opisuję w artykułach o białej stronie w PrestaShop, błędzie 500 i trybie debug, a ogólne wsparcie techniczne — na stronie pomocy PrestaShop.

Stary sklep na 1.6 / 1.7.0–1.7.7 — co wtedy

Sklepy na PrestaShop 1.6 lub wczesnym 1.7 mają dwie drogi.

Aktualizacja platformy (1.6 → 8/9) z migracją danych. Większy projekt: migracja bazy, modułów, motywu i nadpisań, z zachowaniem URL-i (przekierowania 301) i SEO. Realny czas: 2–8 tygodni zależnie od liczby modułów i modyfikacji. To jedyna droga do wspieranego PHP — ale wymaga planu i budżetu.

Zostanie na starym stacku z buforem. Możliwe tylko krótkoterminowo: hosting z odizolowanym starym PHP, WAF przed sklepem, monitoring bezpieczeństwa. Ryzyko rośnie z każdym miesiącem — nowe podatności w starym PHP i PrestaShop nie dostają łatek. To scenariusz „kupuję czas na migrację", nie rozwiązanie.

Szczegóły migracji platformy (mapa przekierowań, przenoszenie danych, testy) opisuję w artykule o migracji sklepu na inną platformę. Kontekst wersji PHP — daty wsparcia i rekomendacje — w artykule o wersjach PHP i datach wsparcia.

Wydajność — co sklep zyskuje na PHP 8

Aktualizacja PHP to dla sklepu nie tylko bezpieczeństwo, ale i szybkość — a szybkość przekłada się na konwersję.

• Szybsze generowanie stron — PHP 8.x jest istotnie szybsze od 7.x; dla katalogu z cache i Smarty realny zysk to kilkanaście–kilkadziesiąt procent czasu odpowiedzi serwera.
• OPcache i JIT — na nowym PHP lepiej działa OPcache; przy ciężkich operacjach (importy, raporty, generowanie feedów) dochodzi JIT.
• Lepszy profil bezpieczeństwa — wspierana wersja oznacza łaty na bieżąco; dla sklepu z płatnościami to warunek utrzymania zaufania i zgodności z wymogami operatorów płatności.

Po aktualizacji zmierz wynik przed/po (PageSpeed Insights, czas TTFB, GA4) — konkretne liczby najlepiej uzasadniają kolejne inwestycje w wydajność, np. optymalizację, którą opisuję w artykule o optymalizacji PrestaShop.

Ile to trwa i ile kosztuje

Dla sklepu na PrestaShop 8.x, z aktualnymi modułami, aktualizacja PHP to praca 1–2 dni: kopia, audyt modułów, staging, test ścieżki zakupowej, produkcja. Koszt: 1 500–4 000 zł netto.

Sytuacje droższe: moduły wymagające aktualizacji lub wymiany (kilka dni), stary motyw z modyfikacjami (kilka dni), overrides wymagające przepisania (tygodnie), sklep na 1.6/1.7 wymagający migracji platformy (osobny projekt). Zakres i wycena po audycie — na stronie usługi PrestaShop albo w ramach modernizacji legacy PHP, jeśli sklep ma rozbudowany kod własny.

Najczęściej zadawane pytania

Czy PrestaShop 8 działa na PHP 8.4?

Tak — PrestaShop 8.x i 9.x wspierają PHP 8.1–8.4. Warunek dotyczy modułów i motywu: platforma może być zgodna, a konkretny moduł nie. Dlatego przed zmianą wersji PHP sprawdź każdy moduł krytyczny (płatności, wysyłka, integracje) i przetestuj pełną ścieżkę zakupową na stagingu.

Co zrobić, gdy po aktualizacji PHP sklep pokazuje białą stronę?

Włącz tryb debug (_PS_MODE_DEV_ w config/defines.inc.php albo przez panel), sprawdź logi w /var/logs i komunikat błędu — wskaże plik i linię. Najczęściej winny jest moduł albo override. Tymczasowo wyłącz podejrzane moduły (zmiana nazwy katalogu w /modules), przywróć sklep do działania, potem diagnozuj pojedynczo. Procedura krok po kroku jest w artykule o białej stronie w PrestaShop.

Czy aktualizacja PHP w PrestaShop wymaga aktualizacji platformy?

Nie zawsze — PrestaShop 8.x działa na całym zakresie 8.1–8.4, więc sklep na 8.x może zmienić PHP bez aktualizacji platformy. Odwrotnie: sklep na 1.7.8 może przejść na PHP 8.x tylko po aktualizacji do najnowszego 1.7.8.x (z zastrzeżeniami) albo lepiej — do 8.x. Sklep na 1.6 wymaga najpierw migracji platformy.

Jak sprawdzić, które moduły są niezgodne z PHP 8?

• Trzema sposobami: przegląd wersji i dat aktualizacji modułów (te sprzed lat to kandydaci), skan PHPCompatibility na katalogach /modules, /override i motywie, oraz test na stagingu z włączonym trybem debug. Lista modułów do aktualizacji lub wymiany to plan pracy przed wdrożeniem.

Czy aktualizacja PHP przyspieszy sklep PrestaShop?

Zwykle tak — nowsze PHP jest szybsze, lepiej działa OPcache, a ciężkie operacje zyskują na JIT. Realny zysk zależy od hostingu, konfiguracji i modułów. Po aktualizacji wyczyść wszystkie warstwy cache (PrestaShop, Smarty, OPcache, CDN) i porównaj TTFB oraz PageSpeed Insights przed/po.

Czy mogę cofnąć aktualizację PHP, jeśli coś pójdzie nie tak?

Tak — powrót to przełączenie wersji PHP w panelu hostingu (minuta) plus ewentualne cofnięcie zmian w plikach. Dlatego aktualizację robisz poza szczytem, ze starą wersją PHP dostępną na serwerze i kopią zapasową z testem odtworzenia. Sklep transakcyjny powinien mieć plan wycofania zawsze — niezależnie od rodzaju zmiany.

Źródła

• PrestaShop — dokumentacja dla deweloperów
• PrestaShop — wymagania systemowe
• PHP.net — wspierane wersje
• endoflife.date — daty wsparcia PHP