Wymagania systemowe PrestaShop 9: PHP, MySQL i hosting

Wybór hostingu dla PrestaShop 9 nie powinien zaczynać się od hasła reklamowego, takiego jak „hosting e-commerce” czy „zoptymalizowany pod PrestaShop”.

Najpierw należy sprawdzić rzeczywiste wymagania aplikacji.

PrestaShop 9 korzysta z unowocześnionego stosu technologicznego opartego na PHP 8.x, Symfony 6.4, MySQL lub MariaDB oraz architekturze aplikacji bardziej wymagającej niż zwykła strona wizytówkowa. Serwer, na którym da się zainstalować PrestaShop, niekoniecznie zapewni stabilną pracę prawdziwego sklepu.

Ten poradnik przedstawia oficjalne wymagania systemowe PrestaShop 9 , a przede wszystkim wyjaśnia, jak przełożyć minimalne wymagania na rozsądne środowisko produkcyjne.

Uwaga dotycząca wersji: artykuł zweryfikowano 22 września 2026 r. Aktualna oficjalna strona wymagań zaleca PHP 8.5 dla PrestaShop 9.1. W chwili pisania najnowszym stabilnym wydaniem gałęzi 9.1 jest PrestaShop 9.1.5.

Wymagania PrestaShop 9 w skrócie

Aktualna oficjalna dokumentacja PrestaShop 9 podaje następujące wymagania podstawowe:

Te wartości stanowią punkt wyjścia.

Sklep z 500 produktami i dziesięcioma zamówieniami dziennie może sprawnie działać na skromnej infrastrukturze.

Sklep, który ma:

• 100 000 produktów;
• milionami plików graficznych;
• tysiącami kombinacji;
• importami XML od dostawców;
• synchronizacją z platformami marketplace;
• wieloma sklepami;
• integracją ERP;
• dużymi zadaniami cron;
• wieloma użytkownikami Back Office;

ma zupełnie inny profil zużycia zasobów.

Zgodność PrestaShop 9 z PHP

PHP to jedna z pierwszych rzeczy, które należy sprawdzić przed instalacją lub aktualizacją do PrestaShop 9.

PrestaShop 9.0

Oficjalna tabela kompatybilności podaje obecnie:

• PHP 8.1 — obsługiwany
• PHP 8.2 — obsługiwany
• PHP 8.3 — obsługiwany
• PHP 8.4 — zalecany
• PHP 8.5 — nieobsługiwany w wersji 9.0

PrestaShop 9.1

Aktualna tabela podaje:

• PHP 8.1 — obsługiwany
• PHP 8.2 — obsługiwany
• PHP 8.3 — obsługiwany
• PHP 8.4 — obsługiwany
• PHP 8.5 — zalecany

To rozróżnienie jest ważne.

Nie wystarczy zapytać dostawcę hostingu, czy „obsługuje PHP 8”.

Musisz znać:

1. dokładną wersję PrestaShop;
2. dokładną wersję PHP;
3. czy moduły obsługują tę wersję PHP;
4. czy motyw lub własny kod ma problemy z kompatybilnością PHP.

Czy zawsze używać zalecanej wersji PHP?

Przy nowej instalacji użycie zalecanej wersji PHP jest zwykle dobrym wyborem.

W przypadku istniejącego sklepu produkcyjnego najpierw przeprowadź testy.

Moduł może być zgodny z PrestaShop 9.1, a mimo to zawierać kod, który przestaje działać w PHP 8.5.

Typowe problemy z kompatybilnością PHP obejmują:

• bardziej rygorystyczne typy parametrów;
• przekazywanie null tam, gdzie wymagany jest ciąg znaków lub liczba;
• usunięte lub przestarzałe funkcje;
• problemy z właściwościami dynamicznymi;
• niekompatybilne zależności Composer;
• stare biblioteki dostawców;
• niepoprawne sygnatury metod.

Prawidłowy proces wygląda tak:

sklonuj produkcję → przełącz staging na docelową wersję PHP → przetestuj wszystko → wdroż

Nie zmieniaj PHP bezpośrednio w sklepie generującym duże przychody tylko dlatego, że panel hostingu przedstawia to jako nieszkodliwą listę rozwijaną.

Sprawdzaj osobno PHP dla WWW i CLI

To częste źródło nieporozumień.

Wersja PHP używana przez stronę może być inna niż ta używana przez SSH lub zadania cron.

Na przykład:

php -v

może pokazywać PHP 8.3, podczas gdy PHP-FPM obsługujący stronę używa PHP 8.5.

Podobnie polecenie cron takie jak:

php /var/www/shop/bin/console ...

może przypadkowo używać domyślnego pliku wykonywalnego PHP serwera zamiast wersji skonfigurowanej dla sklepu.

Zawsze sprawdzaj:

• PHP dla WWW;
• PHP w wierszu poleceń (CLI);
• PHP używane przez cron;
• PHP procesów supervisor i workerów kolejek.

Te komponenty powinny używać wersji wybranych i przetestowanych świadomie.

Limit pamięci PHP: dlaczego 512M ma znaczenie

Aktualna dokumentacja PrestaShop 9 zaleca ustawienie wartości PHP memory_limit na co najmniej:

memory_limit = 512M

Ten limit dotyczy każdego procesu PHP, a nie całkowitej pamięci serwera.

To niezwykle ważne rozróżnienie.

Załóżmy, że każdy worker PHP-FPM może zużyć do 512 MB.

Jeśli skonfigurujesz 30 równoczesnych workerów PHP, teoretyczne zapotrzebowanie na pamięć PHP będzie bardzo duże.

W praktyce większość żądań zużyje znacznie mniej pamięci, ale pulę workerów i tak trzeba dobrać na podstawie pomiarów.

Nie rozwiązuj problemów z pamięcią przez ciągłe podnoszenie limitu

Jeśli proces importu wielokrotnie osiąga 512 MB, rozwiązaniem nie musi być:

memory_limit = 2048M

Prawdziwym problemem może być kod, który wczytuje do pamięci cały plik XML dostawcy lub wszystkie produkty.

Lepsza architektura polega na:

Plik dostawcy
    ↓
Parser strumieniowy
    ↓
Partia produktów
    ↓
Przetwarzaj
    ↓
Zapisz postęp
    ↓
Następna partia

Dzięki temu zużycie pamięci pozostaje przewidywalne.

Ta sama zasada dotyczy:

• importów CSV;
• ponownego generowania obrazów;
• eksportów katalogu;
• generowania map witryny;
• dużych operacji bazodanowych.

Wymagania MySQL

Obecna oficjalna wersja minimalna dla PrestaShop 9 to:

MySQL 5.7

Dokumentacja zaleca jednak używanie aktualnej wersji bazy danych.

To rozsądne zalecenie.

Wersja minimalna wyznacza granice kompatybilności, ale nowego środowiska produkcyjnego nie należy celowo opierać na przestarzałym wydaniu bazy danych, chyba że wymaga tego konkretne ograniczenie infrastruktury.

Twoja wersja bazy danych powinna być również obsługiwana przez:

• twój system operacyjny;
• dostawcę hostingu;
• narzędzia do kopii zapasowych;
• system monitoringu;
• strategię replikacji, jeśli jest stosowana.

Wymagania MariaDB

PrestaShop 9 podaje obecnie:

co najmniej MariaDB 10.2

Również tutaj, jeśli to możliwe, przy nowym wdrożeniu produkcyjnym wybierz nowoczesne, wspierane wydanie.

Nie wybieraj między MySQL a MariaDB wyłącznie na podstawie artykułów z benchmarkami.

Ważniejsza jest umiejętność obsługi systemu.

Używaj silnika bazy danych, który twój zespół lub dostawca hostingu potrafi:

• monitorować;
• tworzyć kopie zapasowe;
• przywracać;
• dostrajać;
• bezpiecznie aktualizować.

Wydajność bazy danych to nie tylko numer wersji

Nowoczesna wersja bazy danych nie naprawi złej architektury danych.

Ważne czynniki to:

• rozmiar bufora InnoDB;
• opóźnienia dysku;
• dostępna pamięć RAM;
• monitorowanie wolnych zapytań;
• rozmiary tabel;
• indeksy;
• limity połączeń;
• zachowanie tabel tymczasowych;
• projekt zapytań.

PrestaShop może generować duże ilości danych nawet przy umiarkowanej liczbie produktów.

Jeden produkt może występować w:

• tabelach produktów;
• tabelach językowych;
• tabelach sklepów;
• powiązaniach kategorii;
• tabelach obrazów;
• tabelach cech;
• tabelach atrybutów;
• tabelach magazynowych;
• tabelach specyficznych dla modułów.

Katalog 100 000 produktów może więc obejmować miliony powiązanych wierszy.

Korzystaj z dziennika wolnych zapytań

W dużych sklepach optymalizacja bazy danych powinna opierać się na dowodach.

Włącz i analizuj dziennik wolnych zapytań w kontrolowany sposób.

Szukaj zapytań wykonywanych podczas:

• ładowania kategorii;
• wyszukiwania;
• edycji produktów;
• wyświetlania tabel zamówień;
• importowania;
• synchronizacji stanów magazynowych;
• generowania feedów.

Następnie przeanalizuj je za pomocą:

EXPLAIN

Nie instaluj przypadkowych pakietów indeksów pobranych z Internetu.

Indeks powinien odpowiadać zapytaniu rzeczywiście wykonywanemu przez sklep.

Wymagania Apache

Oficjalna dokumentacja PrestaShop podaje obecnie:

Apache 2.4 lub nowszy

Apache pozostaje w pełni odpowiednią platformą dla PrestaShop.

Serwer WWW powinien obsługiwać wymagane przepisywanie adresów URL i mieć konfigurację umożliwiającą prawidłowe działanie przyjaznych adresów oraz reguł bezpieczeństwa PrestaShop.

Ważne obszary obejmują:

• reguły przepisywania adresów;
• przekierowania HTTPS;
• buforowanie zasobów statycznych;
• limity przesyłania plików;
• limity rozmiaru treści żądań;
• kompresję;
• kontrolę dostępu.

Jeśli używasz Apache z PHP-FPM, monitoruj obie warstwy niezależnie.

Czy PrestaShop 9 działa na Nginx?

Tak.

PrestaShop obsługuje Nginx, a oficjalna dokumentacja dla programistów zawiera zaawansowany przykład konfiguracji Nginx.

Nginx jest często używany do:

• odwrotnego proxy;
• dostarczania zasobów statycznych;
• PHP-FPM;
• terminacji TLS;
• buforowania;
• ograniczania częstotliwości żądań.

W PrestaShop 9 istotnym zagadnieniem jest obsługa obrazów.

Ponieważ PrestaShop 9 obsługuje nowoczesne formaty, takie jak WebP i AVIF, reguły przepisywania i konfiguracja plików statycznych powinny poprawnie obsługiwać te rozszerzenia.

Nie kopiuj starej konfiguracji Nginx dla PrestaShop 1.7 bez jej przeanalizowania.

Apache czy Nginx dla PrestaShop 9

Nie ma jednego uniwersalnego zwycięzcy.

Dobrze skonfigurowany Apache może działać wydajniej niż źle skonfigurowany Nginx i odwrotnie.

Wybierz na podstawie:

• doświadczenia administratora;
• wsparcia dostawcy hostingu;
• narzędzi wdrożeniowych;
• architektury buforowania;
• możliwości monitorowania.

W wielu sklepach największe problemy z wydajnością wcale nie wynikają z serwera WWW.

Powodują je:

• powolne moduły;
• nieefektywny SQL;
• zbyt duże obrazy;
• zbyt wiele procesów PHP;
• ciężkie importy;
• powolne dyski.

Wymagane rozszerzenia PHP

PrestaShop wymaga kilku rozszerzeń PHP do prawidłowego działania.

Oficjalna dokumentacja wyraźnie wymienia następujące rozszerzenia:

• OpenSSL;
• PDO;
• PDO MySQL;
• SimpleXML;
• Zip.

Środowisko hostingowe może również wymagać innych popularnych rozszerzeń używanych przez PrestaShop i moduły.

Na przykład:

• cURL;
• GD;
• Intl;
• Mbstring;
• DOM;
• Fileinfo;
• obsługa JSON zapewniana przez nowoczesne wersje PHP.

Przed instalacją użyj oficjalnego narzędzia do sprawdzania wymagań PrestaShop, zamiast zakładać, że ogólny pakiet PHP zawiera wszystkie potrzebne elementy.

allow_url_fopen

Aktualne oficjalne wymagania PrestaShop 9 określają:

allow_url_fopen = On

PrestaShop korzysta z dostępu do zdalnych plików w niektórych procesach.

Dokumentacja zaleca również:

allow_url_include = Off

Są to różne ustawienia.

allow_url_fopen umożliwia obsługiwanym funkcjom PHP dostęp do zdalnych adresów URL.

allow_url_include pozwala dołączać zdalne pliki przez operacje include w PHP i powinno pozostać wyłączone.

Limity przesyłania plików w PHP

Sklepy importujące produkty, moduły, motywy lub duże pliki danych powinny sprawdzić:

upload_max_filesize
post_max_size
max_execution_time
max_input_time

Nie ustawiaj bezrefleksyjnie wszystkich limitów na ogromne wartości.

W przypadku dużych plików od dostawców CLI jest zwykle lepszym rozwiązaniem niż przesyłanie 1 GB przez Back Office.

Solidny proces pobiera lub odbiera plik od dostawcy w kontrolowany sposób, a następnie przetwarza go partiami.

Konfiguracja procesów PHP-FPM

Jeśli używasz PHP-FPM, jednym z najważniejszych ustawień jest liczba dostępnych procesów roboczych.

Typowe parametry puli obejmują:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

Nie istnieje jedna uniwersalna poprawna wartość.

Zmierz rzeczywiste zużycie pamięci procesów PHP.

Jeśli na przykład zajęty proces zużywa średnio 150 MB, a serwer ma 8 GB RAM, ustawienie 50 procesów PHP byłoby niebezpieczne po uwzględnieniu:

• MySQL;
• Redis;
• system operacyjny;
• serwer WWW;
• zadania cron;
• pamięć podręczna systemu plików.

Wyczerpanie pamięci może spowodować znacznie większe szkody niż krótkie oczekiwanie użytkownika na wolny proces.

OPcache powinien być włączony

Serwer produkcyjny PrestaShop powinien używać PHP OPcache.

OPcache przechowuje skompilowany kod bajtowy PHP w pamięci, dzięki czemu PHP nie musi analizować i kompilować każdego pliku przy każdym żądaniu.

Duża instalacja PrestaShop z wieloma modułami wymaga odpowiedniej ilości pamięci OPcache, by przechowywać przydatny kod.

Monitoruj:

• zużycie pamięci OPcache;
• liczbę skryptów w pamięci podręcznej;
• częstotliwość ponownych uruchomień;
• współczynnik trafień pamięci podręcznej.

Nie wystarczy go włączyć i zakładać, że domyślna konfiguracja jest optymalna.

RAM serwera: ile naprawdę potrzebujesz?

Oficjalne wymagania PrestaShop wskazują, że większa ilość RAM jest korzystna, i zalecają co najmniej 512 MB pamięci na skrypt PHP.

Nie oznacza to jednak, że serwer produkcyjny potrzebuje dokładnie 512 MB całkowitej pamięci RAM.

Przykładowe orientacyjne podejście:

Mały sklep

Mały sklep o niewielkim ruchu może działać z:

• 2–4 GB RAM;
• ograniczoną liczbą procesów PHP;
• niewielką bazą danych;
• niewielką liczbą zadań w tle.

Średni sklep

Bardziej aktywny sklep może skorzystać z:

• 4–8 GB RAM;
• większej liczby procesów PHP;
• większej pamięci podręcznej InnoDB;
• Redis;
• regularnych importów.

Duży katalog lub sklep o dużym ruchu

Sklepy z dużymi katalogami i rozbudowaną automatyzacją mogą potrzebować:

• 8–32 GB RAM lub więcej;
• dedykowanych zasobów bazy danych;
• oddzielnych procesów roboczych do zadań;
• odpowiednio dobranych pul procesów PHP.

Nie są to oficjalne wymagania PrestaShop.

To przykłady planowania zasobów.

Właściwą odpowiedź daje pomiar rzeczywistego obciążenia.

Wymagania CPU

PrestaShop nie wymaga konkretnego modelu procesora.

Liczy się obciążenie.

PHP korzysta z wysokiej wydajności pojedynczego rdzenia, a równoległy ruch i zadania w tle z dodatkowych rdzeni.

Zadania intensywnie obciążające CPU obejmują:

• zmianę rozmiaru obrazów;
• kodowanie AVIF;
• duże importy;
• generowanie feedów;
• indeksowanie wyszukiwania;
• przebudowę pamięci podręcznej;
• przetwarzanie XML.

Jeśli sklep jednocześnie obsługuje klientów i kilka ciężkich importów, dodatkowe rdzenie zapewnią przydatny zapas wydajności.

Dysk: SSD czy NVMe

We współczesnym hostingu PrestaShop dyski SSD należy uznać za podstawowy standard.

NVMe sprawdza się szczególnie przy:

• dużych bazach danych;
• licznych losowych operacjach odczytu i zapisu;
• katalogach z dużą liczbą zdjęć;
• obciążeniach intensywnie korzystających z cache;
• wysokiej współbieżności.

Dyski mechaniczne nadal nadają się do kopii zapasowych lub archiwizacji, ale są słabym wyborem dla aktywnych baz danych e-commerce.

Monitoruj wykorzystanie inode’ów

Instalacje PrestaShop z dużą liczbą zdjęć mogą generować ogromne liczby plików.

Każde zdjęcie produktu może generować kilka wariantów.

Jeśli masz:

100,000 produktów
× 3 obrazów
× 8 typów obrazów

możesz łatwo osiągnąć miliony wygenerowanych plików.

Niektóre plany hostingowe mają limity i-węzłów (inode).

Serwer może wykazywać dużo wolnego miejsca na dysku, a mimo to odmawiać tworzenia plików z powodu wyczerpania limitu inode.

Monitoruj oba wskaźniki:

• pojemność dysku;
• zużycie inode.

Formaty obrazów w PrestaShop 9

PrestaShop 9 wprowadził natywną obsługę:

• WebP;
• AVIF.

Te formaty mogą znacznie zmniejszyć rozmiar przesyłanych obrazów.

Jednak kodowanie AVIF może wymagać większej mocy CPU.

Jeśli ponownie generujesz setki tysięcy obrazów, zaplanuj to jako czynność konserwacyjną lub zadanie CLI, a nie w godzinach szczytu.

Planowanie przestrzeni dyskowej

Nie planuj pojemności dysku wyłącznie na podstawie aktualnego katalogu zdjęć produktów.

Uwzględnij również:

• bazę danych;
• logi;
• pamięć podręczną;
• tymczasowe importy;
• kopie zapasowe;
• wygenerowane miniatury;
• kopie środowisk testowych;
• wydania wdrożeniowe;
• pliki eksportowe.

Bezpieczny serwer potrzebuje wolnego miejsca.

Stałe wykorzystanie dysku na poziomie 90–95% pozostawia mało miejsca na operacje tymczasowe i zwiększa ryzyko awarii.

System operacyjny

Oficjalna dokumentacja PrestaShop podaje, że platforma najlepiej działa w systemach typu Unix, takich jak:

• Linux;
• macOS.

W hostingu produkcyjnym Linux jest typowym wyborem.

Windows może działać w niektórych przypadkach, ale nie jest aktywnie wspierany w takim samym stopniu.

Typowy stos produkcyjny może wykorzystywać:

Linux
Nginx lub Apache
PHP-FPM
MySQL/MariaDB
Redis
Cron/systemd

Czy hosting współdzielony wystarczy?

Hosting współdzielony może wystarczyć do obsługi:

• małego katalogu;
• niewielkiego ruchu;
• minimalnej automatyzacji;
• niewielkiej liczby modułów.

Ograniczenia zwykle stają się widoczne, gdy potrzebujesz:

• długotrwałych zadań CLI;
• własnych ustawień PHP;
• wysokich limitów procesów roboczych;
• Redis;
• dużych importów;
• SSH;
• własnej konfiguracji Nginx;
• nadzoru nad procesami;
• szczegółowego monitoringu.

Oferta hostingu współdzielonego może reklamować dużo miejsca na dysku, jednocześnie mocno ograniczając CPU lub czas procesów.

Sprawdź rzeczywiste limity.

Kiedy wybrać VPS?

VPS przydaje się, gdy potrzebujesz przewidywalnej kontroli nad:

• wersją PHP;
• PHP-FPM;
• konfiguracją bazy danych;
• cronem;
• Redis;
• systemem plików;
• serwerem WWW;
• logami;
• narzędziami bezpieczeństwa.

Dla sklepów z dużymi importami, własnymi modułami lub dziesiątkami tysięcy produktów VPS często okazuje się praktyczniejszy niż ograniczony hosting współdzielony.

Ułatwia też standaryzację środowisk programistycznych i produkcyjnych.

Serwer dedykowany czy infrastruktura chmurowa

Serwer dedykowany lub większe środowisko chmurowe przydaje się, gdy:

• ruch jest stale duży;
• zadania katalogowe są intensywne;
• baza danych jest duża;
• wielu pracowników korzysta z Back Office;
• wymagania dostępności są wysokie.

Nie dziel wszystkiego na mikroserwisy tylko dlatego, że sklep jest duży.

Jeden mocny serwer z dobrze skonfigurowaną bazą danych może być łatwiejszy w utrzymaniu niż niepotrzebnie złożona architektura rozproszona.

Skaluj infrastrukturę wtedy, gdy uzasadniają to pomiary.

Redis i buforowanie

Redis może pomagać w architekturach, które prawidłowo wykorzystują go do:

• pamięci podręcznej;
• sesji;
• kolejek;
• blokad.

Nie jest to uniwersalny przełącznik „przyspiesz PrestaShop”.

Jeśli strona produktu spędza większość czasu na wykonywaniu niezindeksowanego zapytania SQL, Redis nie usunie przyczyny problemu.

Wprowadzaj cache po zmierzeniu, na co zużywany jest czas.

CDN

CDN przydaje się do zasobów statycznych, takich jak:

• zdjęcia produktów;
• CSS;
• JavaScript;
• czcionki.

Korzyści obejmują:

• mniejszy ruch do serwera źródłowego;
• szybsze dostarczanie treści odległym użytkownikom;
• wyższy współczynnik trafień cache;
• mniejsze obciążenie łącza.

CDN nie sprawi jednak, że powolne PHP lub zapytania do bazy danych znikną.

Mierz TTFB osobno od czasu pobierania zasobów.

Dostęp do cron i CLI

W profesjonalnym sklepie PrestaShop dostęp SSH i cron jest niezwykle cenny.

Długotrwałe zadania lepiej wykonywać przez CLI:

php bin/console ...

lub polecenia właściwe dla modułów.

Przykłady:

• importy produktów;
• aktualizacje stanów magazynowych;
• optymalizacja obrazów;
• synchronizacja kategorii;
• generowanie feedów;
• prace porządkowe.

CLI pozwala uniknąć wielu przekroczeń limitu czasu przeglądarki i proxy.

Duże sklepy muszą rozdzielać obciążenia

Jeśli sklep importuje co noc 100 000 produktów, praca w tle konkuruje o zasoby z ruchem klientów.

Lepszy projekt wykorzystuje:

• partie o ograniczonej wielkości;
• kolejki;
• limity procesów roboczych;
• blokady;
• harmonogramy poza godzinami szczytu.

Na przykład:

Ruch WWW → Pula PHP-FPM
Import produktów → Proces roboczy CLI
Przetwarzanie obrazów → Dedykowany proces roboczy
Synchronizacja stanów → Małe, częste zadanie cron
Baza danych → Współdzielony, lecz monitorowany zasób

To zapobiega zajęciu całego serwera przez jedno ogromne zadanie.

Wymagania dotyczące kopii zapasowych

Hosting nie jest kompletny bez kopii zapasowych.

Przechowuj kopie zapasowe:

• bazy danych;
• plików;
• zdjęć produktów;
• konfiguracji modułów;
• konfiguracji środowiska.

Nie przechowuj jedynej kopii zapasowej na tym samym dysku co środowisko produkcyjne.

Awaria dysku nie powinna zniszczyć jednocześnie sklepu i kopii zapasowej.

Testuj przywracanie kopii

Status kopii zapasowej „sukces” dowodzi jedynie, że program utworzył plik.

Nie dowodzi, że da się odtworzyć sklep.

Regularnie przywracaj kopie w środowisku testowym i sprawdzaj:

• import bazy danych;
• obecność obrazów;
• działanie Back Office;
• ładowanie modułów;
• dostępność definicji cron;
• dostępność zmiennych środowiskowych.

HTTPS jest w praktyce obowiązkowy

Produkcyjny sklep internetowy powinien działać w całości przez HTTPS.

Chroni to:

• dane logowania do kont;
• sesje;
• komunikację API;
• dane procesu płatności.

Stosuj nowoczesną konfigurację TLS i automatyzuj odnawianie certyfikatów.

Upewnij się również, że:

• HTTP przekierowuje na HTTPS;
• kanoniczne adresy URL używają HTTPS;
• wewnętrzne odnośniki nie powodują mieszanego ładowania treści.

Dostarczanie e-maili to część hostingu

Potwierdzenia zamówień, resetowanie haseł, wiadomości wsparcia i powiadomienia o koncie wymagają niezawodnego dostarczania e-maili.

Korzystaj z odpowiedniego dostawcy poczty transakcyjnej lub prawidłowo skonfigurowanej usługi SMTP.

Monitoruj:

• błędy dostarczania;
• uwierzytelnianie;
• SPF;
• DKIM;
• DMARC.

Nawet idealny serwer nie wystarczy, jeśli klienci nie otrzymują e-maili z potwierdzeniem zamówienia.

Logi i monitorowanie

Środowisko produkcyjne PrestaShop powinno zapewniać dostęp do:

• logi dostępu Nginx/Apache;
• logi błędów Nginx/Apache;
• błędy PHP;
• logi PrestaShop;
• powolne zapytania do bazy danych;
• metryki systemowe;
• logi cron.

Monitoruj:

• CPU;
• RAM;
• dysk;
• zużycie inode;
• przeciążenie procesów roboczych PHP;
• połączenia z bazą danych;
• błędy HTTP 5xx;
• czas wykonywania zadań.

Bez monitoringu problemy z wydajnością są wykrywane dopiero po skargach klientów.

Wymagania środowiska programistycznego

Jeśli pracujesz z wersją deweloperską PrestaShop zamiast zainstalowanego pakietu produkcyjnego, oficjalna dokumentacja wymienia też narzędzia deweloperskie.

PrestaShop używa Composera do zależności PHP.

Aktualna dokumentacja wskazuje również Node.js 20.x dla odpowiedniego procesu deweloperskiego.

Sprzedawcy instalujący gotowe wydanie PrestaShop zwykle nie muszą samodzielnie kompilować całej platformy.

Twórcy modułów i motywów powinni jednak utrzymywać zgodny zestaw narzędzi programistycznych.

Docker do tworzenia PrestaShop

Docker bywa bardzo przydatny przy programowaniu i testowaniu, ponieważ pozwala jawnie określić wersje.

Środowisko deweloperskie może mieć ustalone wersje:

• PHP;
• MySQL/MariaDB;
• serwera WWW;
• Redis;
• narzędzi do testowania poczty.

Ułatwia to odtwarzanie błędów i testowanie zgodności modułów.

Docker nadaje się także do produkcji, ale konteneryzacja nie sprawia automatycznie, że aplikacja staje się skalowalna.

Nadal potrzebujesz:

• trwałego przechowywania bazy danych;
• strategii tworzenia kopii zapasowych;
• przechowywania obrazów;
• logowania zdarzeń;
• architektury procesów roboczych;
• strategii wdrażania.

Przykładowa architektura małego sklepu produkcyjnego

Mały, lecz profesjonalny sklep mógłby wykorzystywać:

1 VPS
├── Nginx
├── PHP-FPM
├── PrestaShop 9
├── MariaDB/MySQL
├── Redis
└── cron / Procesy robocze CLI

Taka architektura jest prosta i łatwa w diagnozowaniu problemów.

Przykład większej architektury

Większy sklep mógłby rozwinąć się w kierunku:

Równoważnik obciążenia / CDN
        ↓
Serwery aplikacji
        ↓
PHP-FPM
        ↓
Redis
        ↓
Serwer bazy danych
        ↓
Kopia zapasowa / replika

Osobne procesy robocze:
- importy
- obrazów
- kanały danych
- synchronizacja stanów

Nie zaczynaj od takiej architektury, jeśli ruch i operacje nie uzasadniają dodatkowej złożoności.

Lista kontrolna hostingu PrestaShop 9

Przed uruchomieniem sprawdź:

• wybraną dokładną wersję PrestaShop
• ustawioną obsługiwaną wersję PHP
• sprawdzoną wersję PHP serwera WWW
• sprawdzoną wersję PHP w CLI
• sprawdzoną wersję PHP używaną przez cron
• zainstalowane wymagane rozszerzenia PHP
• memory_limit co najmniej 512M w odpowiednich przypadkach
• allow_url_fopen włączone
• allow_url_include wyłączone
• obsługiwaną wersję MySQL/MariaDB
• automatyczne kopie zapasowe bazy danych
• przetestowane przywracanie bazy danych
• magazyn SSD/NVMe
• wystarczającą ilość wolnego miejsca
• monitorowane zużycie inode
• włączony OPcache
• odpowiednio dobraną pulę PHP-FPM
• włączony HTTPS
• przetestowane wiadomości transakcyjne
• dostępny cron
• dostępne SSH/CLI do konserwacji
• dostępne logi serwera WWW
• dostępne logi PHP
• dostępny monitoring powolnych zapytań
• aktywny monitoring systemu

Najczęściej zadawane pytania

Jakiej wersji PHP wymaga PrestaShop 9?

PrestaShop 9.0 obsługuje PHP od 8.1 do 8.4, z zalecaną wersją 8.4. PrestaShop 9.1 obsługuje PHP od 8.1 do 8.5, z zalecaną wersją 8.5 według aktualnej oficjalnej tabeli wymagań.

Czy PrestaShop 9 obsługuje PHP 8.5?

Tak, PrestaShop 9.1 obsługuje PHP 8.5 i obecnie je zaleca. PrestaShop 9.0 nie wymienia PHP 8.5 jako obsługiwanej wersji.

Jaka jest minimalna wersja MySQL dla PrestaShop 9?

Oficjalne minimum to MySQL 5.7. W przypadku nowych wdrożeń zaleca się najnowszą obsługiwaną wersję.

Jaka jest minimalna wersja MariaDB?

Oficjalne minimum to MariaDB 10.2.

Ile pamięci PHP potrzebuje PrestaShop 9?

Oficjalna dokumentacja zaleca minimum memory_limit 512M na skrypt. Sam serwer potrzebuje wystarczająco dużo RAM dla procesów PHP, bazy danych, systemu operacyjnego, cache i zadań w tle.

Czy PrestaShop 9 może działać na Nginx?

Tak. Nginx jest obsługiwany, a PrestaShop udostępnia wskazówki konfiguracji.

Czy 2 GB RAM wystarczą?

Może wystarczyć dla małego sklepu o niewielkim ruchu, przy dobrze ograniczonej liczbie procesów PHP, lecz zapotrzebowanie na zasoby zależy od katalogu, modułów, importów i obciążenia bazy danych.

Czy 8 GB RAM wystarczy dla 100 000 produktów?

Być może, ale sama liczba produktów nie wystarczy do odpowiedzi. Znaczenie mają kombinacje, zdjęcia, ruch, importy, moduły, rozmiar bazy danych i jednoczesne procesy.

Czy potrzebuję Redis?

Nie. Redis może być przydatny do cache, sesji, kolejek lub blokad w odpowiedniej architekturze, ale nie jest obowiązkowy dla każdego sklepu.

Wybrać hosting współdzielony czy VPS?

Hosting współdzielony może się sprawdzić w mniejszych sklepach. VPS jest zwykle praktyczniejszy, gdy trzeba kontrolować PHP, cron, Redis, importy, logi i konfigurację serwera.

Powiązane poradniki i zasoby PrestaShop 9

• poradnik bezpiecznej aktualizacji PrestaShop 8 do 9
• optymalizacja wydajności PrestaShop 9
• poradnik tworzenia modułów PrestaShop 9