Moduł w PrestaShop to najszybszy sposób na dodanie funkcji, której sklep nie ma domyślnie — od płatności i kurierów po integrację z ERP. Problem w tym, że instalacja zajmuje 10 minut, a skutki złego wyboru widzisz przez kolejne dwa lata: konflikty z cache, wolniejsze ładowanie koszyka, brak aktualizacji pod PHP 8.3. Ten artykuł przechodzi przez całą organizację pracy z modułami: skąd je brać, jak ocenić przed zakupem, jak wdrożyć bez ryzyka i kiedy gotowe rozwiązanie przestaje mieć sens. Punkt wyjścia znajdziesz w naszym przeglądzie usług PrestaShop.
Moduł w PrestaShop to katalog w /modules/ zawierający plik PHP z klasą dziedziczącą po Module, szablony Smarty, zasoby CSS/JS i plik config.xml z metadanymi. Sklep nie wie o module, dopóki ten nie zarejestruje się w hookach — punktach zaczepienia, które PrestaShop wywołuje w konkretnych momentach renderowania strony lub obsługi zdarzeń. Pełną listę hooków opisuje dokumentacja dla deweloperów PrestaShop.
Cztery hooki, które zobaczysz najczęściej:
displayHeader — dopina CSS i JS do sekcji <head>; tak działa np. moduł listy życzeń.displayHome — blok na stronie głównej: slider, banner, sekcja promocji.displayProductAdditionalInfo — dodatkowa sekcja na karcie produktu, np. tabela rozmiarów albo informacja o darmowej dostawie.actionCartSave — uruchamiany przy każdej zmianie koszyka; tu pracują moduły gratisów, cross-sellu i wysyłki stanów magazynowych do ERP.Funkcjonalnie moduły dzielą się na płatności, dostawę, marketing (pixel, newsletter), SEO (dane strukturalne, canonical), wydajność (cache, lazy loading) i integracje z ERP, hurtowniami czy systemami magazynowymi. Osobna grupa to moduły back-office rozszerzające panel administracyjny.
Struktura folderu jest powtarzalna: plik główny (np. mymodule.php), controllers/ z kontrolerami front i admin, views/ z szablonami i assetami, upgrade/ ze skryptami migracji bazy oraz katalog override/. Override to kopia metody rdzenia PrestaShop — jeden moduł nadpisujący CartController potrafi zablokować drugi, który robi dokładnie to samo. Po instalacji podejrzyj listę nadpisań w „Zaawansowane → Wydajność” i trzymaj ją możliwie krótką. Jeśli funkcja wymaga nadpisania rdzenia, zwykle taniej wychodzi zlecić niestandardowe moduły i wtyczki do PrestaShop niż łatać cudzy kod po każdej aktualizacji.
Masz cztery realne źródła. Każde ma inną cenę i inne ryzyko.
PrestaShop Addons — oficjalny marketplace. Zaleta: faktura, wersja zgodna ze sklepem, deklarowane wsparcie autora, pośrednictwo w zwrotach (konkretne warunki znajdziesz w karcie produktu — sprawdź je przed zakupem). Ograniczenia: licencja prawie zawsze przypisana do domeny, więc testy na stagingu wymagają osobnego klucza albo resetu licencji przy przenosinach na produkcję. Wiele modułów działa w modelu subskrypcji rocznej — po roku bez opłaty nie dostajesz aktualizacji pod nowe PHP, choć moduł dalej funkcjonuje.
Darmowe moduły z GitHuba i forów — najtańsze i najdroższe jednocześnie. Typowe ryzyka: brak aktualizacji od 2019 roku, kod używający usuniętych funkcji, wyciek danych klientów na nieznany endpoint, backdoor w postaci eval(base64_decode(...)). Zanim wgrasz taki moduł na produkcję, przejrzyj go pod kątem curl_exec, file_get_contents i base64_decode oraz sprawdź, czy nie wymaga wyłączenia open_basedir.
Moduły od bramek i kurierów — Przelewy24, PayU, InPost, DPD, DHL. Tu nie ma dyskusji: używaj oficjalnych. Są aktualizowane przez operatora, przechodzą audyty bezpieczeństwa i najszybciej dostają zmiany w API (nowe metody płatności, uwierzytelnianie 3DS). Tańszy zamiennik z forum przy zmianie API oznacza brak płatności w sklepie.
Agencja i własny kod — gdy logika jest specyficzna: indywidualne progi rabatowe B2B, konfigurator z wyceną, integracja z wewnętrznym ERP, automatyczne faktury. Kryterium nie brzmi „czy da się kupić gotowca”, ale ile kosztuje jego dopasowanie. Własny moduł to też zobowiązanie — licz 1–2 dni pracy rocznie na utrzymanie i testy przy każdej aktualizacji PrestaShop. Więcej o tym, jak poukładać takie prace, piszemy przy okazji wdrożeń i migracji PrestaShop, a przykłady modułów pisanych na zamówienie opisujemy osobno.
Siedem rzeczy do sprawdzenia, zanim klikniesz „Kup”. Wszystkie zajmują 15–20 minut, a oszczędzają tygodnie problemów.
actionCartSave, displayShoppingCart, displayCheckoutBefore) często łamią full-page cache. Test: włącz cache i CCC, dodaj produkt do koszyka, odśwież stronę dwa razy i sprawdź, czy liczba sztuk oraz rabat się zgadzają.Każdy nowy moduł testuj najpierw na kopii sklepu — pełna organizacja wdrożenia PrestaShop to kopia bazy, staging i lista kontrolna przed włączeniem na produkcji.
| Kryterium | Co sprawdzić konkretnie | Czerwona flaga |
|---|---|---|
| Aktualizacje | Data ostatniej wersji, obsługiwane PrestaShop i PHP | Brak wydania od ponad 24 miesięcy |
| Wsparcie | Czas odpowiedzi autora w wątku modułu | Nierozwiązane zgłoszenia o konfliktach |
| Licencja | Model rozliczania i zasady przenoszenia klucza | Klucz tylko na jedną domenę bez opcji stagingu |
| Zasoby | Liczba zapytań SQL, waga JS/CSS, fonty zewnętrzne | Zapytania SQL w pętli na liście produktów |
| Cache | Zgodność z full-page cache i CCC | Koszyk gubi zawartość po włączeniu cache |
| Kod źródłowy | ionCube, Zend, dostęp do plików | Zakodowane pliki bez wsparcia autora |
| Aktualizacje techniczne | ZIP, kanał własny, 1-Click Upgrade | Brak jakiegokolwiek kanału aktualizacji |
Punkt zero, który ratuje sklepy: pełny backup plików i bazy przed każdą instalacją — także przed aktualizacją modułu, który działa u ciebie od roku. Bez tego nieudane wgranie kończy się odtwarzaniem sklepu z kopii hostingu sprzed tygodnia.
mysqldump --single-transaction --quick --routines --triggers -u użytkownik -p nazwa_bazy | gzip > /backup/sklep_$(date +%F_%H%M).sql.gztar -czf /backup/pliki_$(date +%F_%H%M).tar.gz -C /var/www/sklep . — razem z img/, modules/, themes/ i config/settings.inc.php.Instalacja przez panel: Moduły > Menedżer modułów > Prześlij moduł. Jeśli ZIP nie przechodzi, sprawdź upload_max_filesize i post_max_size w php.ini. Przez FTP/SSH rozpakuj katalog do /modules/nazwa_modulu/ — nazwa folderu musi być identyczna z nazwą klasy i pliku głównego (nazwa_modulu.php), inaczej moduł się nie zainstaluje. Na VPS ustaw właściciela plików na użytkownika PHP (np. www-data), prawa 755 dla katalogów i 644 dla plików.
Po instalacji wejdź w Moduły > Pozycje i sprawdź, w których hookach moduł się zaczepił. Krytyczny jest displayHeader — tam moduł dokłada CSS i JS do każdej podstrony. Jeśli funkcja dotyczy tylko karty produktu, a kod siedzi globalnie w displayHeader i displayFooter, ogranicz go wyjątkami (Exceptions) do wybranych plików, np. product i category.
Wyczyść cache: Zaawansowane parametry > Wydajność, a przy twardym debugowaniu usuń zawartość var/cache/prod/. Zajrzyj do var/logs/ — błąd PHP 8.x kończy się tam zapisem fatal error, a sklep pokazuje białą stronę.
Uprawnienia i grupy klientów: moduł B2B z cennikiem netto włączasz tylko dla grupy „Hurtownie”, a nie dla wszystkich. Osobno sprawdź uprawnienia pracowników — nie każdy powinien mieć dostęp do konfiguracji płatności.
Ostatni krok to staging: kopia sklepu na subdomenie, ta sama wersja PHP i MySQL, przejście całej ścieżki — koszyk, płatność, mail, faktura. Pełną listę hooków znajdziesz w dokumentacji dla deweloperów PrestaShop.
Trzy sygnały, że kolejny zakup modułu to przepalanie budżetu. Pierwszy: twój proces jest nietypowy — np. wycena B2B, gdzie rabat liczony jest progami z cennika w wewnętrznym ERP i zależy od terminu płatności. Drugi: gotowy moduł niby robi to samo, ale wymusza inny workflow, więc obsługa klika dwa razy więcej. Trzeci: masz już trzy wtyczki robiące to samo (popup, newsletter, rabat koszykowy) i zaczynają się nadpisywać. Osobny przypadek to moduł, który do działania wymaga override klasy core — po aktualizacji PrestaShop te zmiany znikają.
Własny moduł ma sens, gdy logika jest twoja i nikt jej nie sprzeda w wersji pudełkowej. Zyskujesz: mniej zależności (jeden autor kodu zamiast pięciu dostawców), lepszą wydajność (jedno zapytanie SQL zamiast trzech modułów dopisujących się do tego samego hooka), brak konfliktów licencyjnych i pełną kontrolę nad aktualizacjami pod PHP 8.3.
Kiedy NIE pisać własnego: gdy logika jest standardowa (płatności, kurierzy, faktury, podstawowe rabaty). Moduł za 200 zł kontra własny za 8 000 zł to nie jest wybór techniczny, tylko finansowy — chyba że wymagania mocno odbiegają od standardu.
Zakres robót w praktyce znajdziesz w opisie usługi niestandardowe moduły i wtyczki.
| Zakres | Widełki godzinowe | Co składa się na wycenę |
|---|---|---|
| Prosty moduł | 16–40 h | jeden hook, formularz w panelu, brak integracji, dane wyłącznie z bazy sklepu |
| Średni moduł | 40–120 h | własna logika (np. progi rabatowe), panel konfiguracji, import/eksport CSV, kilka hooków, testy |
| Złożona integracja | 120–300 h | API zewnętrznego systemu, synchronizacja stanów i zamówień w obie strony, obsługa błędów, logi, dokumentacja |
Bez pomiaru nie ma dyskusji. W PrestaShop 1.7/8 włącz tryb deweloperski (_PS_MODE_DEV_ w config/defines.inc.php) i korzystaj z Debug Profilera — pokazuje czas hooków, listę zapytań SQL i zużycie pamięci. Mierz jedną, tę samą stronę produktu (z wariantami), z wyłączonym cache, przed i po instalacji modułu.
TTFB sprawdzisz bez narzędzi: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://twojsklep.pl/produkt — zrób 5 pomiarów i weź medianę, bo pojedynczy wynik kłamie. Do tego Lighthouse lub PageSpeed Insights, ale zawsze 3 przebiegi i porównanie tych samych warunków.
Typowe problemy, które widzimy w audytach:
$;displayHeader i potrafią podwoić liczbę zapytań na stronie produktu.Zasada: jedna funkcja = jeden moduł. Limity, które warto traktować jako cel: poniżej 50 zapytań SQL na stronę produktu i poniżej 300 KB JavaScriptu po kompresji Gzip/Brotli. Progi dla Core Web Vitals opisuje web.dev – Web Vitals. Jeśli nie masz czasu na własną diagnostykę, robimy to w ramach wdrożeń i optymalizacji PrestaShop.
| Wskaźnik | Cel | Czym zmierzyć |
|---|---|---|
| Zapytania SQL na stronę produktu | poniżej 50 | Debug Profiler — lista zapytań i czas hooków |
| JavaScript po kompresji | poniżej 300 KB | DevTools > Network, filtr JS, kolumna Transfer |
| TTFB | poniżej 800 ms | curl -w time_starttransfer, mediana z 5 prób |
Override to mechanizm, w którym moduł nadpisuje plik z /classes/ lub /controllers/ własną wersją. Jeśli dwa moduły nadpiszą ten sam plik, działa ten zainstalowany później — pierwszy przestaje działać, a objaw widzisz dopiero przy konkretnej akcji klienta.
find override -name '*.php' | sort wypisze wszystkie nadpisania, a diff -u classes/Cart.php override/classes/Cart.php pokaże, co moduł zmienił. Dwa moduły w tym samym pliku to konflikt, nie „dziwny błąd”./order nie ma listy przewoźników. Zawęź winowajcę zapytaniem (dla domyślnego prefiksu ps_): SELECT m.name, h.name FROM ps_hook_module hm JOIN ps_module m USING(id_module) JOIN ps_hook h USING(id_hook) WHERE h.name IN ('actionCartSave','actionValidateOrder','displayShoppingCart'). Potem wyłączaj moduły z tej listy pojedynczo i testuj.var/logs/, log PHP-FPM/Apache oraz error_log. Przy błędzie 500 na stagingu włącz _PS_MODE_DEV_ w config/defines.inc.php — stack trace wskaże plik i linię. Brak wskazania? Wyłączaj połowę modułów i testuj (binary search).Kolejność i zakres zmian warto rozpisać wcześniej — pomaga w tym uporządkowany proces organizacji wdrożenia i migracji PrestaShop. Dokumentacja deweloperska PrestaShop opisuje też sam mechanizm override w szczegółach: PrestaShop Developer Documentation.
Moduł analityczny, remarketingowy czy czat to transfer danych poza Twój serwer. Zanim go zainstalujesz, ustal co i gdzie wysyła.
grep -rn -e 'curl_init' -e 'file_get_contents' -e 'https://' modules/nazwa_modulu wylistuje adresy docelowe. Potem DevTools → Network: otwórz stronę w trybie prywatnym, odrzuć zgodę na cookies i patrz, czy requesty do GA4, Meta czy Criteo lecą jeszcze przed zgodą. Jeśli lecą, moduł łamie przepisy niezależnie od tego, co pisze w opisie.display_errors=Off i _PS_MODE_DEV_=false na produkcji, katalogi 755, pliki 644, plik z danymi bazy bez prawa zapisu i z właścicielem równym użytkownikowi PHP. Backup plików i bazy przed każdą zmianą plus test jego odtworzenia na stagingu.tcpdump -i any -n port 443 pokaże połączenia; SNI zdradzi domenę nawet przy szyfrowanym ruchu.Gdy moduł nie przechodzi któregokolwiek punktu, taniej bywa napisać własny niż naprawiać cudzy — zobacz, jak podchodzimy do niestandardowych modułów i wtyczek.
Każdy punkt to jednoznaczne tak/nie. Brak „tak” na etapie wcześniejszym wstrzymuje kolejny — nie ma sensu instalować modułu bez backupu i stagingu.
| Etap | Punkt kontrolny (tak/nie) | Jeśli NIE |
|---|---|---|
| Przed zakupem | Deklarowana jest dokładnie Twoja wersja PrestaShop (np. 8.1), a nie „1.7 i nowsze”? | Odpuść — konflikty wyjdą na produkcji |
| Przed zakupem | Ostatnia aktualizacja modułu to mniej niż 12 miesięcy i jest wsparcie PHP 8.2/8.3? | Dolicz koszt własnych poprawek do ceny |
| Przed zakupem | Autor odpowiedział na zgłoszenie w Addons w ciągu ostatnich 6 miesięcy? | Traktuj jak moduł porzucony |
| Przed zakupem | Znasz koszt 3 lat: licencja lub subskrypcja + VAT? | Policz, zanim klikniesz „kup” |
| Przed zakupem | Wiesz, jakie tabele moduł dodaje do bazy i czy je usunie? | Zaplanuj migrację danych przed instalacją |
| Przed instalacją | Backup plików i bazy z datą w nazwie, odtworzony na stagingu? | Nie instaluj |
| Przed instalacją | Staging działa na tej samej wersji PHP i tej samej wersji PrestaShop? | Test nie będzie miarodajny |
| Przed instalacją | Lista override’ów modułu porównana z istniejącymi (<code>find override</code>)? | Scal zmiany przed włączeniem |
| Przed instalacją | Zmierzony TTFB i czas odpowiedzi <code>/order</code> przed instalacją? | Nie porównasz wpływu na wydajność |
| Po instalacji | Koszyk: dodanie produktu, zmiana ilości, kupon, zmiana przewoźnika, zamówienie testowe — wszystko działa? | Wyłącz moduł i szukaj konfliktu hooków |
| Po instalacji | Zero błędów w konsoli JS i brak nowych wpisów w <code>var/logs/</code>? | Sprawdź stack trace i zawęź winowajcę |
| Po instalacji | Cache wyczyszczony (Zaawansowane → Wydajność)? | Powtórz testy od początku |
| Po instalacji | W DevTools żaden request do domeny zewnętrznej nie leci przed zgodą na cookies? | Zgłoś autorowi lub wyłącz moduł |
| Po instalacji | TTFB i <code>/order</code> nie wzrosły o więcej niż 10%? | Rezygnuj — koszt przewyższa zysk |
| Po 30 dniach | W logach nie ma wpisów z prefiksem modułu? | Zgłoś błąd z logiem i wersjami PHP |
| Po 30 dniach | Rozmiar tabel modułu rośnie zgodnie z liczbą zamówień (<code>SELECT COUNT(*)</code>)? | Sprawdź, czy moduł nie loguje wszystkiego |
| Po 30 dniach | Używasz więcej niż połowy funkcji, za które płacisz? | Wyłącz — mniej modułów to mniej ryzyka |
| Po 30 dniach | Klient nie zgłosił problemu z koszykiem ani płatnością? | Przejdź pełną diagnostykę hooków i override’ów |
Instalacja modułu bez aktualnej kopii plików i bazy.
Jak wykryć: Nie masz dumpu z ostatnich 24 godzin albo backup robi tylko hosting raz na dobę i nie wiesz, czy da się go przywrócić.
Jak naprawić: Przed każdą instalacją wykonaj pełny backup: mysqldump -u user -p baza > baza.sql oraz tar -czf pliki.tar.gz /sciezka/do/sklepu. Sprawdź, czy plik .sql faktycznie się otwiera — backup, którego nie testowałeś, nie jest backupem.
Zakup modułu bez sprawdzenia daty ostatniej aktualizacji i wsparcia dla PHP 8.x.
Jak wykryć: W karcie modułu ostatnia wersja ma ponad 12 miesięcy, a w opisie nie ma ani słowa o PHP 8.1, 8.2 czy 8.3.
Jak naprawić: Napisz do autora i zapytaj wprost o wspierane wersje PHP i PrestaShop. Jeśli nie odpowiada w ciągu 2–3 dni roboczych, to odpowiedź brzmi: nie kupuj. Sprawdź też zgodność z dokumentacją deweloperską PrestaShop.
Testowanie modułu bezpośrednio na produkcji, na żywym ruchu.
Jak wykryć: Nie masz kopii sklepu na subdomenie i moduł włączyłeś od razu na stronie z zamówieniami.
Jak naprawić: Postaw staging: kopia plików i bazy na osobnym hostingu lub subdomenie z wyłączoną indeksacją. Dopiero po przejściu testów zamówienia, koszyka i płatności przenieś zmiany na produkcję.
Pominięcie kontroli hooków po instalacji.
Jak wykryć: Moduł wyświetla się w złym miejscu, dubluje treść na karcie produktu albo nie pokazuje się wcale mimo statusu „zainstalowany”.
Jak naprawić: Wejdź w Moduły > Pozycje i sprawdź, w których hookach moduł faktycznie się zaczepił (displayHeader, displayHome, displayProductAdditionalInfo). Jeśli siedzi nie tam, gdzie trzeba, przesuń go ręcznie lub wyłącz hook.
Dokładanie kolejnych wtyczek do tego samego problemu zamiast konsolidacji.
Jak wykryć: Masz pięć modułów modyfikujących koszyk i checkout, a każdy kolejny miał „naprawić” konflikt poprzedniego.
Jak naprawić: Zrób listę modułów pracujących na tym samym obszarze i wyłącz je po kolei, obserwując zachowanie koszyka. Zwykle zostaje jeden działający moduł albo wniosek, że potrzebny jest własny kod.
Brak weryfikacji zachowania modułu przy włączonym cache i kompresji.
Jak wykryć: Po włączeniu modułu ceny w koszyku się nie odświeżają, rabaty znikają, a zawartość modułu pokazuje się losowo lub nie pokazuje wcale.
Jak naprawić: Wyłącz cache stron, wyczyść cache PrestaShop i przetestuj pełną ścieżkę zakupu. Potem włącz cache ponownie i powtórz test — moduły modyfikujące koszyk często wymagają wykluczenia konkretnych stron z full-page cache.
Moduły w PrestaShop to najszybsza droga do nowej funkcji, ale tylko wtedy, gdy wybierasz je świadomie. Najważniejsze filtry to data ostatniej aktualizacji, wsparcie dla Twojej wersji PHP, model licencji i to, czy moduł nie psuje cache. Sam zakup to dopiero połowa pracy — druga połowa to backup, test na stagingu, sprawdzenie hooków i test zamówienia. Jeśli proces w firmie jest nietypowy, gotowy moduł zwykle okazuje się droższy niż własny kod.
Nie ma jednej odpowiedzi. Część modułów w PrestaShop Addons jest darmowa, część płatna jednorazowo, a część w modelu rocznej subskrypcji. Darmowy moduł nadal kosztuje Twój czas: wymaga testów, aktualizacji i reagowania na błędy. Jeśli autor przestał go rozwijać, koszt utrzymania przechodzi na Ciebie.
Sam GitHub nie jest problemem — problemem jest brak procesu. Repozytorium bez wydań, tagów i wsparcia dla aktualnych wersji PHP bywa kłopotliwe, bo nikt nie odpowiada za błędy. Przed wdrożeniem przeczytaj kod, sprawdź, czy moduł nie wysyła danych na zewnętrzne serwery, i przetestuj go na staging. Jeśli nie umiesz tego ocenić, wybierz rozwiązanie komercyjne z realnym wsparciem.
Po pierwsze: sprawdź w karcie modułu deklarowane wsparcie dla wersji PHP. Po drugie: zainstaluj go na staging z tą samą wersją PHP i włącz pełne logowanie błędów. Ostrzeżenia o przestarzałych funkcjach i błędy typów pojawiają się w logach od razu. Dokumentacja techniczna PrestaShop (devdocs.prestashop-project.org) pomaga ocenić, czy moduł korzysta z aktualnych mechanizmów frameworka.
To zależy od modelu licencji i trzeba to ustalić przed zakupem. Część modułów jest przypisana do konkretnej domeny i po migracji wymaga ponownej aktywacji, czasem płatnej. Inne licencjonuje się na developera, więc możesz używać ich na stagingu i produkcji. Zapytaj autora o procedurę przeniesienia, zanim zapłacisz — po fakcie zwrot bywa niemożliwy.
Tak, i to często. Największe ryzyko to dodatkowe zapytania SQL na każdej stronie, ciężkie pliki JS/CSS ładowane globalnie oraz moduły modyfikujące koszyk, które omijają cache. Zmierz czas generowania strony i liczbę zapytań przed instalacją i po niej. Wytyczne dotyczące szybkości po stronie użytkownika opisuje web.dev – Web Vitals.
Zwykle tak. Wiele modułów tworzy własne tabele i wpisy w konfiguracji, których odinstalowanie nie usuwa. Zostają też pliki w katalogu /override, jeśli moduł nadpisywał klasy PrestaShop. Jeśli planujesz wymianę modułu na inny, sprawdź to wcześniej — dwa moduły pracujące na tych samych danych potrafią się wzajemnie psuć.
Wtedy, gdy proces w firmie jest nietypowy: wycena B2B liczona według własnych zasad, integracja z wewnętrznym ERP, niestandardowe reguły dostawy. Sygnałem jest też sytuacja, w której gotowy moduł trzeba obudować trzema kolejnymi, żeby działał jak trzeba. Własny moduł ma wyższy koszt początkowy, ale niższy koszt utrzymania i pełną kontrolę nad kodem.
Jeśli nie wiesz, czy w Twoim przypadku wystarczy gotowy moduł, czy potrzebny jest własny, opisz nam proces — powiemy wprost, co ma sens. Zajmujemy się wdrożeniami, integracjami i niestandardowymi modułami dla sklepów PrestaShop.