Integracja Mailchimp

OPcache to rozszerzenie PHP, które przechowuje skompilowany kod PHP w pamięci, dzięki czemu PHP nie musi go rekompilować przy każdym żądaniu. Zdecydowanie warto go włączyć — może poprawić wydajność PrestaShop o 30–50% bez żadnych negatywnych skutków na produkcji. Większość hostingodawców ma go domyślnie włączonego. Ważne ustawienie to opcache.validate_timestamps: ustaw na 1 w środowisku deweloperskim, ale wiele serwerów produkcyjnych ustawia go na 0 dla maksymalnej wydajności (co oznacza, że musisz ręcznie zresetować OPcache po wdrożeniu zmian w kodzie).

See our full guide on PHP optimization

Jak dzialaja szablony e-mail PrestaShop

PrestaShop wysyla e-maile transakcyjne w kazdym kluczowym momencie sciezki klienta: utworzenie konta, potwierdzenie zamowienia, powiadomienie o wysylce, reset hasla i inne. Te e-maile sa generowane z plikow szablonow przechowywanych na serwerze i sa w pelni konfigurowalne. Zrozumienie dzialania systemu szablonow to pierwszy krok do tworzenia profesjonalnych, markowych e-maili z potwierdzeniem zamowienia, ktore wzmacniaja tozsamosc Twojego sklepu.

Kazdy e-mail PrestaShop sklada sie z dwoch plikow szablonow: wersji HTML dla klientow pocztowych obslugujecych formatowanie oraz wersji tekstowej (TXT) dla klientow, ktore tego nie obsluguja. Oba pliki musza istniec, aby e-mail zostal wyslany poprawnie. Wersje HTML zobaczy zdecydowana wiekszosc klientow. Wersja TXT sluzy jako rozwiazanie awaryjne i jest rowniez uzywana przez narzedzia dostepnosci oraz niektore firmowe filtry pocztowe.

Szablony e-mail znajduja sie w strukturze katalogow mails/. Dokladna lokalizacja zalezy od tego, czy uzywasz e-maili rdzenia, e-maili nadpisanych przez motyw, czy e-maili specyficznych dla modulow. Zrozumienie tej hierarchii jest kluczowe, poniewaz PrestaShop sprawdza wiele lokalizacji dla kazdego szablonu i uzywa pierwszego znalezionego.

Struktura katalogow szablonow e-mail

PrestaShop organizuje szablony e-mail w specyficznej hierarchii katalogow. Gdy musi wyslac e-mail, przeszukuje te lokalizacje w kolejnosci priorytetu:

Nadpisania na poziomie motywu (najwyzszy priorytet)

Szablony w /themes/twoj-motyw/mails/pl/ (gdzie pl to kod ISO jezyka) maja priorytet nad wszystkimi innymi lokalizacjami. Jesli chcesz dostosowac szablon e-mail bez modyfikowania plikow rdzenia, tutaj powinny trafic Twoje niestandardowe szablony. Takie podejscie przetrwa aktualizacje PrestaShop, poniewaz pliki motywu nie sa nadpisywane podczas aktualizacji rdzenia.

Szablony rdzenia (domyslne)

Domyslne szablony znajduja sie w /mails/pl/ w katalogu glownym PrestaShop. Sa to szablony dostarczane z PrestaShop i uzywane, gdy nie istnieje nadpisanie motywu. Bezposrednia edycja tych plikow dziala, ale nie jest zalecana, poniewaz zmiany zostana utracone po aktualizacji PrestaShop.

Szablony specyficzne dla modulow

Moduly wysylajace wlasne e-maile przechowuja szablony w /modules/nazwa-modulu/mails/pl/. Na przyklad e-maile z powiadomieniami o zamowieniach wysylane przez rdzennie moduly platnosci sa przechowywane w ich odpowiednich katalogach modulow. Mozesz je nadpisac, umieszczajac zmodyfikowane kopie w katalogu mails/ motywu z ta sama nazwa pliku.

Podkatalogi jezykowe

Kazdy katalog mails/ zawiera podkatalogi dla kazdego zainstalowanego jezyka, uzywajac kodu ISO jezyka: en dla angielskiego, fr dla francuskiego, de dla niemieckiego i tak dalej. Gdy PrestaShop wysyla e-mail, uzywa szablonu z katalogu odpowiadajacego preferencji jezykowej klienta. Jesli szablon nie istnieje w jezyku klienta, PrestaShop wraca do jezyka domyslnego.

Anatomia szablonu potwierdzenia zamowienia

E-mail z potwierdzeniem zamowienia to najwazniejszy e-mail transakcyjny wysylany przez Twoj sklep. To plik o nazwie order_conf.html (i towarzyszacy mu order_conf.txt) w katalogu mails. Przyjrzyjmy sie jego strukturze.

Struktura szablonu HTML

Szablony e-mail PrestaShop sa samodzielnymi dokumentami HTML. Nie uzywaja zewnetrznych plikow CSS, poniewaz wiekszosc klientow pocztowych usuwa zewnetrzne arkusze stylow. Wszystkie style musza byc inline CSS. Typowy szablon potwierdzenia zamowienia zawiera nastepujace sekcje:

Dokument zaczyna sie od standardowego doctype HTML i sekcji head. Body zawiera uklad oparty na tabelach (poniewaz klienty pocztowe maja slaba obsluge nowoczesnych metod ukladu CSS jak flexbox i grid). W tym ukladzie znajdziesz sekcje naglowka z logo sklepu, glowny obszar tresci ze szczegolami zamowienia, tabele produktow z kazdym zamowionym produktem, podsumowanie cen z sumami czesciowymi i calkowitymi, informacje o wysylce, szczegoly metody platnosci oraz stopke z danymi kontaktowymi sklepu i informacjami prawnymi.

System zmiennych

PrestaShop uzywa prostego systemu zamiany zmiennych w szablonach e-mail. Zmienne sa ujete w nawiasy klamrowe: {nazwa_zmiennej}. Gdy e-mail jest generowany, PrestaShop zastepuje kazda zmienna jej rzeczywista wartoscia. Szablon potwierdzenia zamowienia uzywa tych kluczowych zmiennych:

{firstname} i {lastname} zawieraja imie i nazwisko klienta. {order_name} to numer referencyjny zamowienia (jak ABCDEF123). {shop_name} to nazwa sklepu skonfigurowana w panelu administracyjnym. {shop_url} to adres URL sklepu. {shop_logo} to sciezka do logo sklepu. {date} to data zamowienia. {payment} to uzyta metoda platnosci. {total_paid} to calkowita zaplacona kwota. {delivery_company} i {delivery_address} zawieraja informacje o przewozniku i adresie dostawy.

Dla listy produktow PrestaShop uzywa specjalnej skladni blokowej. Sekcja elementow produktowych jest opakowana w petle, ktora powtarza sie dla kazdego produktu w zamowieniu: {items} zawiera wstepnie sformatowany HTML dla calej tabeli listy produktow, wlaczajac nazwy produktow, ilosci, ceny i wszelkie szczegoly personalizacji.

Referencja dostepnych zmiennych

Aby zobaczyc wszystkie dostepne zmienne dla konkretnego szablonu e-mail, sprawdz kod PHP wysylajacy e-mail. Dla potwierdzenia zamowienia sprawdz klase PaymentModule (w /classes/PaymentModule.php). Metoda validateOrder() buduje tablice zmiennych szablonu. Kazdy klucz w tablicy odpowiada nazwie zmiennej, ktorej mozesz uzyc w szablonie.

Czesto dostepne zmienne w e-mailach potwierdzenia zamowienia obejmuja: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} i {total_products}.

Personalizacja szablonu potwierdzenia zamowienia

Krok 1: Utworz nadpisanie motywu

Nigdy nie edytuj bezposrednio plikow szablonow rdzenia. Zamiast tego skopiuj szablon do katalogu mails motywu:

Skopiuj /mails/pl/order_conf.html do /themes/twoj-motyw/mails/pl/order_conf.html. Zrob to samo dla order_conf.txt. Jesli katalog mails/pl/ nie istnieje w motywu, utworz go.

Jesli Twoj sklep obsluguje wiele jezykow, skopiuj szablony do kazdego katalogu jezykowego. Twoje angielskie potwierdzenie zamowienia trafia do /themes/twoj-motyw/mails/en/order_conf.html i tak dalej.

Krok 2: Modyfikuj uklad HTML

Otworz szablon HTML w edytorze tekstu (nie w edytorze wizualnym, ktory moze dodac niechciany kod). HTML e-mailowy rozni sie od HTML webowego w kilku waznych aspektach:

Uzywaj tabel do ukladu, nie divow. Klienty pocztowe, szczegolnie Outlook, maja bardzo ograniczona obsluge CSS. Uklad trzech kolumn musi uzywac <table> z trzema elementami <td>, nie kolumn CSS czy flexboxa.

Uzywaj stylow inline na kazdym elemencie. Zamiast <p class="heading"> z oddzielnym arkuszem stylow, uzyj <p style="font-size:18px; font-weight:bold; color:#333333;">. Kazdy stylizowany element potrzebuje wlasnego atrybutu stylu inline.

Ustaw jawne szerokosci na tabelach i komorkach. Klienty pocztowe nie zawsze respektuja szerokosci procentowe. Uzyj stalej szerokosci dla glownej tabeli tresci (600 pikseli to standard) z procentowymi kolumnami wewnetrznymi.

Uzywaj bezpiecznych czcionek webowych. Nie wszystkie klienty pocztowe obsluguja niestandardowe czcionki. Trzymaj sie Arial, Helvetica, Georgia, Times New Roman, Verdana lub Trebuchet MS. Mozesz sprobowac zaladowac niestandardowa czcionke jako fallback, ale zawsze okresl bezpieczna czcionke webowa jako koncowy fallback.

Krok 3: Dodaj swoj branding

Zastap domyslny naglowek PrestaShop brandingiem swojego sklepu. Obejmuje to zazwyczaj aktualizacje logo (zmienna {shop_logo} automatycznie uzywa logo sklepu, ale mozesz chciec specjalnej wersji e-mailowej), zmiane koloru tla naglowka na zgodny z marka, dodanie schematu kolorow marki do naglowkow i linkow oraz dolaczenie sloganu sklepu lub krotkiego komunikatu marketingowego.

Utrzymuj ogolna strukture prosta. Zbyt skomplikowane projekty e-maili rozpadaja sie w roznych klientach pocztowych. Czysty, jednokolumnowy uklad z kolorami marki i logo jest bardziej efektywny i niezawodny niz rozbudowany wielokolumnowy projekt.

Krok 4: Dostosuj tabele produktow

Domyslna tabela produktow w potwierdzeniu zamowienia PrestaShop jest funkcjonalna, ale podstawowa. Mozesz ja ulepszyc, dodajac obrazy produktow (uzyj bezwzglednych URL do obrazow hostowanych na serwerze, nie sciezek wzglednych), dodajac linki do stron produktow, aby klienci mogli latwo zamowic ponownie lub zostawic opinie, dodajac niestandardowe pola jak szacowane daty dostawy lub spersonalizowane wiadomosci, oraz dostosowujac styl tabeli do marki.

Dodajac obrazy produktow, utrzymuj je male (50 do 80 pikseli szerokosci) i zawsze dodawaj atrybut alt. Niektore klienty pocztowe domyslnie blokuja obrazy, a tekst alternatywny zapewnia, ze klienci moga nadal zidentyfikowac produkty.

Dodawanie niestandardowych pol do e-maili zamowien

Domyslne zmienne PrestaShop pokrywaja standardowe informacje o zamowieniu, ale mozesz chciec dolaczyc dodatkowe dane jak zdobyte punkty lojalnosciowe, szacowana date dostawy, spersonalizowane podziekowanie lub rekomendacje produktow powiazanych.

Dodawanie zmiennych przez modul

Najczystszym sposobem dodania niestandardowych zmiennych jest modul podlaczajacy sie do procesu wysylania e-maili. Utworz modul rejestrujacy hook actionEmailSendBefore (dostepny od PrestaShop 1.7.6) lub hook actionGetExtraMailTemplateVars. W handlerze hooka dodaj niestandardowe zmienne do tablicy zmiennych szablonu:

Funkcja hooka otrzymuje tablice zmiennych szablonu przez referencje. Mozesz dodac nowe zmienne do tej tablicy i staja sie one dostepne w szablonie przy uzyciu standardowej skladni {nazwa_zmiennej}. Na przyklad po dodaniu loyalty_points do tablicy w hooku, mozesz uzyc {loyalty_points} w szablonie HTML potwierdzenia zamowienia.

Uzywanie istniejacych danych z bazy

Mozesz pobierac dowolne dane z bazy PrestaShop do zmiennych e-mail. Czeste przyklady obejmuja calkowita liczbe zamowien klienta (aby wyswietlic "Dziekujemy za 5. zamowienie!"), saldo punktow lojalnosciowych klienta, niestandardowe pola produktow przechowywane w cechach lub atrybutach produktow oraz informacje o magazynie lub dostawcy zamowionych produktow.

Konfiguracja wielojezyczna e-maili

Jesli Twoj sklep obsluguje klientow w wielu jezykach, kazdy szablon e-mail potrzebuje wersji dla kazdego jezyka. PrestaShop automatycznie wybiera jezyk na podstawie preferencji klienta, ale musisz dostarczyc szablony.

Tworzenie szablonow specyficznych dla jezyka

Dla kazdego jezyka obslugiwanego przez sklep utworz katalog w folderze mails motywu: /themes/twoj-motyw/mails/en/, /themes/twoj-motyw/mails/fr/, /themes/twoj-motyw/mails/de/ i tak dalej. Skopiuj i przetlumacz kazdy plik szablonu do odpowiedniego katalogu.

Nie uzywaj automatycznego tlumaczenia e-maili transakcyjnych. Te e-maile reprezentuja komunikacje sklepu z klientami, a slabe tlumaczenia podkopuja zaufanie. Kazda wersje jezykowa powinna napisac lub sprawdzic native speaker.

Obsluga jezykow od prawej do lewej

Jesli obslugiwane sa jezyki takie jak arabski lub hebrajski, szablony e-mail potrzebuja wsparcia RTL (od prawej do lewej). Dodaj dir="rtl" do glownego elementu tabeli i dostosuj wyrownanie tekstu oraz padding w stylach inline. Utworz oddzielne szablony dla jezykow RTL zamiast probowac uzywac jednego szablonu dla obu kierunkow.

Formatowanie dat i walut

PrestaShop automatycznie formatuje daty i wartosci walut zgodnie z ustawieniami jezyka i waluty klienta. Zmienne {date}, {total_paid} i inne sformatowane wartosci juz odzwierciedlaja prawidlowa lokalizacje. Jednak jesli dodajesz niestandardowe zmienne z datami lub wartosciami walut, upewnij sie, ze sa prawidlowo sformatowane dla jezyka docelowego.

Konfiguracja SMTP dla niezawodnej dostarczalnosci

Najlepszy szablon e-mail na swiecie jest bezuzyteczny, jesli e-maile nie docieraja do skrzynki odbiorczej. Domyslna konfiguracja e-mail PrestaShop uzywa wbudowanej funkcji PHP mail(), ktora jest nieniezawodna dla e-maili transakcyjnych. Wiekszosc tych e-maili trafia do folderu spam lub jest calkowicie odrzucana przez nowoczesnych dostawcow poczty.

Dlaczego SMTP jest wazne

SMTP (Simple Mail Transfer Protocol) z odpowiednia autoryzacja jest kluczowe dla dostarczalnosci e-maili. Gdy wysylasz e-maile przez funkcje PHP mail(), e-mail pochodzi z adresu IP serwera bez zadnej autoryzacji. Dostawcy poczty jak Gmail, Outlook i Yahoo widza to jako sygnial ostrzegawczy i czesto klasyfikuja takie e-maile jako spam.

Z SMTP e-maile sa wysylane przez uwierzytelniony serwer pocztowy z odpowiednimi rekordami SPF, DKIM i DMARC. To dowodzi serwerom pocztowym, ze e-mail jest legalny i autoryzowany przez Twoja domene.

Konfiguracja SMTP w PrestaShop

Przejdz do Zaawansowane > E-mail w panelu administracyjnym PrestaShop. Zmien metode z "Uzyj funkcji mail() PHP" na "Ustaw wlasne parametry SMTP". Wprowadz dane serwera SMTP: adres serwera, port (typowo 587 dla TLS lub 465 dla SSL), typ szyfrowania, nazwe uzytkownika i haslo.

Popularni dostawcy SMTP dla PrestaShop obejmuja Gmail SMTP (smtp.gmail.com, port 587, TLS, wymaga hasla aplikacji przy wlaczonym 2FA), Amazon SES (przystepny cenowo dla duzych wolumenow), SendGrid (hojny darmowy plan), Mailgun (przyjazny dla programistow z dobrym logowaniem) oraz serwer SMTP Twojego dostawcy hostingu (sprawdz ustawienia u swojego hosta).

Testowanie konfiguracji SMTP

Po skonfigurowaniu SMTP uzyj przycisku "Wyslij testowy e-mail" na dole strony konfiguracji e-mail. Wprowadz wlasny adres e-mail i sprawdz, czy testowy e-mail dotarl do skrzynki (nie do spamu). Jesli testowy e-mail nie dotarl, sprawdz dane SMTP, upewnij sie, ze serwer moze polaczyc sie z serwerem SMTP na skonfigurowanym porcie (niektore firmy hostingowe blokuja porty wychodzace 25 i 587) oraz sprawdz, czy dostawca SMTP wymaga okreslonych ustawien bezpieczenstwa.

Rekordy SPF, DKIM i DMARC

Dla maksymalnej dostarczalnosci skonfiguruj te rekordy DNS dla swojej domeny. SPF (Sender Policy Framework) okresla, ktore serwery sa uprawnione do wysylania e-maili w imieniu domeny. DKIM (DomainKeys Identified Mail) dodaje podpis cyfrowy do e-maili potwierdzajacy, ze zostaly wyslane z Twojej domeny. DMARC (Domain-based Message Authentication, Reporting, and Conformance) informuje serwery odbiorcze, co robic z e-mailami niespelniajacymi sprawdzen SPF lub DKIM.

Dostawca SMTP dostarczy konkretne rekordy DNS do dodania. Na przyklad przy korzystaniu z SendGrid otrzymasz rekordy SPF i DKIM podczas procesu uwierzytelniania domeny. Dodaj je jako rekordy TXT w ustawieniach DNS domeny.

Testowanie szablonow e-mail

Wysylanie testowych e-maili

PrestaShop nie ma wbudowanej opcji podgladu konkretnych szablonow e-mail. Aby przetestowac szablon potwierdzenia zamowienia, musisz zlozyc prawdziwe zamowienie testowe. Utworz testowe konto klienta, dodaj produkty do koszyka i sfinalizuj zamowienie testowa metoda platnosci. Jesli masz skonfigurowany modul platnosci sandbox, uzyj go. W przeciwnym razie metody platnosci przelewem bankowym lub czekiem pozwalaja sfinalizowac zamowienie bez rzeczywistego przetwarzania platnosci.

Testowanie w roznych klientach pocztowych

Renderowanie e-maili dramatycznie rozni sie miedzy klientami pocztowymi. To co wyglada idealnie w Gmail, moze byc uszkodzone w Outlooku. Przetestuj szablony co najmniej w Gmail (web), Outlook (desktop i web), Apple Mail, Yahoo Mail i przynajmniej jednej mobilnej aplikacji pocztowej. Uslugi jak Litmus lub Email on Acid automatyzuja to testowanie, renderujac e-mail w dziesieciach klientow pocztowych jednoczesnie, ale sa to uslugi platne.

Czeste problemy z renderowaniem

Jesli e-mail wyglada zle w Outlooku, jest to prawie na pewno problem CSS. Outlook uzywa silnika renderowania Microsoft Word dla e-maili HTML, ktory ma niezwykle ograniczona obsluge CSS. Nie obsluguje obrazow tla na komorkach tabeli (uzyj kolorow tla), paddingu na elementach blokowych (uzyj paddingu komorek tabeli), max-width (uzyj stalych szerokosci), margin do centrowania (uzyj align="center" na tabelach) ani CSS float.

Dla responsywnosci mobilnej opakuj tabele tresci w kontener z max-width:600px i dodaj media query w bloku stylu head (obslugiwana przez niektore klienty pocztowe), ktora ustawia szerokosci tabel na 100% na malych ekranach. To nie jest idealny responsywny design, ale zapobiega przewijaniu poziomemu na wiekszosci urzadzen mobilnych.

Czeste problemy i rozwiazywanie

Brakujace obrazy w e-mailach

To najczestszy problem z szablonami e-mail. Obrazy w e-mailach musza uzywac bezwzglednych URL (zaczynajacych sie od https://), nie sciezek wzglednych. Jesli szablon odwoluje sie do /img/logo.png, zmien na https://www.twojadomena.pl/img/logo.png. Zmienna {shop_logo} automatycznie generuje bezwzgledny URL, ale wszystkie obrazy dodane recznie musza uzywac pelnych URL.

Sprawdz rowniez, czy obrazy sa dostepne spoza sieci. Jesli sklep jest za zapora lub uwierzytelnianiem HTTP, klienty pocztowe nie moga zaladowac obrazow. Przetestuj otwierajac URL obrazu w prywatnym oknie przegladarki.

Uszkodzony uklad po edycji

HTML e-mailowy jest kruchy. Pojedynczy niezamkniety tag lub brakujaca komorka tabeli moze zniszczyc caly uklad. Zawsze waliduj HTML po edycji. Policz otwierajace i zamykajace tagi table, tr i td. Kazdy <table> potrzebuje </table>, kazdy <tr> potrzebuje </tr>, a kazdy <td> potrzebuje </td>. Upewnij sie, ze kazdy wiersz w tabeli ma taka sama liczbe komorek (lub uzywa colspan).

Zmienne nie sa zastepowane

Jesli w wyslanych e-mailach widzisz literalny tekst {nazwa_zmiennej} zamiast rzeczywistych wartosci, sprawdz nazwe zmiennej pod katem literowek. Nazwy zmiennych sa wrazliwe na wielkosc liter. Sprawdz rowniez, czy zmienna istnieje dla konkretnego typu e-maila. Nie wszystkie zmienne sa dostepne we wszystkich szablonach. Zmienne specyficzne dla zamowien jak {order_name} sa dostepne tylko w e-mailach zwiazanych z zamowieniami.

E-maile nie sa wysylane

Jesli e-maile nie sa wysylane, sprawdz panel administracyjny PrestaShop w Zaawansowane > E-mail. Mozesz tam zobaczyc dziennik wyslanych e-maili. Jesli dziennik pokazuje bledy, sprawdz konfiguracje SMTP. Jesli zaden e-mail nie pojawia sie w dzienniku, e-mail moze nie byc w ogole wyzwalany. Sprawdz, czy przejscia statusow zamowien sa skonfigurowane do wysylania e-maili (Zamowienia > Statusy > edytuj status > zaznacz "Wyslij e-mail do klienta").

Sprawdz rowniez dziennik bledow PHP serwera pod katem bledow zwiazanych z e-mailami. Czeste problemy to wylaczona funkcja PHP mail() przez dostawce hostingu, bledy uwierzytelniania SMTP z powodu zmienionego hasla oraz problemy z polaczeniem sieciowym miedzy serwerem a serwerem SMTP.

E-maile trafiaja do spamu

Nawet przy poprawnej konfiguracji SMTP e-maile moga nadal trafiac do spamu. Najczestsze przyczyny to brakujace lub nieprawidlowe rekordy SPF/DKIM/DMARC, tresc e-maila wyzwalajaca filtry spam (nadmierne uzycie duzych liter, slowa wyzwalajace spam jak "za darmo" czy "dzialaj teraz", zbyt duzo obrazow z mala iloscia tekstu), wysylanie z adresu IP o zlej reputacji (czeste przy hostingu wspoldzielonym) oraz domena adresu nadawcy niezgodna z domena serwera SMTP.

Najpierw napraw rekordy DNS, potem przejrzyj tresc e-maili. Uzyj narzedzia takiego jak mail-tester.com do analizy e-maili pod katem wyzwalaczy spamu. Wyslij testowy e-mail na podany adres, a otrzymasz szczegolowy raport pokazujacy, co moze powodowac klasyfikacje jako spam.

Nadpisania e-maili specyficzne dla motywu

Niektore motywy PrestaShop zawieraja wlasne szablony e-mail pasujace do designu motywu. Jesli motyw ma szablony w /themes/twoj-motyw/mails/, automatycznie nadpisuja one szablony rdzenia.

Sprawdzanie szablonow e-mail motywu

Sprawdz w katalogu aktywnego motywu, czy istnieje folder mails. Jesli istnieje, motyw dostarcza niestandardowe szablony e-mail. Te szablony zazwyczaj pasuja do schematu kolorow i designu naglowka/stopki motywu, zapewniajac wizualna spojnosc e-maili z witryma sklepu.

Dostosowywanie szablonow e-mail motywu

Jesli motyw dostarcza szablony e-mail, edytuj te zamiast kopiowac z katalogu mails/ rdzenia. Szablony motywu moga uzywac innej struktury HTML lub zawierac dodatkowe CSS specyficzne dla systemu designu motywu. Rozpoczecie od wersji motywu zapewnia wizualna spojnosc.

Synchronizacja szablonow z aktualizacjami motywu

Aktualizujac motyw, sprawdz czy aktualizacja zawiera zmiany w szablonach e-mail. Jesli tak, Twoje dostosowania moga zostac nadpisane. Przed aktualizacja zrob kopie zapasowa dostosowanych szablonow. Po aktualizacji porownaj nowe szablony z kopiami i ponownie zastosuj dostosowania do zaktualizowanych wersji. Jest to zmdune, ale konieczne, aby zachowac zarowno dostosowania, jak i ewentualne ulepszenia lub poprawki dewelopera motywu.

Dobre praktyki dla e-maili potwierdzenia zamowienia

Dobrze zaprojektowany e-mail z potwierdzeniem zamowienia robi wiecej niz tylko potwierdza transakcje. Buduje zaufanie, zmniejsza liczbe zapytan do obslugi klienta i tworzy mozliwosci zaangazowania.

Umiesc wyraznie widoczny numer referencyjny zamowienia na gorze. Klienci potrzebuja tego numeru kontaktujac sie z obsluga lub sledzac zamowienie. Wymien kazdy produkt z nazwa, iloscia, cena i wszelkimi opcjami lub personalizacjami. Dolacz pelne zestawienie sumy czesciowej, kosztow wysylki, podatkow, rabatow i sumy calkowitej. Pokaz adres dostawy, aby klienci mogli go zweryfikowac i natychmiast skontaktowac sie w razie bledu. Podaj uzyta metode platnosci i odpowiednie szczegoly transakcji. Udostepnij link do strony sledzenia zamowienia lub historii zamowien w koncie klienta. Dodaj dane kontaktowe obslugi klienta, aby wiedzieli jak sie skontaktowac w razie problemow.

Utrzymuj design czysty i przyjazny dla urzadzen mobilnych. Ponad polowa wszystkich e-maili jest czytana na urzadzeniach mobilnych. Uzyj jednokolumnowego ukladu, duzego czytelnego tekstu (minimum 14px dla tresci) i przyciskow z odpowiednimi celami dotykowymi (minimum 44px wysokosci). E-mail z potwierdzeniem zamowienia odzwierciedla profesjonalizm sklepu. Zainwestuj czas, aby zrobic to dobrze.

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

Lazy Loading w 2026: co przeglądarki obsługują natywnie, a co wymaga modułu

Lazy loading to technika optymalizacji wydajności, która odwleka ładowanie zasobów poza ekranem do momentu, gdy użytkownik przewinie w ich pobliże. W 2026 roku natywne wsparcie przeglądarek dla lazy loadingu znacząco dojrzało, ale wciąż istnieją scenariusze, w których właściciele sklepów PrestaShop potrzebują dodatkowych modułów lub niestandardowych implementacji. Ten przewodnik wyjaśnia dokładnie, co przeglądarki obsługują samodzielnie, jakie luki pozostają i jak wdrożyć najlepszą strategię lazy loading dla Twojego sklepu PrestaShop.

Co natywny lazy loading obejmuje w 2026

Atrybut HTML loading="lazy" jest teraz obsługiwany przez ponad 95% przeglądarek na świecie. Obejmuje to Chrome (od v77), Firefox (od v75), Safari (od v15.4), Edge (od v79) i wszystkie przeglądarki oparte na Chromium.

Jak działa natywny lazy loading

Dodanie loading="lazy" do tagu <img> lub <iframe> mówi przeglądarce, aby odroczyła ładowanie tego zasobu do momentu, gdy znajdzie się w określonej odległości od viewportu.

<img src="obraz-produktu.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nazwa produktu">

Co przeglądarki obsługują natywnie

Czego przeglądarki NIE obsługują

Implementacja natywnego lazy loadingu w PrestaShop

Dla motywów PrestaShop 8.x i 9.x

Nowoczesne motywy PrestaShop (jak Hummingbird dla PS 9) często zawierają natywny lazy loading domyślnie. Aby zweryfikować lub dodać go do swojego motywu, edytuj pliki szablonów.

{* Przed - bez lazy loadingu *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Po - z natywnym lazy loadingiem *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Krytyczna zasada: nigdy nie stosuj lazy loading do obrazów above-the-fold

Najczęstszym błędem lazy loadingu jest stosowanie go do obrazów widocznych bez przewijania. To w rzeczywistości pogarsza wydajność, ponieważ przeglądarka opóźnia ładowanie treści, które użytkownik widzi natychmiast.

Obrazy, które NIE powinny być lazy ładowane:

• Logo Twojego sklepu
• Obrazy hero/baner na górze strony
• Pierwsze 1-2 obrazy produktów na stronach kategorii

<img src="hero-baner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Baner letniej wyprzedaży">

Kiedy potrzebujesz modułu: obrazy tła CSS

Motywy PrestaShop często używają obrazów tła CSS dla sliderów, banerów i nagłówków kategorii. Atrybut loading="lazy" nie działa dla teł CSS.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Kiedy potrzebujesz modułu: efekty placeholder

• Efekt blur-up (LQIP) - Załaduj najpierw małą, rozmytą wersję
• Ekrany szkieletowe - Szare bloki placeholder odpowiadające wymiarom
• Placeholdery dominującego koloru - Użyj dominującego koloru obrazu jako tła

Wpływ na wydajność PrestaShop i Core Web Vitals

• LCP - Lazy loading obrazów above-the-fold POGARSZA LCP
• CLS - Obrazy bez atrybutów width/height powodują przesunięcia układu
• INP - Mniej jednocześnie ładowanych zasobów poprawia interaktywność

<!-- ŹLE - powoduje przesunięcie układu -->
<img src="produkt.jpg" loading="lazy" alt="Produkt">

<!-- DOBRZE - rezerwuje miejsce -->
<img src="produkt.jpg" loading="lazy" 
     width="400" height="400" alt="Produkt">

Rekomendacje specyficzne dla PrestaShop

Strony z listą produktów

Lazy ładuj wszystkie obrazy produktów oprócz pierwszego rzędu. Zastosuj fetchpriority="high" do pierwszego rzędu.

Strony szczegółów produktu

Główny obraz produktu powinien być ładowany eager z fetchpriority="high". Miniatury galerii mogą być lazy ładowane.

Strona główna

Obrazy slidera above the fold powinny być ładowane eager. Bloki modułów below the fold powinny używać lazy loadingu.

Podsumowanie: Moduł vs. Natywny

Limitowanie zapytan i ochrona przed botami w PrestaShop bez WAF

Boty stanowia ponad 40% calego ruchu w sieci w 2026. Ten przewodnik pokazuje jak wdrozyc skuteczna ochrone za pomoca konfiguracji serwera, regul .htaccess i lekkich modulow.

Metoda 1 - Rate Limiting Apache .htaccess

RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Metoda 2 - Rate Limiting Nginx

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

Metoda 3 - fail2ban przeciw brute force

fail2ban monitoruje logi serwera i automatycznie blokuje IP z zlosliwym zachowaniem.

Metoda 4 - Rate Limiting na poziomie PHP

Dla hostingu wspoldzielonego: plikowy rate limiter w PHP.

Metoda 5 - robots.txt i kontrola crawlowania

User-agent: SemrushBot
Crawl-delay: 10

Metoda 6 - CAPTCHA na krytycznych formularzach

Dodaj reCAPTCHA na logowaniu, rejestracji, formularzu kontaktowym i newsletterze.

Metoda 7 - Cloudflare Free

Browser Integrity Check, Bot Fight Mode i Rate Limiting sa dostepne za darmo.

Podsumowanie warstw ochrony

Przekierowania .htaccess w PrestaShop: pisanie regul bez psucia sklepu

Plik .htaccess jest jednym z najpotezniejszych i najbardziej niebezpiecznych plikow w Twojej instalacji PrestaShop. Jeden zle umieszczony znak moze wylaczyc caly Twoj sklep. Ale opanowanie przekierowan .htaccess jest niezbedne dla SEO.

Jak PrestaShop uzywa .htaccess

PrestaShop automatycznie generuje i zarzadza plikiem .htaccess. Gdy wlaczysz przyjazne URLe w ustawieniach SEO i URLe, PrestaShop zapisuje reguly przepisywania miedzy dwoma komentarzami znacznikowymi.

Krytyczna zasada - Nigdy nie dodawaj niestandardowych przekierowan wewnatrz tego bloku. PrestaShop nadpisze je przy nastepnej regeneracji. Umieszczaj swoje reguly PRZED blokiem PrestaShop.

Typy przekierowan

301 - Przekierowanie stale

Uzywaj gdy strona zostala trwale przeniesiona. Wyszukiwarki przenoszą wartosc SEO na nowy URL.

302 - Przekierowanie tymczasowe

Uzywaj gdy strona jest tymczasowo niedostepna.

410 - Gone (Usuniety)

Uzywaj gdy strona zostala trwale usunieta bez zamiennika.

Podstawowa skladnia przekierowan

# Przekieruj pojedynczy URL
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# Przekieruj stary URL produktu
Redirect 301 /stary-produkt.html https://twojsklep.com/pl/nowy-produkt.html

Przekierowania oparte na wzorcach z RewriteRule

RewriteEngine On
RewriteRule ^stary-folder/(.*)$ https://twojsklep.com/nowy-folder/$1 [R=301,L]

Typowe scenariusze przekierowan PrestaShop

Scenariusz 1 - Migracja z innej platformy

# WooCommerce do PrestaShop
RewriteRule ^product/stary-slug/?$ https://twojsklep.com/pl/nowy-url.html [R=301,L]

Scenariusz 2 - Wymuszenie HTTPS i WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Reguly ktore moga zepsuc PrestaShop

Nieskonczone petle przekierowan

Najniebezpieczniejszy blad. Zawsze uzywaj warunkow do zapobiegania petlom.

# NIEBEZPIECZNE
RewriteRule ^(.*)$ https://twojsklep.com/$1 [R=301,L]

# BEZPIECZNE
RewriteCond %{HTTP_HOST} !^www\.twojsklep\.com$ [NC]
RewriteRule ^(.*)$ https://www.twojsklep.com/$1 [R=301,L]

Psucie dostepu do back office

# BEZPIECZNE - wyklucz admin i API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteCond %{REQUEST_URI} !^/modules [NC]
RewriteRule ^(.*)$ https://twojsklep.com/pl/$1 [R=301,L]

Bezpieczne testowanie przekierowan

# Zawsze najpierw zrob kopie
cp .htaccess .htaccess.backup

# Testuj z curl
curl -I -L https://twojsklep.com/stara-strona.html

Gdzie umieszczac niestandardowe reguly

# TWOJE PRZEKIEROWANIA TUTAJ (przed blokiem PrestaShop)
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# ~~start~~ Blok PrestaShop
# ... automatycznie generowane reguly ...
# ~~end~~ Blok PrestaShop

Kiedy uzywac modulu

Rozwaz modul przekierowan gdy nietechniczny personel musi zarzadzac przekierowaniami, masz setki przekierowan lub potrzebujesz automatycznego wykrywania 404.

Macierz kompatybilności wersji PHP dla PrestaShop

Wybór odpowiedniej wersji PHP dla Twojego sklepu PrestaShop to jedna z najważniejszych decyzji infrastrukturalnych, jakie podejmiesz. Uruchomienie niekompatybilnej wersji PHP może spowodować białe ekrany, niedziałające procesy płatności, awarie modułów i luki w zabezpieczeniach. Ten kompleksowy przewodnik obejmuje każdą wersję PrestaShop od 1.6 do 9.x i przyporządkowuje każdą z nich do obsługiwanych wersji PHP, zalecanych konfiguracji i kwestii aktualizacji.

Dlaczego wersja PHP ma znaczenie dla PrestaShop

PHP to serwerowy język programowania, który napędza PrestaShop. Każda główna wersja PHP wprowadza poprawki wydajności, nowe funkcjonalności języka i wycofuje starsze funkcje. Kod źródłowy PrestaShop ewoluuje równolegle z PHP, co oznacza, że nowsze wersje PrestaShop wykorzystują nowoczesne funkcje PHP, jednocześnie rezygnując ze wsparcia dla przestarzałych wersji.

Używanie niewłaściwej wersji PHP powoduje trzy kategorie problemów:

• Błędy fatalne - Funkcje usunięte w nowszych wersjach PHP (np. funkcje mysql_* usunięte w PHP 7.0, each() usunięta w PHP 8.0) powodują natychmiastowe awarie.
• Ostrzeżenia o wycofaniu - Wycofane funkcje generują ostrzeżenia, które mogą uszkodzić odpowiedzi AJAX, wyjście JSON i generowanie PDF, gdy display_errors jest włączone.
• Narażenie na zagrożenia bezpieczeństwa - Wersje PHP, które osiągnęły koniec życia, nie otrzymują już łatek bezpieczeństwa, pozostawiając Twój sklep podatnym na ataki.

Pełna macierz kompatybilności

PrestaShop 1.6.x

Zalecane PHP dla 1.6.x - PHP 7.1. Oferuje najlepszą równowagę między wydajnością a kompatybilnością. Uruchamianie 1.6.x na PHP 7.2+ wymaga modyfikacji plików rdzeniowych, co przerywa ścieżkę aktualizacji i nie jest zalecane.

PrestaShop 1.7.x

Krytyczne ostrzeżenie - Żadna wersja PrestaShop 1.7 nie obsługuje PHP 8.0 ani nowszego. Jeśli uruchomisz PS 1.7.6 na PHP 8, Smarty natychmiast się zawiesi, ponieważ silnik szablonów używa funkcji usuniętych w PHP 8.0. Usunięcie funkcji each() i zmiany w działaniu array_key_exists() z obiektami powodują błędy fatalne.

PrestaShop 8.x

Zalecane PHP dla 8.x - PHP 8.1. Jest to optimum oferujące pełną kompatybilność, aktywne wsparcie bezpieczeństwa i doskonałą wydajność z kompilacją JIT. PHP 8.1 wprowadza Fibers, Enums, właściwości readonly i typy intersection, z których PrestaShop 8 może korzystać.

PrestaShop 9.x

Zalecane PHP dla 9.x - PHP 8.3 lub 8.4. PrestaShop 9 działa na Symfony 6.4 LTS i wymaga PHP 8.1 jako minimum. PHP 8.4 wprowadza Property Hooks i asymetryczną widoczność, które przyszłe aktualizacje PrestaShop będą wykorzystywać.

Daty zakończenia wsparcia PHP, które musisz znać

Jeśli w 2026 roku używasz PHP 7.4 lub 8.0, pracujesz na niewspieranej wersji, która nie otrzymuje już poprawek bezpieczeństwa. Jest to krytyczne ryzyko dla każdego sklepu e-commerce obsługującego dane płatnicze.

Jak sprawdzić aktualną wersję PHP

Metoda 1 - Panel administracyjny PrestaShop

Przejdź do Zaawansowane > Informacje. Sekcja Informacje o serwerze wyświetla Twoją wersję PHP wraz z limitem pamięci, maksymalnym czasem wykonania i innymi istotnymi ustawieniami.

Metoda 2 - Plik PHP Info

Utwórz plik o nazwie phpinfo.php w katalogu głównym sklepu o następującej treści:

<?php phpinfo();

Uzyskaj do niego dostęp przez przeglądarkę pod adresem https://twojsklep.com/phpinfo.php. Usuń ten plik natychmiast po sprawdzeniu - ujawnia wrażliwe szczegóły konfiguracji serwera.

Metoda 3 - Linia poleceń

php -v
php -r "echo PHP_VERSION;"

Pamiętaj, że wersja PHP CLI może różnić się od wersji PHP serwera web. Zawsze weryfikuj przez interfejs webowy lub phpinfo().

Typowe problemy przy nieprawidłowej wersji PHP

Biały ekran śmierci (WSOD)

Najczęstszy objaw niekompatybilności PHP. Sprawdź log błędów PHP (zazwyczaj pod /var/log/php-errors.log lub dostępny przez panel hostingowy). Typowe błędy to:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Ostrzeżenia o wycofaniu psują AJAX

Gdy display_errors = On i aktualizujesz PHP, ostrzeżenia o wycofaniu są dołączane do odpowiedzi AJAX. To psuje parsowanie JSON w panelu administracyjnym, powodując ciche awarie funkcji takich jak wyszukiwanie produktów, wyszukiwanie klientów i tworzenie zamówień. Rozwiązanie:

; php.ini
display_errors = Off
log_errors = On
error_log = /sciezka/do/php-error.log

Niekompatybilność modułów

Moduły firm trzecich mogą nie obsługiwać Twojej wersji PHP. Przed aktualizacją PHP sprawdź kompatybilność każdego zainstalowanego modułu. Typowe problematyczne obszary:

• Moduły używające create_function() - usunięta w PHP 8.0
• Moduły używające funkcji mysql_* - usunięte w PHP 7.0
• Moduły używające pozycyjnego dostępu do ciągów z nawiasami klamrowymi $str{0} - usunięte w PHP 8.0
• Moduły nieobsługujące nullable typów zwracanych - bardziej restrykcyjne od PHP 8.1+

Jak bezpiecznie zaktualizować PHP dla PrestaShop

Krok 1 - Audyt aktualnej konfiguracji

Zanim cokolwiek zmienisz, udokumentuj swoje obecne środowisko:

php -v                    # Aktualna wersja PHP
php -m                    # Załadowane rozszerzenia
php -i | grep memory      # Limit pamięci
php -i | grep max_exec    # Limit czasu wykonania

Krok 2 - Sprawdź kompatybilność modułów

Przejrzyj każdy zainstalowany moduł. Sprawdź dokumentację dewelopera modułu pod kątem obsługi wersji PHP. Jeśli moduł nie był aktualizowany od ponad dwóch lat, prawdopodobnie jest niekompatybilny z PHP 8.x.

Krok 3 - Najpierw przetestuj na stagingu

Nigdy nie aktualizuj PHP na serwerze produkcyjnym bez testów. Utwórz kopię staging swojego sklepu i przetestuj z nową wersją PHP. Sprawdź:

• Strony front office ładują się prawidłowo
• Strony produktów, kategorii, strony CMS
• Proces koszyka i zamówienia kończy się poprawnie
• Moduły płatności przetwarzają transakcje testowe
• Funkcjonalność back office działa (edycja produktów, zarządzanie zamówieniami)
• Wszystkie moduły firm trzecich działają prawidłowo
• Zadania cron wykonują się bez błędów

Krok 4 - Aktualizacja z planem wycofania

Większość dostawców hostingu pozwala na zmianę wersji PHP z panelu sterowania (cPanel, Plesk, DirectAdmin). Zachowaj poprzednią wersję PHP dostępną do szybkiego wycofania, jeśli pojawią się problemy.

Krok 5 - Wyczyść wszystkie cache po aktualizacji

Po zmianie wersji PHP wyczyść każdą warstwę cache:

# Wyczyść cache PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Wyczyść skompilowane szablony Smarty
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Jeśli używasz OPcache, uruchom ponownie PHP-FPM
systemctl restart php8.3-fpm

# Wyczyść cache CDN (Cloudflare, itp.)

Najlepsze praktyki konfiguracji PHP dla PrestaShop

Niezależnie od wybranej wersji PHP, te ustawienia są niezbędne dla optymalnej wydajności PrestaShop:

; Zalecane ustawienia php.ini
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Ustawienia OPcache (krytyczne dla wydajności)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Wymagane rozszerzenia
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Uwagi dla deweloperów modułów

Jeśli rozwijasz moduły PrestaShop, musisz starannie rozważyć kompatybilność PHP:

• Minimalna wersja PHP - Celuj w PHP 7.2 jako minimum dla modułów, które powinny działać na PrestaShop 8.0+, lub PHP 8.1 dla modułów przeznaczonych wyłącznie dla PrestaShop 9.
• Używaj PHPStan lub Psalm - Narzędzia analizy statycznej wykrywają niekompatybilności wersji PHP, zanim zrobią to Twoi użytkownicy.
• Unikaj składni specyficznej dla wersji - Funkcjonalności takie jak wyrażenia match (PHP 8.0), enums (PHP 8.1) i właściwości readonly (PHP 8.1) ograniczają Twój moduł do tych wersji PHP i wyższych.
• Testuj na wielu wersjach - Używaj kontenerów Docker z różnymi wersjami PHP, aby testować moduł na całym zakresie kompatybilności.

Często zadawane pytania

Czy mogę uruchomić PrestaShop 1.7 na PHP 8?

Nie. Żadna wersja PrestaShop 1.7 oficjalnie nie obsługuje PHP 8.0 ani nowszego. Chociaż niektórzy użytkownicy zastosowali łatki, aby częściowo to uruchomić, nie jest to wspierane i będzie powodować problemy przy aktualizacjach. Właściwą drogą jest migracja do PrestaShop 8.x.

Czy powinienem używać PHP 8.4 z PrestaShop 8.1?

Niezalecane. PrestaShop 8.1 został opracowany i przetestowany głównie z PHP 8.1. Chociaż PHP 8.2 jest częściowo obsługiwany w późniejszych wersjach 8.1.x, PHP 8.4 wprowadza zmiany, które mogą powodować problemy ze starszymi komponentami Symfony. Pozostań przy PHP 8.1 dla PrestaShop 8.x.

O ile szybszy jest PHP 8.x w porównaniu z 7.x?

Benchmarki pokazują, że PHP 8.1 jest około 20-30% szybszy niż PHP 7.4 dla typowych obciążeń PrestaShop. Kompilator JIT zapewnia największą korzyść przy zadaniach obliczeniowych. Dla operacji związanych z I/O (zapytania do bazy danych, odczyt plików) poprawa jest mniejsza, ale nadal mierzalna.

Czy aktualizacja PHP wymaga aktualizacji PrestaShop?

Niekoniecznie, ale obie rzeczy idą w parze. Możesz zaktualizować PHP w obsługiwanym zakresie dla swojej wersji PrestaShop bez aktualizacji samego PrestaShop. Jednak jeśli chcesz używać nowoczesnej wersji PHP (8.3+), będziesz potrzebować PrestaShop 8.1 lub 9.x.

What Content Security Policy Is and Why It Matters

Content Security Policy (CSP) is a security mechanism implemented through HTTP headers that tells the browser exactly which resources are allowed to load on your pages. It prevents cross-site scripting (XSS) attacks, data injection attacks, and other code injection vulnerabilities by giving you granular control over where JavaScript, CSS, images, fonts, frames, and other resources can originate from.

Without CSP, a browser will execute any JavaScript it encounters on your page, regardless of where it came from. If an attacker manages to inject a malicious script (through a vulnerable module, a compromised third-party library, or a stored XSS vulnerability), the browser happily executes it with full access to the page content, including customer data, form inputs, and session cookies.

With CSP, you declare a whitelist of trusted sources. If the browser encounters a resource that does not match the policy, it blocks it and logs a violation. This means that even if an attacker finds a way to inject code into your page, the browser refuses to execute it because it does not come from an approved source.

For PrestaShop stores that handle customer personal information, payment data, and authentication credentials, CSP is a critical security layer. It is not a replacement for fixing vulnerabilities in your code, but it is an effective defense-in-depth measure that limits the damage when a vulnerability exists.

CSP Directives Explained

A Content Security Policy consists of one or more directives, each controlling a specific type of resource. The most important directives for PrestaShop are:

default-src: The fallback directive. If a more specific directive is not set, the browser uses default-src. Setting default-src 'self' means that by default, only resources from your own domain are allowed.

script-src: Controls where JavaScript can be loaded from. This is the most critical directive for XSS prevention. Common values include 'self' (your own domain), specific CDN domains, and analytics domains.

style-src: Controls where CSS can be loaded from. PrestaShop themes and modules frequently use inline styles, which means you may need 'unsafe-inline' unless you implement a nonce-based approach.

img-src: Controls where images can be loaded from. PrestaShop stores often load images from their own domain, CDN domains, and third-party services like Google (for user avatars or Maps).

font-src: Controls where fonts can be loaded from. Google Fonts, Font Awesome CDN, and your own domain are common sources.

connect-src: Controls which URLs can be contacted via JavaScript (AJAX requests, WebSocket connections, EventSource). Payment gateways, analytics endpoints, and your own API endpoints need to be listed here.

frame-src: Controls which domains can be embedded in iframes. Payment gateways like PayPal, Stripe, and Klarna use iframes for their payment forms. YouTube and Vimeo embeds also require frame-src entries.

frame-ancestors: Controls which domains can embed your page in an iframe. Setting frame-ancestors 'self' prevents clickjacking attacks by ensuring your store cannot be embedded in another site's iframe.

object-src: Controls plugin content like Flash. Set this to 'none' because Flash is obsolete and no PrestaShop functionality requires it.

base-uri: Controls which URLs can be used in the <base> element. Set to 'self' to prevent base URI manipulation attacks.

form-action: Controls which URLs forms can submit to. This should include your own domain and any external payment processing endpoints.

Starting with Report-Only Mode

Deploying CSP on a PrestaShop store requires careful preparation because an overly restrictive policy will break functionality. The right approach is to start with report-only mode, which tells the browser to report violations without actually blocking anything.

Instead of using the Content-Security-Policy header, use Content-Security-Policy-Report-Only. This header accepts the exact same directives but only generates reports without enforcing the policy. Your store continues to function normally while you collect data about what would be blocked.

Setting Up Violation Reporting

Add a report-uri directive to your policy that points to an endpoint that collects violation reports. You can use a free service like Report URI (report-uri.com), which provides a dashboard for viewing and analyzing CSP violations, or you can set up your own endpoint.

The browser sends violation reports as JSON POST requests. Each report includes the blocked URI, the directive that was violated, the page where the violation occurred, and other useful debugging information. Collecting these reports for a week or two on a live store gives you a comprehensive picture of all the resources your store loads and where they come from.

Building Your Initial Policy

Using the violation reports from report-only mode, build a whitelist of all legitimate resource sources. Group them by directive type. Your initial policy will likely include:

Your own domain for all resource types. CDN domains (like cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) for scripts, styles, and fonts. Analytics domains (like google-analytics.com, googletagmanager.com, connect.facebook.net) for tracking. Payment gateway domains for scripts, frames, and connections. Chat widget domains if you use live chat. Social media domains for embedded content or share buttons.

Building a CSP for PrestaShop

PrestaShop presents specific challenges for CSP implementation because of its architecture and the modules ecosystem.

Handling Inline Styles and Scripts

PrestaShop core, themes, and many modules use inline styles and inline JavaScript extensively. Inline code is blocked by default in CSP because an attacker who injects content into your page would be injecting inline code. There are three approaches to handling this:

Using 'unsafe-inline': The simplest but least secure approach. Adding 'unsafe-inline' to script-src and style-src allows all inline code, which significantly weakens CSP's XSS protection. For style-src, this is generally acceptable because inline styles pose a much lower security risk than inline scripts. For script-src, avoid 'unsafe-inline' if at all possible.

Using nonces: The recommended approach. A nonce is a random, single-use token generated on each request. You add the nonce to your CSP header (script-src 'nonce-abc123') and to each legitimate inline script tag (<script nonce="abc123">). The browser only executes inline scripts that have the correct nonce. Since the nonce changes on every request and an attacker cannot predict it, injected scripts without the nonce are blocked.

Implementing nonces in PrestaShop requires modifying the theme to add nonce attributes to all inline script tags and creating a mechanism (typically a module or a custom hook) that generates the nonce, adds it to the CSP header, and makes it available to templates. This is a significant implementation effort but provides strong XSS protection.

Using hashes: You can whitelist specific inline scripts by their SHA-256 hash. The browser computes the hash of each inline script it encounters and checks it against the hashes listed in the CSP. This approach works for inline scripts that do not change between requests (static inline scripts), but it is impractical for PrestaShop because many inline scripts include dynamic content like product IDs, prices, and user-specific data that change the hash.

Handling eval and Dynamic Code

Some JavaScript libraries use eval() or new Function() to dynamically create and execute code. CSP blocks these by default. If a module or library requires eval, you must add 'unsafe-eval' to script-src. Common culprits include older versions of jQuery templates, some analytics scripts, and certain payment gateway libraries.

Check your violation reports for entries with eval or inline as the blocked URI. These indicate code that uses dynamic evaluation. Where possible, replace the library with a version that does not use eval. When that is not possible (such as with a third-party payment gateway library you cannot modify), 'unsafe-eval' is the only option.

Third-Party Services

Most PrestaShop stores rely on multiple third-party services, each of which needs to be whitelisted in your CSP. Here are the most common ones and the directives they require:

Google Analytics and Google Tag Manager: These require entries in script-src for www.google-analytics.com, www.googletagmanager.com, and tagmanager.google.com. They also need connect-src entries for www.google-analytics.com and analytics.google.com (for sending tracking data), and img-src entries for www.google-analytics.com (for the tracking pixel). Google Tag Manager is particularly challenging because it dynamically loads scripts from domains you may not know in advance, as the scripts loaded depend on the tags configured in GTM.

PayPal: Requires script-src and frame-src entries for *.paypal.com and *.paypalobjects.com. The exact domains depend on whether you use PayPal Standard, PayPal Express, or the newer PayPal Commerce Platform integration.

Stripe: Requires script-src for js.stripe.com, frame-src for js.stripe.com and hooks.stripe.com, and connect-src for api.stripe.com.

Google Fonts: Requires style-src for fonts.googleapis.com and font-src for fonts.gstatic.com.

YouTube embeds: Require frame-src for www.youtube.com and www.youtube-nocookie.com.

Facebook Pixel and social plugins: Require script-src and connect-src for connect.facebook.net and www.facebook.com, plus img-src for www.facebook.com and *.fbcdn.net.

Live chat widgets (Tidio, Crisp, Intercom, etc.): Each has its own set of domains for scripts, styles, WebSocket connections, and images. Check your violation reports or the provider's documentation for the exact domains required.

A Complete CSP Example for PrestaShop

Here is a realistic CSP header for a PrestaShop store that uses Google Analytics, Google Fonts, PayPal, YouTube embeds, and has inline styles:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

This policy includes 'unsafe-inline' and 'unsafe-eval' for scripts, which weakens XSS protection but is necessary for most PrestaShop installations that have not been modified to support nonces. For img-src, the data: source is included because PrestaShop and many modules use data URIs for small images and icons.

Implementing CSP in PrestaShop

Via .htaccess (Apache)

For Apache servers, add the CSP header in your .htaccess file. Place it near the top of the file, before the PrestaShop rewrite rules:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

This requires the mod_headers module to be enabled. You can verify by checking if your server returns the header using browser DevTools (Network tab, click on the main document request, check the Response Headers).

Via Nginx Configuration

For Nginx, add the header in your server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

The always parameter ensures the header is sent even for error responses, which is important because error pages can also be targets for XSS attacks.

Via a PrestaShop Module

Implementing CSP through a module gives you the ability to manage the policy from the back office. The module hooks into the actionOutputHTMLBefore or uses PHP's header() function in a front controller hook to add the CSP header to every response. A module-based approach is easier to maintain because you can update the policy without editing server configuration files and without restarting the web server.

Testing Your CSP with Browser DevTools

After implementing your CSP (in report-only mode initially), use browser DevTools to monitor for violations. Open the Console tab and look for messages that start with "[Report Only]" (in report-only mode) or "Refused to" (in enforcement mode). Each message tells you exactly what was blocked and which directive was responsible.

Test every page type on your store: the home page, category pages, product pages, the cart, the checkout process (including each step and each payment method), the customer account pages, and CMS pages. Each page type may load different resources, and you need to ensure your policy covers all of them.

Pay special attention to the checkout process. A blocked payment gateway script or iframe during checkout directly prevents customers from completing purchases. Test every payment method you offer, including the 3D Secure verification flow if applicable, because these often load additional resources from domains that are not obvious.

Common Testing Pitfalls

Testing in a development environment may not reveal all violations because your development setup may not include all the third-party services that run on production (analytics, advertising pixels, live chat, A/B testing tools). Always deploy CSP in report-only mode on production first and collect reports for at least one to two weeks before switching to enforcement.

Some violations only occur under specific conditions. For example, a payment gateway might load additional verification scripts only when a customer's card requires 3D Secure authentication. Social sharing buttons might load scripts only when a visitor clicks them. Dynamic content loaded via AJAX may reference resources that are not present on the initial page load. Run through every possible user flow during testing.

Gradual Enforcement Strategy

The recommended deployment strategy for CSP on PrestaShop follows these steps:

Phase 1: Discovery. Deploy a permissive Content-Security-Policy-Report-Only header with default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; and a report-uri. This logs all resources without blocking anything, giving you a complete inventory of what your store loads.

Phase 2: Draft policy. Based on the violation reports, build a whitelist policy that covers all legitimate resources. Deploy it in report-only mode and monitor for violations that indicate you missed a resource.

Phase 3: Refine. Over one to two weeks, check violation reports daily and add any legitimate sources you missed. Pay attention to reports that come from specific page types or user flows you might not have tested manually.

Phase 4: Enforce. Switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report-uri directive so you continue receiving violation reports. Monitor closely for the first week after enforcement to catch any legitimate resources that are being blocked.

Phase 5: Tighten. Once enforcement is stable, look for opportunities to tighten the policy. Can you replace 'unsafe-inline' in script-src with nonces? Can you narrow wildcard domains to specific subdomains? Can you remove sources that are no longer used? Each tightening step improves your security posture.

Maintaining Your CSP

A CSP is not a set-and-forget configuration. Every time you install a new module, add a third-party service, change payment gateways, or update your theme, you may need to update your CSP to include new resource sources. Make CSP review part of your module installation and update process.

Keep your report-uri active even after enforcement so you receive alerts about new violations. A sudden increase in violation reports might indicate that a module update introduced new resource requirements, or it might indicate an actual XSS attack attempt that your CSP is successfully blocking. Either way, you want to know about it.

Document your CSP and the reason for each entry. Over time, policies accumulate entries for services you no longer use. Periodic reviews to remove unnecessary entries keep the policy clean and reduce the attack surface. A CSP with fewer allowed sources is inherently more secure than one with many.

Jak PrestaShop obsługuje obrazy produktów

Każdy obraz przesłany do PrestaShop przechodzi przez potok przetwarzania. Gdy dodajesz obraz produktu, system zapisuje oryginalny plik, a następnie generuje wiele zmniejszonych wersji zwanych miniaturkami. Każda miniaturka odpowiada typowi obrazu zdefiniowanemu w panelu administracyjnym w sekcji Wygląd > Ustawienia obrazów. Te typy obrazów określają dokładne wymiary w pikselach i są powiązane z konkretnymi kontekstami: listami produktów, stronami produktów, podglądami koszyka, nagłówkami kategorii, logami producentów i nie tylko.

PrestaShop przechowuje obrazy w katalogu /img/. W PrestaShop 1.7 i 8.x obrazy produktów są organizowane przy użyciu struktury katalogów opartej na identyfikatorze obrazu. Na przykład obraz o ID 1234 jest przechowywany w /img/p/1/2/3/4/. Wewnątrz tego katalogu znajdziesz oryginalny obraz (nazwany po ID, jak 1234.jpg) oraz wszystkie wygenerowane miniaturki (jak 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

Konwencja nazewnictwa jest następująca: {image_id}-{image_type_name}.{extension}. Oznacza to, że każdy zdefiniowany typ obrazu tworzy dodatkowy plik dla każdego obrazu produktu w katalogu. Sklep z 5000 obrazami produktów i 8 typami obrazów będzie miał około 45 000 plików obrazów (5000 oryginałów plus 5000 razy 8 miniaturek). Ta skala ma znaczenie, gdy trzeba je zregenerować.

Zrozumienie typów obrazów

Typy obrazów są zdefiniowane w tabeli bazy danych ps_image_type i zarządzane przez panel administracyjny. Każdy typ obrazu ma nazwę, szerokość, wysokość i flagi wskazujące, do jakich typów encji się stosuje (produkty, kategorie, producenci, dostawcy, sklepy). Domyślna instalacja PrestaShop zawiera kilka typów obrazów:

cart_default to zwykle 125x125 pikseli, używany w koszyku i mini koszyku. small_default to około 98x98 pikseli, używany w listach produktów w niektórych motywach. medium_default to około 452x452 piksele, używany dla miniaturek produktów na stronie produktu. home_default to około 250x250 pikseli, używany na stronie głównej i listach kategorii. large_default to około 800x800 pikseli, używany jako główny obraz produktu na stronie produktu.

Motywy mogą definiować własne wymagania dotyczące typów obrazów. Gdy instalujesz nowy motyw, zazwyczaj rejestruje on swoje preferowane typy obrazów podczas instalacji. Kluczowy punkt to to, że rzeczywiste pliki obrazów na dysku muszą odpowiadać temu, czego oczekuje motyw. Jeśli motyw żąda home_default w rozmiarze 340x340, ale Twoje pliki obrazów zostały wygenerowane w rozmiarze 250x250, ponieważ wcześniej używałeś innego motywu, każda lista produktów będzie wyświetlać obrazy o nieprawidłowych rozmiarach.

Kiedy regeneracja obrazów jest konieczna

Kilka sytuacji wymaga pełnej lub częściowej regeneracji miniaturek. Zrozumienie, kiedy jest to naprawdę konieczne, oszczędza czas na uruchamianiu procesu, który może trwać godzinami na dużych katalogach.

Zmiana motywu

To najczęstszy powód. Różne motywy wymagają różnych wymiarów obrazów. Gdy przełączasz się z jednego motywu na inny, szablony nowego motywu odwołują się do typów obrazów o konkretnych wymiarach. Jeśli te wymiary nie odpowiadają istniejącym plikom miniaturek, obrazy pojawiają się rozciągnięte, nieprawidłowo przycięte lub rozmazane. Po zainstalowaniu nowego motywu zawsze sprawdź jego wymagania dotyczące typów obrazów i zregeneruj miniaturki, aby pasowały.

Zmiana wymiarów typu obrazu

Jeśli zmodyfikujesz szerokość lub wysokość istniejącego typu obrazu poprzez Wygląd > Ustawienia obrazów, zmiana dotyczy tylko definicji w bazie danych. Wszystkie istniejące pliki miniaturek na dysku zachowują swoje stare wymiary. Musisz zregenerować miniaturki dla zmodyfikowanego typu obrazu, aby zastosować nowe wymiary do istniejących obrazów.

Dodawanie nowego typu obrazu

Gdy tworzysz nowy typ obrazu, żadne pliki miniaturek jeszcze dla niego nie istnieją. Jeśli szablon odwołuje się do tego nowego typu obrazu, wyświetli uszkodzone linki do obrazów, dopóki nie przeprowadzisz regeneracji. Proces regeneracji tworzy brakujące pliki miniaturek dla każdego istniejącego obrazu.

Problemy z jakością obrazów

Jeśli zmienisz ustawienie jakości kompresji JPEG w PrestaShop (znajdziesz je w Wydajność > Ustawienia obrazów lub sekcji konfiguracji obrazów w zależności od wersji), istniejące miniaturki zostały wygenerowane ze starym ustawieniem jakości. Regeneracja stosuje nowy poziom jakości do wszystkich miniaturek.

Po migracji lub przenoszeniu serwera

Czasami podczas migracji pliki miniaturek zostają utracone lub uszkodzone, podczas gdy oryginalne obrazy przetrwają. Jeśli obrazy produktów wyglądają na uszkodzone, ale oryginały istnieją w oczekiwanych katalogach, regeneracja odtwarza wszystkie miniaturki z oryginałów.

Włączanie formatu WebP

PrestaShop 8.x wprowadził obsługę WebP dla obrazów produktów. Gdy włączysz generowanie WebP, istniejące obrazy nie otrzymują automatycznie wariantów WebP. Musisz zregenerować miniaturki, aby utworzyć wersje .webp obok istniejących plików JPEG lub PNG.

Regeneracja przez panel administracyjny

PrestaShop udostępnia wbudowane narzędzie regeneracji w panelu administracyjnym w sekcji Wygląd > Ustawienia obrazów (lub Preferencje > Obrazy w starszych wersjach). Na dole strony znajdziesz sekcję regeneracji.

Dostępne opcje

Możesz wybrać usuwanie poprzednich obrazów przed regeneracją. Po włączeniu PrestaShop usuwa wszystkie istniejące miniaturki przed utworzeniem nowych. Jest to przydatne, gdy chcesz usunąć miniaturki dla typów obrazów, które już nie istnieją, ale oznacza, że wszystkie obrazy będą niedostępne podczas procesu regeneracji. Po wyłączeniu PrestaShop nadpisuje istniejące miniaturki i tworzy brakujące bez wcześniejszego usuwania czegokolwiek.

Możesz wybrać, które typy encji regenerować: produkty, kategorie, producentów, dostawców lub sklepy. Jeśli zmieniłeś tylko wymiary obrazów produktów, nie ma potrzeby regenerowania obrazów kategorii czy producentów.

Ograniczenia podejścia przez panel administracyjny

Regeneracja przez panel administracyjny działa jako żądanie webowe. Stwarza to kilka problemów dla dużych katalogów. Serwery WWW mają limity czasu wykonywania, zazwyczaj od 30 do 300 sekund w zależności od konfiguracji. Sklep z 10 000 obrazami produktów i 8 typami obrazów musi wygenerować 80 000 plików miniaturek. Nawet przy hojnym tempie 10 obrazów na sekundę zajmie to ponad dwie godziny. Większość serwerów WWW przerwie proces na długo przed jego zakończeniem.

Obowiązują także limity pamięci. Każdy obraz musi zostać załadowany do pamięci, przeskalowany przy użyciu GD lub ImageMagick i zapisany. Oryginalne obrazy o wysokiej rozdzielczości mogą zużywać od 20 do 50 MB pamięci podczas przetwarzania. Domyślny limit pamięci PHP wynoszący 128 MB lub 256 MB może zostać szybko wyczerpany, szczególnie przy przetwarzaniu obrazów sekwencyjnie bez odpowiedniego zwalniania pamięci.

Jeśli proces zostanie przerwany przez timeout lub błąd pamięci, kończysz z częściowo zregenerowanym katalogiem. Niektóre produkty mają nowe miniaturki, inne mają stare, a niektóre mogą nie mieć żadnych. Ten niespójny stan jest gorszy od pierwotnego problemu.

Regeneracja CLI dla dużych katalogów

Dla sklepów z więcej niż kilkuset produktami zdecydowanie zalecana jest regeneracja z linii poleceń. Omija ona limity czasu serwera WWW i może być skonfigurowana z wyższymi limitami pamięci.

Użycie konsoli PrestaShop

PrestaShop 1.7.5 i nowsze zawierają konsolę Symfony. Możesz regenerować miniaturki za pomocą:

php bin/console prestashop:image:regenerate

Polecenie to akceptuje kilka opcji. Aby regenerować tylko konkretne typy obrazów, użyj flagi --image-type z nazwą typu obrazu. Aby przetwarzać tylko produkty, kategorie lub inne konkretne typy encji, użyj flagi --entity. Flaga --format pozwala określić, które formaty wyjściowe generować (jpg, png, webp).

Uruchom polecenie z katalogu głównego PrestaShop. Jeśli używasz Dockera, wykonaj je wewnątrz kontenera:

docker exec -u www-data your-container php bin/console prestashop:image:regenerate

Flaga -u www-data zapewnia, że wygenerowane pliki są własnością użytkownika serwera WWW. Uruchamianie jako root tworzy pliki, których serwer WWW nie może serwować ani modyfikować później.

Konfiguracja pamięci i czasu

Przy wykonywaniu z CLI możesz zwiększyć limity PHP bezpośrednio w poleceniu:

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Ustawienie max_execution_time=0 całkowicie usuwa limit czasu, a 512 MB pamięci jest wystarczające dla większości katalogów. Dla sklepów z ekstremalnie wysokorozdzielczymi oryginałami (4000x4000 pikseli lub więcej) możesz potrzebować 1 GB lub więcej.

Niestandardowe podejście do regeneracji

Dla bardzo dużych katalogów (50 000 lub więcej obrazów) nawet polecenie konsolowe może być powolne lub problematyczne. Niestandardowe podejście PHP pozwala przetwarzać obrazy w partiach ze śledzeniem postępu, obsługą błędów i możliwością wznowienia po przerwaniu.

Podejście polega na odpytaniu bazy danych o wszystkie rekordy obrazów, iterowaniu przez nie w partiach po 100 lub 200, generowaniu miniaturek dla każdego obrazu i rejestrowaniu postępu. Jeśli proces zostanie przerwany, można go wznowić od miejsca zatrzymania, sprawdzając, które miniaturki już istnieją.

Podejście partiowe umożliwia również rozłożenie regeneracji na wiele uruchomień w godzinach o niskim ruchu, unikając wpływu na wydajność działającego sklepu.

Generowanie WebP podczas regeneracji

WebP to nowoczesny format obrazu, który zapewnia znacznie mniejsze rozmiary plików niż JPEG przy porównywalnej jakości. PrestaShop 8.x może generować wersje WebP miniaturek podczas procesu regeneracji.

Włączanie obsługi WebP

Przed regeneracją włącz WebP w konfiguracji PrestaShop. W PrestaShop 8.x ta opcja znajduje się w ustawieniach obrazów. Po włączeniu proces regeneracji tworzy zarówno tradycyjną miniaturkę JPEG/PNG, jak i wersję .webp dla każdego typu obrazu.

Wymagania serwerowe

Generowanie WebP wymaga rozszerzenia GD skompilowanego z obsługą WebP (--with-webp) lub rozszerzenia ImageMagick z delegatami WebP. Możesz sprawdzić obsługę GD za pomocą phpinfo() lub gd_info(). Szukaj WebP Support w wynikach. Jeśli obsługa WebP jest niedostępna, proces regeneracji cicho pomija tworzenie WebP bez generowania błędów.

Rozważania dotyczące przestrzeni dyskowej

Pliki WebP są zazwyczaj o 25 do 35 procent mniejsze niż równoważne pliki JPEG, ale przechowujesz oba formaty. Sklep z 40 000 miniaturek JPEG zajmujących 2 GB przestrzeni dyskowej będzie potrzebował około 3,4 GB łącznie po wygenerowaniu WebP (oryginalne 2 GB plus około 1,4 GB plików WebP). Zaplanuj odpowiednio swoją przestrzeń dyskową przed rozpoczęciem pełnej regeneracji.

Serwowanie WebP przeglądarkom

Generowanie plików WebP to tylko połowa rozwiązania. Twój motyw i serwer muszą być skonfigurowane do serwowania WebP przeglądarkom, które go obsługują, z fallbackiem do JPEG/PNG dla przeglądarek, które tego nie robią. Jest to zazwyczaj obsługiwane przez elementy <picture> w szablonach motywu lub przez negocjację treści po stronie serwera przy użyciu nagłówka Accept.

W Apache możesz dodać reguły przepisywania, które sprawdzają obsługę WebP i serwują wersję WebP, gdy jest dostępna. W Nginx dyrektywa try_files może sprawdzić, czy istnieje wersja .webp żądanego obrazu i serwować ją, jeśli nagłówek Accept przeglądarki zawiera image/webp.

Wpływ na wydajność i łagodzenie skutków

Regeneracja obrazów jest intensywna pod względem procesora i obciążająca dla I/O. Na działającym sklepie może znacząco obniżyć wydajność, jeśli nie jest odpowiednio zarządzana.

Wpływ na procesor

Każda operacja zmiany rozmiaru obrazu wymaga załadowania oryginału do pamięci, wykonania algorytmu skalowania, zastosowania ustawień jakości/kompresji i zapisania wyniku na dysk. Sama operacja skalowania jest kosztowna obliczeniowo, szczególnie dla dużych obrazów zmniejszanych do małych miniaturek. Na środowisku hostingu współdzielonego może to nasycić procesor i spowolnić cały sklep.

Wpływ na I/O

Regeneracja odczytuje każdy oryginalny obraz i zapisuje wiele plików miniaturek. Na tradycyjnych dyskach twardych tworzy to znaczne obciążenie I/O. Na dyskach SSD wpływ jest znacznie mniejszy, ale nadal zauważalny na dużą skalę. Wzorzec I/O jest szczególnie nieprzyjazny dla dysków obrotowych, ponieważ obejmuje losowe odczyty (oryginały rozrzucone po katalogach) w połączeniu z sekwencyjnymi zapisami (miniaturki w tych samych katalogach).

Uruchamianie regeneracji w godzinach o niskim ruchu

Zaplanuj regenerację na okres o najniższym ruchu. Dla sklepów europejskich to zazwyczaj między 2:00 a 6:00 w nocy. Dla sklepów o globalnym ruchu może nie być prawdziwego okresu niskiego ruchu, ale możesz zidentyfikować relatywne punkty niskiego ruchu z danych analitycznych.

Użycie nice i ionice

Na serwerach Linux możesz obniżyć priorytet procesu regeneracji, aby nie pozbawiał innych procesów zasobów. Polecenie nice obniża priorytet procesora, a ionice obniża priorytet I/O:

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Wartość nice 19 to najniższy priorytet. Klasa ionice 3 to klasa bezczynności (idle), co oznacza, że proces otrzymuje czas I/O tylko wtedy, gdy nic innego go nie potrzebuje. Drastycznie redukuje to wpływ na działający sklep, ale sprawia, że regeneracja trwa dłużej.

Tymczasowe skalowanie

Jeśli korzystasz z serwera w chmurze, rozważ tymczasowe zwiększenie mocy serwera (więcej rdzeni procesora, więcej RAM, szybsza pamięć masowa) na czas regeneracji, a następnie zmniejszenie. Dodatkowy koszt kilku godzin zasobów wyższego poziomu jest zazwyczaj minimalny w porównaniu z wpływem powolnej, wielodniowej regeneracji na wydajność sklepu.

Unikanie timeoutów podczas regeneracji

Timeouty to najczęstszy problem przy regeneracji obrazów. Oto konkretne ustawienia i konfiguracje, które im zapobiegają.

Konfiguracja PHP

Dyrektywa max_execution_time ogranicza czas działania procesu PHP. Dla wykonywania z CLI zazwyczaj jest już ustawiona na 0 (bez limitu), ale zweryfikuj to sprawdzając php -i | grep max_execution_time. Dla regeneracji webowej przez panel administracyjny zwiększ tę wartość w php.ini lub .htaccess:

php_value max_execution_time 7200

Zwiększ również max_input_time, jeśli używasz panelu administracyjnego, ponieważ timeout przesyłania formularza jest oddzielny od timeoutu wykonywania:

php_value max_input_time 7200

Timeout serwera WWW

Dyrektywa Apache Timeout oraz Nginx proxy_read_timeout / fastcgi_read_timeout mogą przerywać długotrwałe żądania nawet jeśli samo PHP nie przekroczyło timeoutu. Dla Apache: Timeout 7200. Dla Nginx dodaj do bloku server: fastcgi_read_timeout 7200; lub proxy_read_timeout 7200;.

Konfiguracja PHP-FPM

Jeśli używasz PHP-FPM (co robi większość nowoczesnych konfiguracji), request_terminate_timeout w konfiguracji puli może również zabijać długotrwałe procesy. Ustaw na 0, aby wyłączyć timeout, lub dopasuj do żądanego maksymalnego czasu wykonywania:

request_terminate_timeout = 7200

Timeouty Cloudflare i CDN

Jeśli Twój sklep jest za Cloudflare lub innym CDN, CDN ma własny timeout żądań (darmowy plan Cloudflare ma timeout 100 sekund). To sprawia, że regeneracja przez panel administracyjny za CDN jest praktycznie niemożliwa. Musisz użyć regeneracji CLI, ominąć CDN dla dostępu administracyjnego lub użyć rozwiązania, które przetwarza obrazy asynchronicznie.

Strategie regeneracji przyrostowej

Pełna regeneracja przetwarza każdy obraz w katalogu. Dla sklepów z dziesiątkami tysięcy obrazów może to trwać wiele godzin. Podejścia przyrostowe przetwarzają tylko te obrazy, które rzeczywiście potrzebują nowych miniaturek.

Selektywna regeneracja typu obrazu

Jeśli dodałeś lub zmodyfikowałeś tylko jeden typ obrazu, nie musisz regenerować wszystkich typów. Użyj opcji --image-type w poleceniu konsoli, aby celować tylko w konkretny typ obrazu, który się zmienił. Redukuje to pracę do jednej ósmej (lub jakiejkolwiek frakcji Twoich łącznych typów obrazów) pełnej regeneracji.

Przetwarzanie oparte na dacie

Jeśli musisz zregenerować miniaturki tylko dla ostatnio dodanych produktów (na przykład po naprawieniu problemu z przetwarzaniem obrazów), możesz odpytać bazę danych o obrazy dodane po konkretnej dacie i przetworzyć tylko te. Tabela ps_image domyślnie nie ma kolumny z datą, ale powiązana tabela ps_product ma pola date_add i date_upd, które można wykorzystać do identyfikacji niedawno zmodyfikowanych produktów.

Wykrywanie brakujących miniaturek

Zamiast regenerować wszystko, przeskanuj katalogi obrazów, aby znaleźć obrazy, którym brakuje konkretnych miniaturek, i zregeneruj tylko te. To najszybsze podejście, gdy dodałeś nowy typ obrazu lub gdy częściowa regeneracja została przerwana.

Logika jest prosta: dla każdego ID obrazu w bazie danych sprawdź, czy oczekiwany plik miniaturki istnieje na dysku. Jeśli nie — zregeneruj tylko tę miniaturkę. Zamienia to wielogodzinną pełną regenerację w ukierunkowany proces, który może zająć minuty.

Przetwarzanie równoległe

Dla bardzo dużych katalogów możesz podzielić zakres ID obrazów na fragmenty i przetwarzać je równolegle przy użyciu wielu procesów PHP. Na przykład jeden proces obsługuje ID obrazów od 1 do 10000, inny od 10001 do 20000 itd. Każdy proces działa niezależnie, a łączna przepustowość jest w przybliżeniu proporcjonalna do liczby równoległych procesów (ograniczona przez rdzenie procesora i przepustowość I/O).

Bądź ostrożny z przetwarzaniem równoległym i obciążeniem I/O dysku. Uruchamianie zbyt wielu procesów jednocześnie na tradycyjnym dysku twardym spowoduje rywalizację o I/O i faktycznie spowolni działanie. Na dyskach SSD 4 do 8 równoległych procesów zazwyczaj działa dobrze.

Rozważania dotyczące formatów obrazów

PrestaShop obsługuje JPEG, PNG i GIF jako formaty źródłowe i może generować miniaturki w tych formatach plus WebP. Format źródłowy wpływa na zachowanie regeneracji.

Obrazy JPEG

JPEG jest najczęstszym formatem dla zdjęć produktów. Obsługuje kompresję stratną, co oznacza, że za każdym razem, gdy JPEG jest zapisywany, pewna jakość jest tracona. Dlatego regeneracja miniaturek z oryginalnych przesyłanych plików daje lepsze wyniki niż regeneracja z wcześniej przeskalowanych miniaturek. Zawsze upewnij się, że pracujesz z oryginalnym przesłanym obrazem, a nie wcześniej wygenerowaną miniaturką.

Obrazy PNG

PNG obsługuje przezroczystość i kompresję bezstratną. Jeśli Twoje obrazy produktów używają przezroczystych teł, miniaturki PNG zachowują tę przezroczystość. Jednak pliki PNG są zazwyczaj znacznie większe niż pliki JPEG. Zastanów się, czy faktycznie potrzebujesz przezroczystości. Jeśli nie, konwersja obrazów produktów PNG do JPEG podczas regeneracji może znacznie zmniejszyć przestrzeń dyskową i poprawić czasy ładowania stron.

Obsługa GIF

PrestaShop może przyjmować przesyłane pliki GIF, ale wygenerowane miniaturki ze źródeł GIF są statyczne (animacja nie jest zachowywana). Jeśli masz animowane obrazy produktów GIF, pamiętaj, że regeneracja produkuje statyczne miniaturki z pierwszej klatki.

Weryfikacja po regeneracji

Po zakończeniu regeneracji zweryfikuj wyniki przed założeniem, że wszystko jest poprawne.

Kontrola wyrywkowa jakości obrazów

Otwórz kilka stron produktów i wizualnie sprawdź obrazy. Upewnij się, że miniaturki są ostre, prawidłowo proporcjonalne i nie są rozciągnięte ani pikselowe. Zwróć szczególną uwagę na obrazy, które były pierwotnie małe (bliskie lub mniejsze od wymiarów miniaturki), ponieważ te mają największe szanse na problemy z jakością przy powiększaniu.

Weryfikacja liczby plików

Porównaj liczbę wygenerowanych miniaturek z oczekiwaniami. Jeśli masz 5000 obrazów produktów i 8 typów obrazów, powinieneś mieć około 40 000 plików miniaturek (plus oryginały i potencjalnie warianty WebP). Znacząco niższa liczba wskazuje, że proces regeneracji został przerwany lub napotkał błędy na niektórych obrazach.

Sprawdzenie uprawnień plików

Upewnij się, że zregenerowane pliki są własnością użytkownika serwera WWW (zazwyczaj www-data na Debian/Ubuntu lub apache na CentOS). Jeśli uruchomiłeś regenerację jako root, pliki mogą być nieczytelne dla serwera WWW, powodując uszkodzone obrazy na froncie sklepu. Napraw za pomocą: chown -R www-data:www-data img/p/.

Czyszczenie cache

Po regeneracji wyczyść wszystkie cache. Obejmuje to wewnętrzną pamięć podręczną PrestaShop (Zaawansowane parametry > Wydajność), wszelką pamięć podręczną opcode (OPcache) i wszelką pamięć podręczną CDN lub reverse proxy. Stare buforowane strony mogą nadal odwoływać się do starych URL-i lub wymiarów obrazów. Jeśli używasz modułu, który generuje sprite'y CSS lub obrazy inline, zregeneruj je również.

Jeśli Twój sklep jest za Cloudflare, wyczyść cache dla ścieżki /img/ lub wykonaj pełne czyszczenie cache. Cloudflare agresywnie buforuje obrazy i odwiedzający mogą widzieć stare miniaturki, dopóki cache CDN nie wygaśnie lub nie zostanie wyczyszczony.

Rozwiązywanie typowych problemów z regeneracją

Czarne lub uszkodzone miniaturki

Zazwyczaj wskazuje to na problem z biblioteką GD. Rozszerzenie GD może nie obsługiwać formatu źródłowego (na przykład GD skompilowane bez obsługi JPEG). Zweryfikuj możliwości GD za pomocą gd_info(). Inną przyczyną jest niewystarczająca ilość pamięci: jeśli PHP nie może przydzielić wystarczającej pamięci do załadowania oryginalnego obrazu, GD może wyprodukować czarny obraz zamiast zgłosić błąd.

Błędne wymiary wygenerowanych miniaturek

Jeśli miniaturki mają nieoczekiwane wymiary, sprawdź definicje typów obrazów w bazie danych. Panel administracyjny może pokazywać jedną wartość, podczas gdy baza danych zawiera inną (może się to zdarzyć po nieudanym imporcie lub ręcznej modyfikacji bazy danych). Odpytaj bezpośrednio: SELECT * FROM ps_image_type WHERE name = 'home_default';

Regeneracja zawiesza się bez postępu

Zawieszony proces regeneracji zazwyczaj oznacza, że napotkał bardzo duży obraz, który wyczerpał dostępną pamięć. Sprawdź log błędów PHP pod kątem błędów alokacji pamięci. Rozwiązaniem jest zwiększenie limitu pamięci lub wstępne przetworzenie problematycznych obrazów źródłowych w celu zmniejszenia ich rozdzielczości przed regeneracją.

Błędy odmowy uprawnień

Jeśli regeneracja zgłasza błędy uprawnień, proces PHP nie może zapisywać do katalogów obrazów. Zdarza się to powszechnie w środowiskach Docker, gdzie wolumeny montowane przez bind mają różną własność wewnątrz i na zewnątrz kontenera. Upewnij się, że użytkownik uruchamiający polecenie regeneracji ma uprawnienia do zapisu w całym drzewie katalogów /img/.

Podsumowanie

Regeneracja obrazów to zadanie konserwacyjne, z którym spotyka się każdy właściciel sklepu PrestaShop, zazwyczaj podczas zmiany motywu lub optymalizacji ustawień obrazów. Dla małych katalogów (poniżej 500 produktów) narzędzie panelu administracyjnego działa adekwatnie. Dla czegokolwiek większego regeneracja CLI jest jedynym niezawodnym podejściem. Kluczowe zasady to: zawsze pracuj z oryginalnymi obrazami, dopasuj definicje typów obrazów do wymagań motywu, zarządzaj proaktywnie zasobami serwera i timeoutami, stosuj podejścia przyrostowe gdy to możliwe i weryfikuj wyniki po zakończeniu procesu. Z WebP stającym się standardem dla obrazów webowych, regeneracja służy również jako mechanizm tworzenia wariantów w nowoczesnych formatach całego katalogu produktów, zapewniając mniejsze rozmiary plików i szybsze ładowanie stron dla Twoich klientów.

Czym jest Varnish i dlaczego ma znaczenie dla PrestaShop

Varnish Cache to odwrotne proxy HTTP (reverse proxy), które znajduje się pomiędzy serwerem www a internetem i serwuje zbuforowane kopie stron bez jakiegokolwiek kontaktu z PHP czy MySQL. Gdy odwiedzający żąda strony, którą Varnish ma w cache, odpowiedź pochodzi bezpośrednio z pamięci operacyjnej w ciągu mikrosekund. PHP nie jest uruchamiane. MySQL nie otrzymuje żadnego zapytania. Serwer WWW praktycznie nie zauważa, że żądanie miało miejsce.

To podejście jest zasadniczo różne od tego, jak działają moduły pełnego buforowania stron (FPC) oparte na PHP w PrestaShop. Moduł FPC nadal działa w ramach PHP. Żądanie trafia do Apache lub Nginx, PHP się uruchamia, PrestaShop inicjalizuje się (ładuje konfigurację, nawiązuje połączenia z bazą danych, parsuje trasy), a następnie moduł FPC przechwytuje żądanie zanim pełna logika kontrolera zostanie uruchomiona, serwując buforowany plik HTML. Choć jest to znacznie szybsze niż renderowanie strony od zera, nadal wymaga uruchomienia PHP i załadowania frameworka PrestaShop. Ten narzut, wynoszący zazwyczaj 50-200 milisekund nawet przy trafieniu w cache, kumuluje się pod obciążeniem.

Varnish całkowicie eliminuje ten narzut. Trafienie w cache Varnish jest serwowane w 1-5 milisekund. Przy dużym ruchu różnica jest dramatyczna. Sklep PrestaShop, który z trudem obsługuje 100 jednoczesnych użytkowników z modułem FPC, może obsłużyć tysiące jednoczesnych użytkowników z Varnishem, ponieważ zdecydowana większość żądań nigdy nie dociera do backendu PHP.

Kiedy moduły PHP Full Page Cache są wystarczające

Zanim zainwestujesz w Varnish, warto zrozumieć, kiedy moduł FPC oparty na PHP jest wystarczająco dobry. Dla wielu sklepów PrestaShop tak właśnie jest.

Jeśli Twój sklep generuje mniej niż 50 000 dziennych wyświetleń stron, dobrze skonfigurowany moduł FPC poradzi sobie z obciążeniem bez problemów. Dodatkowa złożoność Varnisha nie jest uzasadniona, gdy serwer dysponuje rezerwą mocy obliczeniowej. Jeśli czasy odpowiedzi serwera z FPC są konsekwentnie poniżej 200 milisekund, Twoi odwiedzający już otrzymują szybkie ładowanie stron. Wąskim gardłem w tym momencie jest prawdopodobnie renderowanie po stronie frontendu (CSS, JavaScript, obrazy), a nie czas odpowiedzi serwera.

Moduły FPC radzą sobie z niektórymi scenariuszami specyficznymi dla PrestaShop bardziej elegancko niż Varnish, ponieważ działają wewnątrz aplikacji. Mogą sprawdzić, czy użytkownik jest zalogowany, czy koszyk zawiera produkty i czy pewna dynamiczna treść wymaga personalizacji — wszystko w ramach tego samego procesu PHP. W przypadku Varnisha te sprawdzenia muszą być obsługiwane przez inspekcję ciasteczek i reguły wariacji cache, co dodaje złożoności konfiguracyjnej.

Rozważ Varnish, gdy Twój sklep regularnie obsługuje skoki ruchu (wyprzedaże błyskawiczne, kampanie marketingowe, szczyty sezonowe), które przeciążają moce PHP, gdy potrzebujesz czasów odpowiedzi poniżej 10 ms ze względu na SEO lub doświadczenie użytkownika, gdy budżet na hosting jest ograniczony i musisz obsłużyć większy ruch na tym samym sprzęcie, lub gdy sklep obsługuje wysoki stosunek anonimowego przeglądania (strony kategorii, strony produktów) w stosunku do aktywności koszyka i kasy.

Jak działa Varnish: Przepływ żądań

Zrozumienie przepływu żądań przez Varnish jest kluczowe dla prawidłowej konfiguracji z PrestaShop.

Przychodzące żądanie

Gdy odwiedzający żąda strony, żądanie trafia najpierw do Varnisha (Varnish nasłuchuje na porcie 80 lub 443, jeśli zakończenie SSL jest obsługiwane przez proxy frontendowe). Varnish analizuje żądanie: URL, metodę HTTP, ciasteczka i nagłówki.

Wyszukiwanie w cache

Varnish sprawdza swój cache pod kątem zapisanej odpowiedzi pasującej do tego żądania. Klucz cache jest zwykle oparty na URL i wybranych nagłówkach. Jeśli pasująca odpowiedź istnieje i nie wygasła, Varnish serwuje ją bezpośrednio. To jest trafienie w cache (cache hit). Odpowiedź jest wysyłana do odwiedzającego, a serwer backendowy nie jest w ogóle kontaktowany.

Pudło cache

Jeśli brak pasującej zbuforowanej odpowiedzi, Varnish przekazuje żądanie do serwera backendowego (Apache lub Nginx z PrestaShop). PrestaShop przetwarza żądanie normalnie, generuje odpowiedź HTML i odsyła ją do Varnisha. Varnish zapisuje odpowiedź w swoim cache (jeśli odpowiedź nadaje się do buforowania) i przekazuje ją odwiedzającemu. Kolejne żądania tej samej strony będą serwowane z cache.

Inwalidacja cache

Gdy dane produktu się zmienią, ceny zostaną zaktualizowane lub treść zostanie zmodyfikowana, wersja w cache staje się nieaktualna. Varnish musi zostać poinformowany o konieczności odrzucenia starej wersji z cache, aby pobrał świeżą z backendu. To jest inwalidacja cache, i jest to najtrudniejsza część każdego systemu buforowania do prawidłowego wdrożenia.

Konfiguracja VCL dla PrestaShop

Varnish Configuration Language (VCL) to język specyficzny dla domeny, który kontroluje sposób obsługi żądań przez Varnish. Prawidłowa konfiguracja VCL dla PrestaShop musi obsługiwać kilka zachowań specyficznych dla PrestaShop.

Definicja backendu

Definicja backendu informuje Varnish, dokąd przekazywać pudła cache. Dla typowej konfiguracji PrestaShop, gdzie Apache lub Nginx działa na tym samym serwerze na porcie 8080:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 5s;
  .first_byte_timeout = 60s;
  .between_bytes_timeout = 10s;
}

Timeouty są ważne. Strony PrestaShop mogą potrzebować kilku sekund na wygenerowanie przy zimnym cache, szczególnie strony kategorii z wieloma produktami. Ustawienie first_byte_timeout zbyt nisko powoduje, że Varnish zwraca błąd 503 zanim PrestaShop zdąży wygenerować stronę.

Obsługa ciasteczek i sesji

Ciasteczka są największym wyzwaniem przy buforowaniu PrestaShop z Varnishem. PrestaShop ustawia domyślnie kilka ciasteczek, a Varnish traktuje każde żądanie z ciasteczkami jako niebuforowalne, chyba że poinstruujemy go inaczej. Jeśli nie obsłużysz ciasteczek w swoim VCL, Varnish nie będzie buforował praktycznie niczego.

PrestaShop ustawia te ciasteczka przy większości żądań: ciasteczko sesji (zwykle o nazwie PrestaShop-xxxx), ciasteczka związane z koszykiem, ciasteczka Google Analytics (_ga, _gid, _gat) oraz różne ciasteczka śledzące od narzędzi marketingowych. Spośród nich tylko ciasteczko sesji PrestaShop ma znaczenie dla zachowania cache. Ciasteczka analityczne i śledzące powinny być usuwane z żądania przed wyszukiwaniem w cache, aby nie uniemożliwiały buforowania.

W podprocedurze VCL vcl_recv usuń nieistotne ciasteczka:

sub vcl_recv {
  # Usuń ciasteczka Google Analytics i inne śledzące
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Usuń pusty nagłówek ciasteczka
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Decydowanie, co buforować

Nie każda strona PrestaShop powinna być buforowana. VCL musi rozróżniać między żądaniami buforowalnymi i niebuforowalnymi.

Zawsze buforuj: Strony produktów dla anonimowych odwiedzających, strony z listą kategorii, strony CMS (o nas, regulamin, kontakt), stronę główną, strony producentów i dostawców, strony mapy witryny.

Nigdy nie buforuj: Strony koszyka, strony kasy (wszystkie kroki), obszaru konta klienta (zamówienia, adresy, dane osobowe), stron logowania i rejestracji, żadnej strony dla zalogowanego klienta, żądań POST, żądań AJAX modyfikujących stan (dodaj do koszyka, aktualizuj ilość).

Logika VCL do tego celu zwykle sprawdza ścieżkę URL i obecność ciasteczek sesji:

sub vcl_recv {
  # Nie buforuj żądań POST
  if (req.method == "POST") {
    return (pass);
  }
  # Nie buforuj panelu administracyjnego
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # Nie buforuj kasy i koszyka
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # Nie buforuj, jeśli klient ma produkty w koszyku
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Ustawianie czasu życia cache

W podprocedurze vcl_backend_response kontrolujesz, jak długo Varnish buforuje każdą odpowiedź. PrestaShop wysyła nagłówki Cache-Control, które zwykle mówią no-cache lub private, ponieważ zakłada, że każda odpowiedź może zawierać spersonalizowaną treść. Musisz je nadpisać dla stron, o których wiesz, że są bezpieczne do buforowania:

sub vcl_backend_response {
  # Buforuj strony produktów i kategorii przez 1 godzinę
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Buforuj zasoby statyczne przez 1 dzień
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

Usuwanie Set-Cookie z buforowanych odpowiedzi jest krytyczne. Jeśli buforowana odpowiedź zawiera nagłówek Set-Cookie, Varnish domyślnie jej nie zbuforuje, a nawet jeśli zostanie zmuszony do buforowania, ustawi to samo ciasteczko sesji dla każdego odwiedzającego, powodując przechwycenie sesji (session hijacking).

Inwalidacja cache za pomocą żądań PURGE

Gdy cena produktu się zmienia, nowy produkt jest dodawany lub treść jest aktualizowana, buforowana wersja musi zostać unieważniona. Varnish obsługuje żądania PURGE: specjalną metodę HTTP, która informuje Varnish o konieczności usunięcia konkretnego URL z cache.

Konfiguracja obsługi PURGE

Dodaj obsługę PURGE do swojego VCL:

acl purge {
  "127.0.0.1";
  "localhost";
}

sub vcl_recv {
  if (req.method == "PURGE") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    return (purge);
  }
}

ACL ogranicza żądania PURGE do localhost, uniemożliwiając zewnętrznym użytkownikom czyszczenie Twojego cache.

Wyzwalanie operacji purge z PrestaShop

PrestaShop natywnie nie wysyła żądań PURGE. Potrzebujesz modułu lub niestandardowego hooka, który wykrywa zmiany w treści nadającej się do buforowania i wysyła żądanie PURGE do Varnisha. Moduł podpina się pod zdarzenia PrestaShop takie jak actionProductUpdate, actionCategoryUpdate i actionCMSPageUpdate. Gdy te zdarzenia są wywoływane, moduł wysyła żądanie HTTP PURGE na odpowiedni URL serwera Varnish.

Przy aktualizacji produktu moduł powinien wyczyścić URL produktu, URL kategorii, do których produkt należy (ponieważ strony z listą kategorii wyświetlają ceny i dostępność produktów) oraz potencjalnie stronę główną, jeśli wyświetla polecane produkty. Ta kaskada operacji purge jest konieczna, aby zapobiec wyświetlaniu nieaktualnych danych w dowolnym miejscu witryny.

Inwalidacja oparta na BAN

W scenariuszach, gdy wiele URL-i wymaga jednoczesnego wyczyszczenia (aktualizacja cen w całej witrynie, zmiana designu, nowy baner promocyjny), indywidualne żądania PURGE są niepraktyczne. Varnish obsługuje bany, czyli reguły inwalidacji oparte na wzorcach. Ban informuje Varnish o konieczności odrzucenia każdego zbuforowanego obiektu pasującego do wzorca:

sub vcl_recv {
  if (req.method == "BAN") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    ban("req.url ~ " + req.http.X-Ban-Pattern);
    return (synth(200, "Banned."));
  }
}

Wysłanie żądania BAN z nagłówkiem X-Ban-Pattern: /category/ unieważni wszystkie zbuforowane strony kategorii w jednej operacji.

Edge Side Includes (ESI) dla bloków dynamicznych

Wiele stron PrestaShop zawiera mieszankę treści statycznej i dynamicznej. Lista produktów na stronie kategorii jest taka sama dla każdego odwiedzającego, ale nagłówek pokazujący liczbę produktów w koszyku jest spersonalizowany. Bez ESI nie można buforować strony w ogóle, ponieważ dynamiczny nagłówek sprawia, że cała odpowiedź jest specyficzna dla odwiedzającego.

Edge Side Includes rozwiązują to, pozwalając na oznaczenie sekcji strony jako osobno pobieranych fragmentów. Varnish składa finalną stronę z fragmentów buforowanych i niebuforowanych.

Jak działa ESI

W szablonie Smarty, zamiast renderować widget koszyka bezpośrednio, umieszczasz tag ESI:

<esi:include src="/module/cartwidget/ajax" />

Gdy Varnish przetwarza buforowaną stronę, napotyka tag ESI i wysyła osobne żądanie do backendu po ten fragment. Główne ciało strony jest serwowane z cache, podczas gdy widget koszyka jest pobierany świeżo z PrestaShop. Złożona odpowiedź zawiera zarówno buforowane ciało, jak i świeży widget koszyka.

Włącz przetwarzanie ESI w swoim VCL:

sub vcl_backend_response {
  set beresp.do_esi = true;
}

Aspekty ESI dla PrestaShop

Wdrożenie ESI wymaga modyfikacji szablonów PrestaShop w celu oddzielenia dynamicznej treści na fragmenty kompatybilne z ESI. Każdy fragment potrzebuje własnego endpointu URL, który zwraca tylko HTML dla tego bloku. Fragmenty, które są zwykle dynamiczne i wymagają obsługi ESI, to: widget podsumowania koszyka (liczba produktów, suma), powitanie klienta ("Cześć, Jan"), wszelkie spersonalizowane rekomendacje produktów, link logowania/wylogowania oraz ostatnio przeglądane produkty.

Nakład pracy wymagany do prawidłowego wdrożenia ESI jest znaczny. Każdy dynamiczny fragment potrzebuje dedykowanego kontrolera, szablony wymagają restrukturyzacji, a reguły buforowania dla każdego fragmentu wymagają indywidualnego dostrojenia. To jeden z powodów, dla których Varnish jest uważany za zaawansowaną optymalizację — działa najlepiej, gdy aplikacja jest projektowana z myślą o nim.

Kontrole zdrowia backendu

Varnish może monitorować stan serwera backendowego i podejmować działania, gdy staje się niedostępny. Konfiguruje się to w definicji backendu:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .probe = {
    .url = "/ping.php";
    .timeout = 2s;
    .interval = 5s;
    .window = 5;
    .threshold = 3;
  }
}

Varnish wysyła żądanie do /ping.php co 5 sekund. Jeśli 3 z ostatnich 5 sprawdzeń zakończy się niepowodzeniem, Varnish oznacza backend jako chory. Gdy backend jest chory, Varnish może serwować nieaktualną treść z cache (tryb grace) zamiast zwracać błędy odwiedzającym. Oznacza to, że Twój sklep pozostaje częściowo dostępny nawet gdy backend PHP ulega awarii lub jest restartowany.

Konfiguracja trybu grace określa, jak długo Varnish będzie serwował nieaktualną treść:

sub vcl_backend_response {
  set beresp.grace = 6h;
}

Z 6-godzinnym grace, jeśli Twój backend padnie, odwiedzający zobaczą buforowane strony (nawet jeśli mają do 6 godzin) zamiast stron błędów. Ceny produktów mogą być nieznacznie nieaktualne, ale sklep pozostaje funkcjonalny, dopóki naprawiasz problem z backendem.

Benchmarki wydajności

Różnica wydajności między brakiem cache, PHP FPC i Varnishem jest znaczna i mierzalna.

Bez cache (czysty PrestaShop): Typowa strona produktu PrestaShop generuje się w 200-800 milisekund, w zależności od sprzętu serwera, liczby załadowanych modułów i liczby zapytań do bazy danych. Pod obciążeniem czasy odpowiedzi rosną, ponieważ workery PHP są nasycone. Pojedynczy serwer może obsłużyć 20-50 jednoczesnych użytkowników, zanim czasy odpowiedzi staną się nie do zaakceptowania.

Moduł PHP FPC: Trafienia w cache serwowane są w 30-100 milisekund, ponieważ PHP nadal się uruchamia, a framework częściowo inicjalizuje. Pod obciążeniem wydajność jest znacznie lepsza, ponieważ buforowane odpowiedzi wymagają minimalnego czasu przetwarzania PHP. Pojedynczy serwer może obsłużyć 200-500 jednoczesnych użytkowników w zależności od konfiguracji. Pudła cache nadal trwają pełny czas renderowania.

Varnish: Trafienia w cache serwowane są w 1-5 milisekund. Pod obciążeniem sam Varnish może obsłużyć tysiące jednoczesnych połączeń, ponieważ jest napisany w C i zaprojektowany specjalnie do tego obciążenia. Serwer backendowy obsługuje tylko pudła cache, które stanowią niewielki ułamek całkowitego ruchu w prawidłowo skonfigurowanym systemie. Ten sam sprzęt, który z trudem obsługuje 50 jednoczesnych użytkowników bez buforowania, może obsłużyć 5000 lub więcej z Varnishem.

Te liczby ilustrują, dlaczego Varnish jest wart złożoności konfiguracyjnej dla sklepów o dużym ruchu. Poprawa wydajności nie jest przyrostowa — jest o rząd wielkości.

Wymagania hostingowe

Varnish ma specyficzne wymagania hostingowe, których nie każde środowisko hostingowe PrestaShop może spełnić.

Dostęp do serwera

Potrzebujesz dostępu root, aby zainstalować i skonfigurować Varnish. Plany hostingu współdzielonego nie obsługują Varnisha, ponieważ wymaga on własnego procesu nasłuchującego na porcie i przechwytującego cały ruch HTTP. Potrzebujesz VPS, serwera dedykowanego lub instancji chmurowej, gdzie kontrolujesz pełny stos serwerowy.

Pamięć operacyjna

Varnish przechowuje swój cache w RAM. Ilość potrzebnej pamięci RAM zależy od liczby unikalnych stron w Twoim katalogu i rozmiaru każdej buforowanej odpowiedzi. Przybliżony wzór: liczba stron nadających się do buforowania pomnożona przez średni rozmiar strony daje minimalny rozmiar cache. Sklep z 5000 produktami, 200 kategoriami i średnim rozmiarem strony 50 KB potrzebuje około 260 MB pamięci cache. Dodaj narzut na sam Varnish i powinieneś przydzielić co najmniej 512 MB. Dla większych katalogów typowe jest 1-2 GB.

Konfiguracja portów

W standardowej konfiguracji Varnish nasłuchuje na porcie 80 (domyślny port HTTP) i przekazuje pudła cache do serwera www na innym porcie (zwykle 8080). Oznacza to, że musisz przekonfigurować Apache lub Nginx, aby nasłuchiwał na porcie 8080 zamiast 80. Jeśli używasz HTTPS (a powinieneś), zazwyczaj umieszczasz Nginx przed Varnishem do obsługi zakończenia SSL: Nginx na porcie 443 kończy SSL i przekazuje do Varnisha na porcie 80, który przekazuje pudła cache do Apache lub PHP-FPM na porcie 8080.

Przykład konfiguracji Docker

Uruchomienie Varnisha w Dockerze obok kontenera PrestaShop to czysty sposób na dodanie Varnisha do istniejącej konfiguracji bez modyfikowania systemu hosta.

Konfiguracja Docker Compose

Podstawowa konfiguracja Docker Compose z Varnishem, Nginx do SSL i PrestaShop:

services:
  varnish:
    image: varnish:7.4
    ports:
      - "80:80"
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    environment:
      - VARNISH_SIZE=512m
    depends_on:
      - prestashop
  prestashop:
    image: prestashop/prestashop:8
    expose:
      - "80"
    environment:
      - DB_SERVER=db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secretpassword
      - MYSQL_DATABASE=prestashop

W tej konfiguracji Varnish jest punktem wejściowym na porcie 80. Kontener PrestaShop nie eksponuje swojego portu na hosta, tylko na sieć Dockera. Hostem backendu VCL byłby prestashop (nazwa usługi Docker) na porcie 80.

VCL dla Dockera

Definicja backendu VCL dla Dockera używa nazwy usługi zamiast localhost:

backend default {
  .host = "prestashop";
  .port = "80";
}

Wewnętrzne DNS Dockera rozwiązuje nazwę usługi na IP kontenera. Reszta konfiguracji VCL pozostaje taka sama jak w konfiguracji bez Dockera.

Przechowywanie cache w Dockerze

Domyślnie obraz Docker Varnish używa przechowywania w pamięci (malloc), co jest idealne dla wydajności. Zmienna środowiskowa VARNISH_SIZE kontroluje, ile pamięci Varnish przydziela na swój cache. Ustaw tę wartość na taką, która mieści się w limitach pamięci kontenera, pozostawiając miejsce na sam proces Varnish.

Dla trwałego cache, który przetrwa restarty kontenera, możesz użyć przechowywania plikowego montując wolumen, ale jest to rzadko konieczne. Cache rozgrzewa się szybko (w ciągu minut od otrzymania ruchu), a przechowywanie plikowe jest wolniejsze niż przechowywanie w pamięci.

Monitorowanie wydajności Varnisha

Varnish zapewnia wbudowane narzędzia do monitorowania wydajności cache.

Polecenie varnishstat pokazuje statystyki w czasie rzeczywistym, w tym współczynnik trafień cache, połączenia z backendem i wykorzystanie pamięci. Najważniejszą metryką jest współczynnik trafień, który powinien wynosić 85% lub więcej dla dobrze skonfigurowanego systemu. Jeśli współczynnik trafień jest poniżej 70%, przejrzyj reguły VCL, ponieważ zbyt wiele żądań przechodzi do backendu.

Polecenie varnishlog pokazuje szczegółowe logi per żądanie, które są nieocenione przy debugowaniu, dlaczego konkretne żądania nie są buforowane. Możesz filtrować po wzorcu URL, kodzie odpowiedzi lub statusie trafienia/pudła cache.

Polecenie varnishtop pokazuje rankingową listę najczęstszych wpisów w logach, pomagając identyfikować wzorce w pudłach cache lub błędach.

Typowe pułapki

Zapominanie o usuwaniu ciasteczek

Najczęstszą błędną konfiguracją Varnisha z PrestaShop jest nieusuwanie ciasteczek analitycznych i śledzących. Te ciasteczka są obecne w praktycznie każdym żądaniu i sprawiają, że każde żądanie jest unikalne z perspektywy Varnisha, co skutkuje 0% współczynnikiem trafień. Zawsze usuwaj ciasteczka, których nie potrzebujesz do wariacji cache.

Buforowanie spersonalizowanej treści

Jeśli Twój VCL jest zbyt agresywny, będzie buforować strony zawierające spersonalizowaną treść (powitanie zalogowanego użytkownika, zawartość koszyka) i serwować je innym odwiedzającym. Powoduje to poważne problemy z użytecznością i potencjalne problemy z prywatnością. Zawsze przekazuj żądania zawierające ciasteczka sesji do backendu.

Brak inwalidacji przy zmianach treści

Bez odpowiedniego mechanizmu czyszczenia cache zmiany treści w panelu administracyjnym nie będą widoczne, dopóki buforowane strony nie wygasną naturalnie. Dla sklepu z aktywnymi zmianami stanów magazynowych oznacza to, że odwiedzający mogą widzieć produkty niedostępne, błędne ceny lub nieaktualne opisy. Wdróż obsługę PURGE lub BAN i zintegruj ją z hookami aktualizacji PrestaShop.

Ignorowanie HTTPS

Varnish natywnie nie obsługuje SSL. Musisz umieścić proxy kończące SSL (Nginx, HAProxy lub chmurowy load balancer) przed Varnishem. Brak zaplanowania tego w architekturze prowadzi do problemów z mieszaną treścią (mixed content), pętli przekierowań lub niemożności serwowania ruchu HTTPS w ogóle.

Czy Varnish jest odpowiedni dla Twojego sklepu

Varnish to potężne narzędzie, ale nie jest właściwym wyborem dla każdego sklepu PrestaShop. Dodaje złożoność operacyjną: kolejną usługę do monitorowania, kolejny język konfiguracyjny do nauki, kolejną warstwę w procesie debugowania. Korzyści są jasne i mierzalne dla sklepów, które ich potrzebują, ale wiążą się z kosztem w postaci czasu konfiguracji, konserwacji i trudności w rozwiązywaniu problemów.

Jeśli Twój sklep obsługuje mniej niż 50 000 wyświetleń stron dziennie, a serwer radzi sobie z obciążeniem komfortowo z modułem FPC, Varnish to niepotrzebna złożoność. Jeśli Twój sklep regularnie mierzy się ze skokami ruchu, które przeciążają serwer, obsługuje dużą ilość anonimowego ruchu przeglądania lub potrzebuje najszybszych możliwych czasów odpowiedzi dla SEO czy doświadczenia użytkownika, Varnish zapewnia poziom wydajności, którego żadne rozwiązanie buforowania oparte na PHP nie jest w stanie dorównać.

Zacznij od właściwej optymalizacji PrestaShop (optymalizacja zapytań, audyt modułów, PHP OPcache, optymalizacja obrazów) i modułu FPC. Jeśli te optymalizacje nie wystarczą, Varnish jest kolejnym krokiem na drabinie skalowania wydajności.