PrestaShop 1.7 czy 8.x — które wymagania dotyczą Twojego sklepu

Zanim porównasz oferty hostingowe, ustal, na której gałęzi pracuje Twój sklep. To nie detal: PrestaShop 1.7 obsługuje PHP do wersji 7.4 i nie działa poprawnie na PHP 8.x. Próba przełączenia 1.7.8 na PHP 8.1 kończy się najczęściej białym ekranem albo błędem typu „Call to undefined function”, bo część dołączonych bibliotek nie jest zgodna z PHP 8. Gałąź 8.x to inny kontrakt: PHP 8.1 jest tu wspierane, a nowsze wydania 8.x chodzą stabilnie na PHP 8.2 i 8.3. Efekt jest wymierny — na katalogu 5–10 tys. produktów przejście z PHP 7.4 na 8.2 skraca generowanie strony kategorii o kilkadziesiąt procent, bez zmian w szablonie.

Wersję sklepu sprawdzisz w 30 sekund na dwa sposoby. Pierwszy: panel administracyjny → Parametry zaawansowane → Informacje (Advanced Parameters → Information), numer wersji jest na górze strony. Drugi: plik app/AppKernel.php, w którym zapisana jest stała VERSION. W starszych instalacjach 1.6 szukaj stałej _PS_VERSION_ w config/settings.inc.php. Przez SSH wystarczy grep -n "VERSION" app/AppKernel.php. Zakres wsparcia wersji PHP dla poszczególnych wydań trzymaj z dokumentacji deweloperskiej PrestaShop — nie z forów, gdzie cytowane są wersje sprzed pięciu lat.

Pułapka, na którą trafiamy najczęściej: hosting zmienia domyślną wersję PHP dla całego konta przy aktualizacji serwera. Sklep 1.7 na PHP 8.2 potrafi „nagle” przestać dodawać produkty do koszyka, mimo że przez rok działał bez zmian. Jeśli planujesz przejście z 1.7 na 8.x, zaplanuj je razem ze zmianą PHP i MySQL — kolejność kroków i kopie zapasowe opisujemy w przewodniku PrestaShop AutoUpgrade: aktualizacja sklepu bez awarii.

Minimalne i zalecane wymagania serwera — tabela

Tabela poniżej to jedna lista kontrolna do porównania z ofertą hostingu. Kolumna „Minimum” oznacza, że poniżej tych wartości instalacja się nie powiedzie albo będzie niestabilna — nie że sklep będzie szybki.

Trzy punkty wymagają komentarza. Pierwszy — kodowanie bazy. PrestaShop przy nowej instalacji tworzy tabele w utf8mb4, ale po imporcie dumpa ze starszej wersji collation zostaje na utf8 (3-bajtowym). Wtedy przy produkcie z emoji lub znakiem spoza podstawowego zakresu pojawia się błąd „Incorrect string value”. Sprawdź zmienną SHOW VARIABLES LIKE 'character_set_database' — powinno być utf8mb4. Drugi — przepisywanie URL. PrestaShop generuje plik .htaccess w katalogu głównym; na Apache działa od razu, na Nginx reguły musisz przenieść do konfiguracji serwera ręcznie. Bez tego panel i strona główna działają, a kategorie zwracają 404.

Trzeci — zasoby. Na 1 vCPU i 2 GB RAM mały sklep do 500 produktów pracuje spokojnie, ale import CSV z 10 tys. pozycji kończy się błędem 502. Sklep średniej wielkości z kilkoma tysiącami zamówień miesięcznie potrzebuje 2–4 vCPU i 4–8 GB RAM — tyle zajmuje baza plus cache obiektowy. Miejsce na dysku planuj z zapasem: 200 MB to samo wdrożenie, ale zdjęcia w kilku rozmiarach, eksporty i backupy zjadasz szybciej, niż się wydaje. Jak dobrać serwer pod konkretny sklep, opisujemy w sekcji PrestaShop — wdrożenia i utrzymanie sklepów.

Wymagane rozszerzenia PHP — co i po co

Lista rozszerzeń jest stała i taka sama dla 1.7 i 8.x. Różnica jest w hostingu: nowsze pakiety mają je domyślnie, starsze — nie. Poniżej zestawienie z objawem, po którym rozpoznasz brak.

Trzy rozszerzenia robią najwięcej szkód. intl odpowiada za formatowanie walut i dat oraz sortowanie nazw — bez niego ceny potrafią wyświetlać się jako „PLN 1,299.00” zamiast „1 299,00 zł”, a lista producentów sortuje się według kodów ASCII (Ł ląduje po Z). gd generuje miniatury: bez niego zdjęcia wgrywają się, ale katalog pokazuje puste placeholdery, a panel nie przeskaluje obrazka. zip jest potrzebny do importu i eksportu CSV w archiwum oraz do instalacji modułów z paczek .zip — bez niego import produktów z hurtowni wywala się na kroku dekompresji.

Sprawdzenie: przez SSH wpisz php -m lub php -m | grep -i intl. Bez dostępu do terminala skorzystaj z instalatora PrestaShop — pierwszy krok instalacji robi test zgodności i wypisuje brakujące rozszerzenia na czerwono, zanim cokolwiek zapisze w bazie. Osobny punkt: OPcache. Formalnie jest opcjonalny, w praktyce przy sklepie z 5 tys. produktów odpowiada za różnicę rzędu 30–50% czasu generowania strony. Włącz go w panelu hostingu (opcache.enable=1, opcache.memory_consumption min. 128 MB) i pamiętaj o czyszczeniu cache po wgraniu nowej wersji plików, inaczej zobaczysz stary kod.

Praktyczna uwaga: brak rozszerzenia to nie drobiazg konfiguracyjny. PrestaShop albo się nie zainstaluje, albo wywali błąd 500 przy pierwszym wejściu w ustawienia. Jeśli hosting nie pozwala włączyć intl, zmień hosting zamiast szukać obejść.

Konfiguracja PHP, która realnie decyduje o działaniu sklepu

Biała strona po instalacji, „Allowed memory size exhausted” przy imporcie CSV albo produkt, który zapisuje się bez połowy kombinacji — w większości przypadków winne są limity PHP, nie kod PrestaShop. Poniżej progi, które ustawiamy na starcie każdego wdrożenia i które trzeba zweryfikować przed aktualizacją: aktualizacja wykonuje operacje na bazie trwające dłużej niż jeden request, więc zbyt niski timeout przerywa ją w połowie.

Ustawienie	Minimum	Zalecane	Po co
memory_limit	256M	512M, a przy dużych katalogach 1G	generowanie miniatur, import CSV, zapis produktu z wieloma kombinacjami
max_execution_time	120 s	300 s	import, regeneracja miniatur, aktualizacja sklepu
upload_max_filesize	64M	128M	wgrywanie modułów, motywów, plików CSV
post_max_size	64M	128M (nie mniej niż upload_max_filesize)	żądanie POST z plikiem
max_input_vars	5000	10000	zapis produktu z kombinacjami, szeroki import CSV

Trzy pułapki, które widzimy najczęściej:

• Limit PHP to nie wszystko. Jeśli max_execution_time masz na 300 s, a PHP-FPM działa pod Nginx z fastcgi_read_timeout 60s, import i tak padnie po minucie. Limit podnosisz w obu miejscach.
• max_input_vars poniżej 5000. Produkt z 20 atrybutami po 30 wartości to tysiące pól w formularzu. PHP obcina żądanie po cichu — nie ma błędu, jest niepełny zapis.
• Pamięć mnoży się przez procesy. 512M na proces to nie 512M na serwer. Osiem workerów PHP-FPM zajmie samo 4 GB RAM.

allow_url_fopen zostaw włączone, jeśli korzystasz z modułów płatności lub kurierskich pobierających dane z zewnętrznych URL — wyłączenie go „dla bezpieczeństwa” potrafi zablokować płatność online. open_basedir ma sens jako ograniczenie do katalogu sklepu, katalogu sesji i /tmp; jeśli zabraknie któregokolwiek z nich, dostaniesz błędy przy uploadzie plików i generowaniu PDF-ów faktur. Pełny, aktualny zestaw wymagań wersji znajdziesz w PrestaShop Developer Documentation, a kolejność prac przy aktualizacji opisujemy w materiałach o aktualizacji PrestaShop przez AutoUpgrade.

Serwer WWW: Apache, Nginx, mod_rewrite i SSL

Friendly URL-e to pierwsze miejsce, w którym wychodzi różnica między Apache i Nginx. Plik .htaccess generowany przez PrestaShop (Shop Parameters → Traffic & SEO → Friendly URL) działa tylko na Apache i tylko wtedy, gdy katalog sklepu ma AllowOverride All. Bez tego dostajesz 404 na każdej stronie produktu i kategorii, choć strona główna działa. Ten sam efekt daje wyłączony mod_rewrite — najpierw sprawdź moduł, potem pliki.

Element	Apache	Nginx
Przepisywanie URL	mod_rewrite + AllowOverride All, .htaccess z PrestaShop	brak .htaccess, ręczne try_files $uri $uri/ /index.php?$args;
Panel administracyjny	ochrona przez .htaccess w katalogu admina	osobny location /admin/ z ograniczeniem IP i własnym limitem PHP
Cache statyków	mod_expires / nagłówki w .htaccess	osobne location dla obrazów, CSS i JS z expires 30d;
Blokada plików wrażliwych	deny dla .tpl, /config, /var	location blokujące .tpl, /app/config, /var, /translations

Na Nginx konfiguracja żyje w pliku serwera, więc zmiana w panelu PrestaShop niczego nie naprawi. Po przenosinach między serwerami zawsze sprawdź koszyk, logowanie i podstronę produktu — 404 w tych miejscach to prawie zawsze brak przepisywania, a nie błąd modułu.

SSL nie jest opcją. PrestaShop 8 domyślnie ostrzega w panelu o połączeniach bez TLS, a przeglądarki blokują formularz płatności na stronie bez certyfikatu. Po włączeniu HTTPS przejrzyj opisy produktów, treści CMS i szablony maili: pojedyncze http:// łamie kłódkę i psuje zaufanie klienta.

Warstwa nagłówków to darmowe przyspieszenie: HTTP/2 zamiast HTTP/1.1 (mniejsze opóźnienia przy wielu plikach CSS i JS), kompresja gzip lub brotli dla HTML, CSS i JS oraz długi Cache-Control dla /img i /themes. Statyki PrestaShop mają w nazwach wersję lub hash, więc roczny max-age jest bezpieczny. Mechanikę nagłówków opisuje dokumentacja MDN Web Docs – HTTP. Jeśli nie chcesz diagnozować tego samodzielnie, zobacz nasze wdrożenia PrestaShop.

Hosting współdzielony vs VPS — kiedy który ma sens

Shared hosting nie jest zły sam w sobie — problem pojawia się, gdy jest niedopasowany do skali. Trzy liczby rozstrzygają u nas wybór: liczba SKU, liczba języków i szczyt ruchu, a nie średnia miesięczna. 10 000 wizyt miesięcznie to około 330 dziennie, ale jedna kampania potrafi wysłać 200 równoczesnych sesji i wtedy liczy się nie suma, a chwilowe obciążenie.

Kryterium	Shared wystarcza	Czas na VPS
Katalog	do ~1000 produktów	ponad 5000 SKU
Języki	jeden	dwa i więcej
Ruch	do ~10 000 wizyt miesięcznie	kampanie, marketplace, wyższe szczyty
Integracje	brak lub ręczna obsługa zamówień	ERP przez API, kilka sklepów, wielosklepowość
Zespół	jedna osoba obsługująca sklep	zespół, własne crony i Redis

Konkretne sygnały, że shared już nie działa: timeouty w panelu administracyjnym przy zapisie produktu, błąd 500 przy imporcie CSV powyżej kilkuset wierszy, BackupDb przerywany przez limit CPU w połowie procesu i rosnąca liczba błędów 502 w godzinach największego ruchu. To nie są „chwilowe problemy hostingu” — to limity konta, których nie da się negocjować.

Jak policzyć RAM na VPS: liczba równoczesnych workerów PHP-FPM × memory_limit + baza + system + cache. Przykład: 8 workerów × 512M = 4 GB, MariaDB z buforem 1,5–2 GB, system 1 GB, Redis 256 MB — wychodzi VPS z 8 GB RAM i zapasem na szczyt. Na shared tego nie policzysz, bo limity są wspólne dla wszystkich kont na serwerze.

VPS bez administracji to pułapka: trzeba mieć kogoś od aktualizacji PHP, backupu i monitoringu, inaczej oszczędność na hostingu zjada przestój sklepu. Jeśli planujesz przenosiny, zobacz, jak organizujemy wdrożenia i migracje PrestaShop dla firm — kolejność prac (kopie, staging, przełączenie DNS) ma większe znaczenie niż sam wybór serwera.

Jak krok po kroku sprawdzić, czy Twój serwer spełnia wymagania

Ta procedura zajmuje 10–15 minut i kończy się jednoznacznym tak/nie. Kolejność jest ważna: najpierw wersje i rozszerzenia, na końcu zachowanie pod obciążeniem.

1. Wersja PHP i lista modułów. Na VPS: php -v && php -m. Dostajesz wersję PHP i pełną listę rozszerzeń. Na hostingu współdzielonym wrzuć do katalogu plik info.php z zawartością <?php phpinfo(); ?>, otwórz w przeglądarce i skasuj po odczycie — publiczne phpinfo to wyciek konfiguracji. Sprawdź cztery wartości: wersję PHP, memory_limit, max_execution_time, opcache.enable.
2. System check z paczki PrestaShop. Wypakuj pliki sklepu i wejdź na /install. Pierwszy krok instalatora to tabela PASS/FAIL dla każdego wymaganego rozszerzenia. Każdy FAIL blokuje instalację, ale pamiętaj: PASS oznacza tylko, że rozszerzenie istnieje, a nie że działa wydajnie.
3. Baza danych. mysql --version albo w kliencie SQL SELECT VERSION();. Silnik tabel sprawdzisz przez SHOW ENGINES; — InnoDB musi mieć status DEFAULT lub YES. MyISAM kończy się blokadami przy równoczesnym zapisie zamówień.
4. Realny czas odpowiedzi. ab -n 200 -c 10 https://twojadomena.pl/ (albo scenariusz k6) na stronę główną, kategorię z filtrami i kartę produktu. Interesuje Cię średni czas i 95. percentyl, nie sam wynik PASS.
5. Testowa instalacja na subdomenie. Postaw kopię na test.twojadomena.pl z osobną bazą i przejdź ścieżkę: dodanie produktu, zamówienie, faktura PDF. Dopiero potem planuj ruchy na produkcji.

Jeśli chcesz od razu zestawić wynik z tym, co robimy w wdrożeniach PrestaShop, porównaj listę rozszerzeń z dokumentacją dla deweloperów PrestaShop — tam wymagania są aktualizowane razem z kolejnymi wydaniami.

Najczęstsze pułapki i jak je wykryć zanim wyjdzie błąd 500

Instalator pokazuje PASS, a sklep i tak sypie błędami. Poniżej pięć sytuacji, które w praktyce zdarzają się najczęściej — z objawem, przyczyną i miejscem sprawdzenia. Każdą wykryjesz w kilka minut, jeśli wiesz, gdzie patrzeć.

• mod_security blokuje zapis w panelu. Objaw: 403 przy zapisie produktu albo przy edycji treści CMS, mimo poprawnych uprawnień. Sprawdź error_log Apache oraz log mod_security w panelu hostingu. Rozwiązanie: wyłączenie reguły dla /admin albo whitelista konkretnego identyfikatora reguły — nie wyłączanie całego mod_security.
• open_basedir bez dostępu do /tmp. Objaw: błąd generowania faktury PDF, brak miniaturek po wgraniu zdjęcia, dziwne komunikaty o zapisie pliku. Diagnoza: dyrektywa open_basedir w phpinfo i log PHP.
• Brak OPcache. Objaw: dashboard ładuje się kilka sekund, każdy klik w BackOffice to 2–4 s. Sprawdzenie: opcache.enable i opcache.memory_consumption w phpinfo. Przy 128 MB i włączonym OPcache czasy BackOffice spadają zwykle o połowę.
• Za mały max_input_vars. Objaw: produkt z 300+ kombinacjami zapisuje białe okno, część wariantów ginie bez komunikatu. Wartość domyślna 1000 to za mało — ustaw 5000 i sprawdź php -i | grep max_input_vars.
• Niedziałający cron. Objaw: kursy walut stoją na jednej wartości, stany magazynowe nie odświeżają się, maile z koszyka porzuconego nie wychodzą. Sprawdź cron logi i podgląd zadań w panelu hostingu — zadania w tle muszą być odpalane przez systemowy cron, nie przez ruch na stronie.

Punkt drugi i trzeci z tej listy najczęściej wychodzą dopiero przy aktualizacji sklepu — zanim ją odpalisz, przejrzyj PrestaShop AutoUpgrade: aktualizacja sklepu bez awarii.

Kiedy wymagania przestają wystarczać — sygnały do zmiany serwera

Wymagania instalacyjne mówią, czy sklep wstanie. Nie mówią, czy utrzyma ruch. Granicę przekraczasz zwykle w trzech momentach: przy 2–3 tysiącach produktów z wariantami, przy kampanii generującej kilkaset sesji równocześnie i przy integracji odpytującej API co minutę.

Monitoruj cztery liczby i reaguj, gdy dwie przekroczą próg jednocześnie — to tańsze niż kolejne poprawki na siłę.

Plan migracji zamkniesz w 2–3 dniach: stawiasz staging na docelowym serwerze, przenosisz pliki i bazę, robisz test zamówienia i faktury, przełączasz DNS z obniżonym TTL, a potem monitorujesz 48 godzin — TTFB, load average, logi błędów i realizację cronów. Dopiero po tym okresie usunięcie starego serwera.

Kiedy rozważyć Nginx + PHP-FPM zamiast Apache z mod_php: gdy na jednym vCPU widzisz load average powyżej 2 i 2000+ sesji dziennie. Apache z mod_php ładuje interpreter PHP do każdego procesu, więc RAM znika szybciej. PHP-FPM utrzymuje osobną pulę procesów, a Nginx oddaje statyki bez dotykania PHP — w typowym sklepie z 3–5 tys. produktów to 30–40% mniej pamięci na proces. Koszt to przepisanie reguł z .htaccess na bloki location, co przy sklepie z wieloma modułami zajmuje dzień lub dwa. Zanim podejmiesz decyzję, porównaj TTFB z progami opisanymi w wytycznych Google dotyczących Core Web Vitals — to metryka, która przekłada się zarówno na koszty serwera, jak i na to, jak sklep odbierają klienci. Szerszy kontekst organizacyjny znajdziesz w materiale o organizacji wdrożeń i migracji PrestaShop.

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

Lista kontrolna do odklikania

• Wersja PrestaShop — Panel administracyjny → Parametry zaawansowane → Informacje albo app/AppKernel.php i stała _PS_VERSION_. Zrób to przed każdą zmianą PHP.
• Wersja PHP — php -v na serwerze lub w phpinfo(). Dla 1.7 maksimum to 7.4, dla 8.x minimum 8.1, a zalecane są aktualne wersje 8.2/8.3.
• Baza danych i collation — SELECT VERSION(); oraz SHOW VARIABLES LIKE 'character_set_database'. Minimum to MySQL 5.7 lub MariaDB 10.3, zalecane MySQL 8.0, domyślne collation utf8mb4.
• Rozszerzenia PHP — php -m i porównanie z listą: curl, gd, intl, mbstring, mysqli/pdo_mysql, openssl, zip, json, iconv, simplexml, fileinfo, soap.
• intl, gd, zip — najczęstsze braki — Sprawdź osobno, bo objawy są mylące: bez intl psują się waluty i daty, bez gd nie powstają miniatury, bez zip nie przejdzie import/eksport CSV spakowany w archiwum.
• OPcache — Formalnie opcjonalny, praktycznie wymóg wydajnościowy. Sprawdź opcache.enable oraz memory_consumption na środowisku produkcyjnym.
• memory_limit — Minimum 256M, zalecane 512M, przy dużych katalogach 1G. Przy 128M instalacja i generowanie miniatur potrafią się wysypać.
• max_execution_time — 120–300 s dla importu produktów, aktualizacji i generowania miniatur. Przy 30 s import CSV kończy się w połowie.
• max_input_vars — 5000+. Sprawdź, zapisując produkt z dużą liczbą kombinacji — poniżej progu dane są cicho ucinane.
• upload_max_filesize i post_max_size — 64M lub więcej, jeśli wgrywasz motywy i moduły przez panel. Sprawdź też, czy post_max_size jest większe od upload_max_filesize.
• Warstwa web: Apache albo Nginx — Apache 2.4 z mod_rewrite i AllowOverride All oraz poprawnym .htaccess. Nginx 1.20+ bez .htaccess — wymagany ręczny blok try_files i obsługa katalogu /admin.
• SSL i wymuszenie HTTPS — Certyfikat zainstalowany, przekierowanie 301 z HTTP działa, w panelu brak ostrzeżeń o połączeniu bez TLS.
• Zasoby serwera — 1 vCPU i 2 GB RAM dla małego sklepu, 2–4 vCPU i 4–8 GB RAM dla średniego. Minimum 200 MB na wdrożenie plus kilka GB na zdjęcia i backupy.
• Test zgodności przed instalacją — Instalator PrestaShop sprawdza część wymagań automatycznie — uruchom go na docelowym hostingu, zanim przeniesiesz tam sklep. Wynik traktuj jako listę do odhaczenia, nie jako gwarancję.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• MDN Web Docs – HTTP