PrestaShop i PHP 8.0: jak sprawdzić zgodność oraz bezpiecznie zmienić wersję

PrestaShop 8.0-8.2 wymienia PHP 8.0 jako technicznie obsługiwane w tabeli zgodności, ale historyczna dokumentacja tej gałęzi zaleca PHP 8.1 i jest oznaczona jako dokumentacja PrestaShop 8, podczas gdy bieżąca dokumentacja dotyczy PrestaShop 9. Sama zgodność techniczna rdzenia nie czyni PHP 8.0 bezpiecznym wyborem: PHP 8.0 zakończyło wsparcie w 2023 r., a PHP 8.1 zakończyło wsparcie 31 grudnia 2025 r. Wymagania PrestaShop 8 i status wsparcia PHP

Na dzień weryfikacji, 16 października 2026 r., dobieraj utrzymywaną gałąź PHP do dokładnej wersji PrestaShop oraz wszystkich dodatków. PHP 8.2 i 8.3 otrzymują poprawki bezpieczeństwa, 8.4 ma aktywne wsparcie, a 8.5 jest wspierane. To nie oznacza, że każda z tych gałęzi pasuje do każdej wersji sklepu.

Aktualna tabela PrestaShop 9 wskazuje, że wydanie 9.0 obsługuje PHP 8.1-8.4 i rekomenduje 8.4, a wydanie 9.1 obsługuje PHP 8.1-8.5 i rekomenduje 8.5. PrestaShop 8.0-8.2 w dokumentacji tej gałęzi ma tabelę zgodności do PHP 8.1, ale nie wolno przenosić tego historycznego zalecenia na dziś bez oceny wsparcia i komponentów. Przed zmianą porównaj pełny numer sklepu z właściwą tabelą producenta. Wymagania PrestaShop 9

Zapisz wydanie PrestaShop, PHP obsługujące stronę WWW oraz aktywne rozszerzenia. Wersję sklepu znajdziesz w Back Office obok logo; zanotuj pełny numer, na przykład 8.1.x, zamiast samej głównej linii.

Wersję PHP sprawdzisz w panelu hostingu w sekcji typu `Select PHP Version`, `PHP Manager` lub ustawieniach domeny. Gdy panel rozdziela PHP CLI i wersję dla WWW, zanotuj obie osobno. Polecenie `php -v` może pokazać interpreter CLI, który różni się od PHP obsługującego sklep.

Rozszerzenia PHP zweryfikujesz w panelu hostingu lub raporcie administratora. PrestaShop wymienia między innymi cURL, DOM, GD, Intl, mbstring, PDO MySQL i Zip jako wymagane rozszerzenia. Nie pozostawiaj publicznie dostępnego pliku `phpinfo.php` po diagnostyce, bo ujawnia szczegóły serwera.

Zapisz też termin kopii, osobę odpowiedzialną i sposób przywrócenia poprzedniego interpretera. Na hostingu zarządzanym poproś administratora o wskazanie, czy przełączenie dotyczy właściwej domeny i procesu PHP-FPM.

Sprawdzaj wydanie każdego dodatku, nie tylko jego nazwę. Na karcie produktu lub w dokumentacji producenta sprawdź wersję modułu, zgodność z PrestaShop, wymagania PHP, zależności i datę aktualizacji. Jeśli nie ma informacji o planowanym PHP, poproś autora o potwierdzenie dla dokładnego wydania sklepu.

Zacznij od komponentów, które przyjmują płatności, tworzą dostawy, generują faktury, przesyłają dane do ERP albo zmieniają checkout. Następnie zweryfikuj motyw, dodatki wizualne i własne modyfikacje. Zapisz nazwę, wersję, źródło, datę aktualizacji oraz osobę mogącą potwierdzić zgodność.

Przejrzyj logi przed zmianą, aby odróżnić wcześniejsze ostrzeżenia od nowych błędów. W PrestaShop 8 logi aplikacji mogą znajdować się w `var/logs`, a hosting zwykle prowadzi osobne logi PHP i serwera WWW. Materiał WooCommerce czy PrestaShop: koszty, moduły i wybór 2026 pomoże, gdy zmiana PHP jest częścią szerszej decyzji o platformie.

Staging powinien odtwarzać istotne ustawienia produkcji: wersję PrestaShop, PHP, rozszerzenia, serwer, motyw, moduły i integracje. Sama kopia plików nie wystarczy, ponieważ baza zawiera konfigurację, zamówienia i statusy potrzebne do wiarygodnych testów.

Wykonaj spójną kopię plików i bazy, a następnie sprawdź, czy możesz je odtworzyć w osobnym środowisku. Na stagingu wyłącz wysyłkę rzeczywistych e-maili i połączenia tworzące prawdziwe płatności lub etykiety. Zmień wersję PHP dla kopii przez panel hostingu, nie przez produkcyjną domenę.

Po zmianie wyczyść cache PrestaShop w Back Office przez `Zaawansowane > Wydajność > Wyczyść pamięć podręczną`. Jeśli administrator usuwa cache z plików, powinien działać w katalogu `var/cache`, nie w pozostałych danych sklepu. Zapisuj czas, widok, oczekiwany wynik i każdy komunikat błędu.

Kopia testowa daje wiarygodny wynik tylko wtedy, gdy odpowiada produkcji pod względem wersji serwera, konfiguracji i dodatków. Poradnik konfiguracji PrestaShop 8.x pomaga uporządkować ustawienia środowiska, które trzeba uwzględnić w próbie.

Testuj ścieżki wpływające na przyjęcie i obsługę zamówienia. Poprawne logowanie do Back Office nie potwierdza jeszcze, że klient może kupić produkt, zapłacić, otrzymać wiadomość i zobaczyć właściwy status.

Wykonaj logowanie do panelu, wyszukiwanie produktu, dodanie wariantu do koszyka oraz zamówienie testowe z dostawą i płatnością. Sprawdź status po transakcji, wiadomości e-mail, dokumenty, synchronizację ERP, eksporty i zadania cron, jeżeli sklep ich używa. Przetestuj też widoki na telefonie i komputerze.

Po każdym scenariuszu sprawdź log PHP, serwera WWW, aplikacji i integracji. Szukaj komunikatów `Fatal error`, `Uncaught Error`, `Class not found`, `Call to undefined function` oraz błędów o brakujących rozszerzeniach. Godzina testu ułatwia odróżnienie nowych wpisów od wcześniejszych.

Perspektywa KC Mobile: Przy zmianie środowiska PHP sprawdzamy cały łańcuch zamówienia, nie tylko stronę główną. Błąd może pojawić się dopiero przy funkcji modułu, na przykład tworzeniu przesyłki lub wysyłaniu zamówienia do ERP.

Błąd 500 oznacza niepowodzenie po stronie serwera, ale nie podaje przyczyny. Sprawdź log PHP, serwera WWW i PrestaShop dla godziny wystąpienia problemu, a potem porównaj wpisy z rejestrem zmian.

Jeśli panel albo sklep nie działa, przywróć poprzednią wersję PHP zgodnie z przygotowanym planem i sprawdź koszyk oraz płatność. Nie instaluj kolejnych dodatków na produkcji, dopóki nie ustalisz źródła problemu. Gdy błąd dotyczy pojedynczej funkcji, odtwórz go na kopii.

Na stagingu wyłączaj pojedynczo ostatnio aktualizowane moduły i za każdym razem ponawiaj ten sam test. Zweryfikuj też wymagane rozszerzenia i konfigurację PHP dla właściwej domeny. Dokumentacja pomocy PrestaShop przy błędzie 500 po aktualizacji modułu zaleca sprawdzenie zgodności dodatku, czyszczenie cache przez `Zaawansowane > Wydajność` i diagnostykę trybem debugowania. Włączaj debugowanie na kopii, ponieważ komunikaty mogą ujawnić szczegóły techniczne. Procedura diagnozy błędu 500 po aktualizacji modułu

Przywrócenie kopii bazy może usunąć zamówienia zapisane po wykonaniu kopii. Odtwarzaj ją tylko wtedy, gdy trzeba cofnąć również zmiany danych i masz uzgodniony sposób obsługi późniejszych zamówień.

Ustal termin na podstawie aktywności sklepu i dostępności zespołu, który obsługuje zamówienia. Wdrożenie wymaga właściciela, dostępu do hostingu, sprawdzonej kopii, zaliczonych testów i osoby mogącej przywrócić poprzednie ustawienia. Okno powinno obejmować przełączenie i test zakupu od początku do końca.

Przerwij wdrożenie, jeśli nie da się wykonać kopii, brakuje testowego środowiska, moduł płatności nie ma potwierdzonej zgodności albo po przełączeniu nie działa koszyk czy zapis zamówienia. Przed startem wskaż osobę decyzyjną i sposób poinformowania zespołu o wycofaniu.

Przy własnych modyfikacjach lub wielu integracjach warto ocenić kod przed zmianą środowiska. Wsparcie przy technologiach PHP pomoże ustalić zgodność sklepu i zaplanować przejście na utrzymywaną wersję.

• PrestaShop themes: jak wybrać motyw, który nie utrudni rozwoju sklepu
• Jak wyłączyć sklep PrestaShop i bezpiecznie włączyć tryb konserwacji
• PrestaShop API: jak skonfigurować dostęp i bezpiecznie zintegrować sklep
• Konfigurator produktu w PrestaShop: wybór modułu i wdrożenie