Moduł PrestaShop to katalog z kodem, który podpina się pod hooki i rozszerza funkcje sklepu bez ruszania plików rdzenia. Zanim cokolwiek wgrasz, ustal dwie rzeczy: czy moduł działa z Twoją wersją PrestaShop i ile realnie będzie kosztował po pierwszym roku. W tym artykule znajdziesz mapę typów modułów (płatności, kurierzy, ERP, SEO), ramę decyzyjną darmowy czy płatny oraz procedury instalacji i diagnozy konfliktów. Całość uzupełnia checklista wdrożeniowa i lista błędów, które najczęściej kończą się białą stroną sklepu. Punkt wyjścia do dalszej lektury: nasze wdrożenia PrestaShop.
Moduł PrestaShop to katalog w /modules/ — na przykład /modules/mojmodul/. W nim plik główny o identycznej nazwie (mojmodul.php) z klasą dziedziczącą po Module. Dla płatności dziedziczysz po PaymentModule — ta klasa wymusza m.in. metodę validateOrder(). Obok pliku głównego leżą zwykle config.xml (metadane: nazwa, wersja, autor, zgodność z wersjami PrestaShop), katalog views/templates/ i translations/.
Serce mechanizmu to hooki — punkty zaczepienia rozsiane po rdzeniu i motywie. Moduł rejestruje je w metodzie install(), np. $this->registerHook('displayHeader'), a obsługę realizuje w hookDisplayHeader($params). Trzy przykłady z życia:
displayHeader — dopina CSS, JS lub skrypt analityczny do każdej strony; tu najczęściej ląduje kod śledzący.actionCartSave — odpala się przy każdym zapisie koszyka; nadaje się do doliczania gratisu, opłaty za pobranie czy przeliczania rabatu.paymentOptions — zwraca listę metod płatności widocznych w checkoucie (PrestaShop 1.7 i 8).Moduł to nie to samo co override ani motyw. Override kopiuje plik rdzenia do /override/ i nadpisuje go globalnie — działa, dopóki nie wejdzie w konflikt z innym override tego samego pliku i dopóki nie zaktualizujesz PrestaShop. Motyw odpowiada za wygląd i układ, nie za logikę biznesową; to osobna decyzja — zobacz, jak wybrać motyw PrestaShop.
PrestaShop wykrywa moduły, skanując katalog /modules/ przy wejściu w Moduły → Menedżer modułów. Odczytuje wtedy config.xml i pokazuje przycisk Instaluj. Sama instalacja tworzy tabele w bazie, zapisuje konfigurację i dodaje wpis w menu panelu. Katalog /modules/ musi być zapisywalny dla PHP, jeśli instalujesz z panelu. Techniczne szczegóły hooków opisuje dokumentacja dla deweloperów PrestaShop.
| Podejście | Co zmienia | Aktualizacja PrestaShop | Ryzyko konfliktu |
|---|---|---|---|
| Moduł | Dopina funkcje przez hooki | Zwykle bez zmian w plikach rdzenia | Niskie — najwyżej kolizja między modułami |
| Override | Kopiuje plik rdzenia do /override/ | Wymaga weryfikacji po każdej aktualizacji | Wysokie — dwa override tego samego pliku się wykluczają |
| Modyfikacja motywu | Układ i wygląd (.tpl, CSS) | Zależne od zgodności motywu z wersją PS | Średnie — ginie przy zmianie motywu |
Moduły z Addons i Marketplace dzielą się na kilka grup, a każda ma inne kryteria oceny.
Płatności. Przelewy24, PayU, Stripe, tpay. BLIK najczęściej nie jest osobnym modułem — obsługują go bramki jako jedną z metod. Przed instalacją sprawdź: zgodność z Twoją wersją PrestaShop (1.7.x kontra 8.x), czy zwroty i anulacje robisz z panelu sklepu czy operatora, czy jest tryb testowy (sandbox) i czy płacisz tylko prowizję operatorowi, czy dochodzi abonament za moduł. Konfigurację przećwicz na kopii sklepu — pomoże w tym demo PrestaShop i lista rzeczy do sprawdzenia przed wdrożeniem.
Kurierzy. InPost Paczkomaty (ShipX API), DPD, DHL. Moduł powinien generować etykietę z poziomu zamówienia, wpisywać numer przesyłki do zamówienia i maila do klienta oraz zmieniać status. Wymaga kluczy API z Twojej umowy z kurierem. Przy Paczkomatach sprawdź, czy mapa punktów działa w checkoucie i czy wybrany punkt zapisuje się w zamówieniu — bez tego magazyn dzwoni do klienta przy każdej paczce.
ERP i księgowość. Subiekt, Comarch, WF-Mag. Kluczowe pytanie: w którą stronę płyną dane. Najczęstszy układ to stany i ceny z ERP do sklepu oraz zamówienia ze sklepu do ERP. Ustal, kto wygrywa przy konflikcie — jeśli synchronizacja nadpisze cenę detaliczną ceną hurtową, obniżysz marżę bez ostrzeżenia. Sprawdź też częstotliwość (cron co 5–15 minut czy webhook).
SEO i wydajność. Mapy strony, dane strukturalne, kompresja, cache, lazy loading. Tu łatwo zdublować funkcje wbudowane w PrestaShop — zanim kupisz moduł cache, sprawdź, co daje hosting i sam sklep. Efekt mierzysz w Core Web Vitals, nie w opisie sprzedawcy.
Funkcyjne. Koszyk, rabaty, program lojalnościowy, fishbowl, RODO i cookies. Największe ryzyko to kolizja z regułami cenowymi — dwa moduły liczące rabat na tym samym hooku potrafią wygenerować cenę ujemną.
| Kategoria | Typowe zadanie | Co sprawdzić przed instalacją |
|---|---|---|
| Płatności | Przelewy24, PayU, Stripe, BLIK | Zgodność z wersją PS, obsługa zwrotów z panelu, tryb sandbox, model opłat |
| Kurierzy | InPost Paczkomaty, DPD, DHL | Klucze API z umowy, generowanie etykiet, punkty odbioru zapisywane w zamówieniu |
| ERP / księgowość | Subiekt, Comarch, WF-Mag | Kierunek i częstotliwość synchronizacji, kto wygrywa przy konflikcie ceny |
| SEO i wydajność | Sitemap, cache, kompresja, lazy loading | Czy nie dubluje funkcji wbudowanych w PrestaShop 1.7/8 |
| Funkcyjne | Koszyk, rabaty, lojalność, RODO/cookies | Kolizja z regułami cenowymi i innymi modułami koszyka |
Nie ma sensownej odpowiedzi na pytanie „darmowe czy płatne” bez rachunku. Policz, ile godzin pracy zajmie dopisanie brakującej funkcji do darmowego modułu i utrzymanie takiej modyfikacji przy każdej aktualizacji PrestaShop. Przykład: jeśli godzina pracy kosztuje Cię 150 zł, a obejście limitów zajmuje 12 godzin, wydajesz 1800 zł — często więcej niż roczna licencja modułu płatnego. Punkt odniesienia do całego budżetu znajdziesz w naszym cenniku wdrożenia PrestaShop.
Ukryte koszty, o które pytasz przed zakupem:
Znaki ostrzegawcze: brak aktualizacji od dwóch lat (patrz changelog i data ostatniego wydania — zestaw to z kalendarium w PrestaShop news: jak czytać wydania i kiedy aktualizować), kod obfuscated (base64, eval — nie wiesz, co moduł wysyła na zewnątrz), brak tłumaczenia PL, brak deklaracji zgodności z serią 8.x, sprzedawca bez danych do faktury.
Kiedy darmowy wystarcza: prosta, samodzielna funkcja, gdzie koszt błędu jest niski — komunikat o cookies, sitemap, bloczek informacyjny — a moduł ma świeże aktualizacje i sensowne oceny. Kiedy własny: nietypowa logika procesu — rabat liczony od marży, wycena B2B, integracja z wewnętrznym systemem firmy. Wtedy moduł na miarę bywa tańszy niż trzy moduły Marketplace walczące o ten sam hook.
| Kryterium | Darmowy z Marketplace | Płatny | Własny na miarę |
|---|---|---|---|
| Koszt startowy | 0 zł | Jednorazowo lub licencja roczna | Wycena godzinowa |
| Koszt utrzymania | Twoje godziny przy każdej aktualizacji PS | Odnowienie licencji po 12 miesiącach | Umowa serwisowa z deweloperem |
| Zgodność z nowymi wersjami PS | Brak gwarancji | Zwykle deklarowana | Zależy od Ciebie |
| Kiedy sensowny | Prosta, samodzielna funkcja | Standardowy proces: płatności, kurierzy | Nietypowa logika procesu |
Masz trzy realne ścieżki instalacji i każda ma inny próg wejścia.
1. Panel (najprostsza, dla modułów do kilku MB): Moduły > Menedżer modułów > Prześlij moduł. Pakiet ZIP musi mieć w środku katalog z modułem, nie luźno wrzucone pliki. Twardy limit narzuca PHP: upload_max_filesize i post_max_size. Jeśli masz 8 MB w pierwszym i 10 MB w drugim, ZIP 14 MB zerwie się w połowie bez czytelnego komunikatu. Wartości sprawdzisz w Zaawansowane > Informacje (PHP info) albo w php -i | grep upload_max_filesize.
2. FTP/SFTP: rozpakuj ZIP lokalnie i wgraj katalog do /modules/, a potem dokończ instalację przyciskiem w panelu. Ustaw katalogi na 755, pliki na 644, właściciela zgodnego z procesem PHP (typowo www-data). Po wgraniu FTP zawsze wyczyść cache — bez tego moduł nie pojawi się na liście.
3. CLI (staging, PS 1.7.6+ i 8.x): bin/console prestashop:module install nazwamodulu, prestashop:module enable, prestashop:cache:clear. Sensowne przy powtarzalnych wdrożeniach i skryptach.
Backup — minimalny zestaw: zrzut bazy (mysqldump), kopia /modules, /override, katalogu motywu i plików z config/. Bez tego rollback to loteria.
Moduł nie pojawia się na liście? Sprawdź po kolei: podwójne rozpakowanie (/modules/mojmodul/mojmodul/), nazwa folderu inna niż nazwa klasy i pliku głównego, brak nagłówka z $this->name, uprawnienia, niezgodność z wersją PS, cache.
Przed wdrożeniem na produkcję warto przejść całą procedurę na kopii — dobrze nadaje się do tego środowisko demo PrestaShop do testów modułów i konfiguracji.
| Ścieżka | Kiedy właściwa | Główne ryzyko |
|---|---|---|
| Panel (Prześlij moduł) | Mały moduł, brak dostępu do serwera | Limit upload_max_filesize / post_max_size |
| FTP/SFTP do /modules/ | Duże paczki, brak dostępu do konsoli | Złe uprawnienia i właściciel plików, brak czyszczenia cache |
| CLI (bin/console) | Staging, powtarzalne wdrożenia, PS 1.7.6+/8.x | Wymaga dostępu SSH i zgodności komend z wersją PS |
Biała strona lub 500: najpierw diagnoza, nie reinstalacja. W config/defines.inc.php ustaw _PS_MODE_DEV_ na true — dostaniesz stack trace z plikiem i linią. W PS 1.7/8 logi leżą w var/logs/, w 1.6 w katalogu /log/. Po diagnozie natychmiast wyłącz tryb dev: na produkcji pokazuje ścieżki i strukturę bazy.
Nadpisania (override): dwa moduły nadpisujące tę samą klasę to klasyczny konflikt — wygrywa ten, którego plik jest nowszy, a drugi przestaje działać bez komunikatu. Sprawdź /override/classes, /override/controllers i porównaj nagłówki plików oraz daty modyfikacji. Szybki test: grep -rl "extends" /override/ i zestaw wyniki z listą aktywnych modułów.
Podwójne bloki i zła kolejność hooków: ten sam fragment wyświetla się dwa razy, bo dwa moduły wiszą na tym samym hooku albo moduł podpiął się do hooka i dodatkowo wstrzykuje treść w TPL. Sprawdź Design > Pozycje (w 1.6: Menedżer modułów > Pozycje), a potem ustal, który szablon renderuje blok — w TPL pomaga {debug} i podgląd źródła przez Inspector.
Cache: Smarty, CCC (Combine/Compress/Cache) i Cloudflare potrafią trzymać stary stan po zmianie. Na czas testu: wyłącz CCC w Zaawansowane > Wydajność, wyłącz cache Smarty, w Cloudflare użyj trybu deweloperskiego i wyczyść cache.
Rollback w trzech krokach: przywróć /modules i /override z backupu, zresetuj moduł w panelu (Resety), wyczyść cache wydajności i zawartość var/cache.
| Objaw | Najczęstsza przyczyna | Od czego zacząć |
|---|---|---|
| Biała strona / 500 | Błąd PHP w module lub konflikt override | _PS_MODE_DEV_ = true, log z var/logs/ |
| Blok wyświetla się dwa razy | Dwa moduły na tym samym hooku | Design > Pozycje, podgląd TPL |
| Zmiany nie są widoczne | Cache Smarty, CCC lub Cloudflare | Wydajność > wyłącz CCC, purge CDN |
| Moduł przestał działać po instalacji innego | Override tej samej klasy w /override/ | Porównanie plików nadpisań i dat |
Custom moduł jest tańszy od kombinowania w trzech sytuacjach: dedykowany ERP wymagający konkretnego formatu eksportu zamówień i stanów, nietypowa logika cen (rabat progowy liczony od marży, ceny zależne od grupy klienta i kanału) oraz specyficzna integracja kurierska z własną tabelą stref i mapowaniem statusów.
Struktura własnego modułu: katalog /modules/mojmodul/ z plikiem głównym i klasą extends Module. Dalej install() z registerHook() i tworzeniem tabel, getContent() z formularzem konfiguracji, Configuration::updateValue() do zapisu ustawień, kontroler w controllers/admin, katalog translations/ (pl, en), uninstall(), który czyści konfigurację i tabele. Logi pisz przez PrestaShopLogger::addLog(), nie przez file_put_contents.
Widełki czasowe z naszych projektów: prosty moduł integracyjny (eksport CSV, hook na zmianę statusu) — 20-40 h. Moduł z panelem konfiguracji, walidacją, logami i cronem — 60-120 h. Wieloetapowy z API, kolejką, retry, historią i uprawnieniami — 150-300 h i więcej. Punkty odniesienia dla stawek i godzin utrzymania znajdziesz w materiale o tym, jak wygląda praca przy PrestaShop i ile kosztuje utrzymanie sklepu.
Kompatybilność: PS 1.6 ma stary system hooków i brak Symfony w adminie, 1.7/8 opiera się na Symfony i nowych hookach. Przy PHP trzeba przetestować 7.4 i 8.x osobno — w 8.2 dynamiczne właściwości i ostrzejsza typizacja wywalają kod pisany pod 7.4. Dokumentację hooków i struktury modułu trzymamy zawsze pod ręką: PrestaShop Developer Documentation.
Nie łatamy komercyjnych wtyczek. Zmiana w cudzym kodzie znika przy aktualizacji, a szyfrowane paczki (ionCube) i tak uniemożliwiają sensowną modyfikację. Własny moduł przechodzi testy, ma repo i da się przenieść na kolejną wersję PS.
| Typ modułu | Zakres | Widełki czasowe |
|---|---|---|
| Prosty integracyjny | Eksport CSV, hook na status zamówienia | 20-40 h |
| Z panelem i logami | Konfiguracja w adminie, walidacja, cron, logi | 60-120 h |
| Wieloetapowy z API | Kolejka, retry, historia, uprawnienia, panel | 150-300 h i więcej |
Zanim wgrasz plik zip na produkcję, przejdź przez checklistę. Zajmie 20–40 minut i uratuje Ci weekend.
eval(), base64_decode(), gzinflate(), plików kodowanych ionCube oraz żądań wychodzących do domen innych niż Twoja i dostawcy płatności. Sprawdź katalog override/ — jeśli moduł nadpisuje pliki rdzenia, aktualizacja PrestaShop może się wysypać. Strukturę modułu i hooki opisuje dokumentacja deweloperska PrestaShop.var/cache i katalogu uploadów. Jeśli instrukcja każe ustawić 777 na całym sklepie, to czerwona flaga: 777 oznacza, że każdy proces na serwerze może podmienić plik PHP, w tym plik z płatnością.Jeden moduł bez źródła i bez wsparcia potrafi kosztować więcej niż trzy płatne licencje razem wzięte.
| Etap | Co sprawdzasz | Sygnał ostrzegawczy |
|---|---|---|
| Marketplace | data ostatniej aktualizacji, liczba ocen, dane firmy dewelopera | brak wydania od 24 miesięcy, brak NIP-u i adresu |
| Kod źródłowy | eval(), base64_decode(), żądania do obcych domen, katalog override/ | zaszyfrowane pliki, skrypty ładowane z CDN dewelopera |
| Uprawnienia | 755 dla katalogów, 644 dla plików, zapis tylko w var/cache | wymóg 777 na całym sklepie |
| RODO | zakres zbieranych danych, DPA, lokalizacja serwerów | brak informacji, gdzie trafiają dane klientów |
| Test | płatność w sandboxie, e-mail, statusy zamówień na stagingu | wdrożenie bezpośrednio na produkcji bez kopii |
Instalacja to początek kosztu, nie koniec projektu. Moduł trzeba aktualizować, testować i mieć plan na awarię.
mysqldump) — bez tego nie ma drogi powrotu._PS_MODE_DEV_ wyłączone, czytaj var/logs/ i logi serwera. Moduł płatności potrafi dalej przyjmować karty, a przestać obsługiwać BLIK — wyłapiesz to tylko testem albo alertem na spadek liczby zamówień w ciągu dnia.| Klasa modułu | Przykłady | Rytm aktualizacji | Zakres testu |
|---|---|---|---|
| Krytyczne | płatności, kurierzy, faktury, ERP | 2–4 tygodnie od poprawki bezpieczeństwa, po stagingu | transakcja testowa, e-mail, statusy zamówienia, eksport do ERP |
| Funkcjonalne | wyszukiwarka, filtry, cross-selling | raz na kwartał, partiami | koszyk, wyszukiwanie, widok mobilny |
| Kosmetyczne | banery, suwaki, dodatki do szablonu | 1–2 razy w roku przy większym przeglądzie | wygląd desktop i mobile, Core Web Vitals |
Instalacja modułu na produkcji bez kopii bazy i plików.
Jak wykryć: Sprawdź, czy przed ostatnią instalacją istnieje zrzut bazy i archiwum katalogu sklepu z tej samej doby. Brak plików = brak rollbacku.
Jak naprawić: Zrób zrzut bazy i kopię plików (minimum /modules/, /themes/, /override/), potem dopiero instaluj. Testuj najpierw na kopii sklepu, nie na klientach.
Zakup płatnego modułu bez sprawdzenia daty ostatniej aktualizacji i warunków wsparcia.
Jak wykryć: Karta produktu bez changelogu, ostatnia wersja sprzed dwóch lat, brak informacji o wsparciu po 12 miesiącach.
Jak naprawić: Napisz do autora z pytaniem o zgodność z Twoją wersją PrestaShop i PHP, poproś o termin wsparcia w cenie. Jeśli nie ma odpowiedzi w 2 dni robocze, szukaj innego dostawcy.
Dwa moduły robiące to samo (np. dwa moduły koszyka, dwa moduły SEO) na tych samych hookach.
Jak wykryć: Blok wyświetla się podwójnie, ceny liczą się dwa razy, w /override/ pojawiają się dwie klasy nadpisujące ten sam plik.
Jak naprawić: Wyłącz jeden z modułów i przetestuj ponownie. Docelowo zostaw jeden moduł na jedną funkcję i usuń jego override, jeśli był instalowany ręcznie.
Ignorowanie cache po instalacji modułu.
Jak wykryć: Zmiany nie widać w sklepie, ale w podglądzie pliku TPL działa. Logi czyste, a zachowanie nieprzewidywalne.
Jak naprawić: Wyłącz na czas testu Smarty cache i CCC w panelu, wyczyść cache PrestaShop, a jeśli korzystasz z Cloudflare — ustaw tryb deweloperski dla swojego adresu.
Założenie, że darmowy moduł nie kosztuje nic.
Jak wykryć: Policz godziny spędzone na obejściach brakujących funkcji, poprawkach tłumaczeń i kontakcie z autorem. Jeśli to więcej niż kilka godzin — darmowy przestał być darmowy.
Jak naprawić: Przed wdrożeniem wypisz wymagania i sprawdź je punkt po punkcie na liście funkcji modułu. Braki szacuj w godzinach i porównuj z ceną licencji płatnej wersji.
Brak testu pełnej ścieżki: koszyk → płatność → status zamówienia → etykieta kurierska.
Jak wykryć: Zamówienie testowe nie zmienia statusu, etykieta nie generuje się, płatność wraca z błędem po stronie sklepu.
Jak naprawić: Po instalacji modułu płatności lub kuriera wykonaj zamówienie testowe od początku do końca, na kwotę minimalną, i sprawdź w panelu, czy status oraz etykieta są poprawne.
Moduł to katalog z kodem podpięty pod hooki, a nie magiczne rozszerzenie — dlatego liczy się zgodność wersji, aktualizacje i wsparcie autora. Największe koszty nie siedzą w cenie licencji, tylko w obejściach braków darmowych rozwiązań i w godzinach straconych na konflikty. Każdą instalację poprzedź kopią bazy i plików, testem na kopii sklepu oraz zamówieniem testowym end-to-end. Jeśli moduł nie działa po instalacji, diagnozuj logi i override, zamiast reinstalować cały sklep.
Część jest darmowa, część płatna — oba modele są normalne na Marketplace. Darmowy moduł nadal kosztuje Twój czas: konfigurację, tłumaczenia, obejścia braków. Płatny kosztuje pieniądze, ale zwykle dostajesz wsparcie i aktualizacje pod kolejne wersje PrestaShop.
Nie ma jednej ceny — wszystko zależy od licencji, liczby domen i długości wsparcia. Są moduły rozliczane jednorazowo i takie z corocznym odnowieniem, a integracje ERP czy nietypowe logiki cenowe wyceniane są indywidualnie. Zanim porównasz oferty, ustal koszt po pierwszym roku, bo to on decyduje o opłacalności. Kontekst budżetowy znajdziesz w naszym cenniku PrestaShop.
Rozpakuj paczkę tak, aby katalog modułu (z plikiem głównym .php) trafił bezpośrednio do /modules/, a nie do /modules/paczka/modul/. Potem wejdź w panel: Moduły > Menedżer modułów i kliknij Instaluj. Po instalacji wyczyść cache i sprawdź, czy moduł pojawił się na liście oraz czy nie zgłasza błędów PHP.
Najczęstsze przyczyny to zagnieżdżony katalog i brak uprawnień. Sprawdź, czy plik główny modułu leży w /modules/nazwa_modulu/ i czy nazwa katalogu nie zawiera spacji ani wielkich liter niezgodnych z konwencją. Zweryfikuj uprawnienia katalogu i właściciela plików, wyczyść cache i odśwież listę w panelu.
Zacznij od wyłączenia modułów zainstalowanych jako ostatnie, po jednym, i sprawdzaj efekt. Zajrzyj do katalogu /override/ — jeśli dwie klasy nadpisują ten sam plik rdzenia, masz konflikt. Włącz tryb deweloperski (_PS_MODE_DEV_) i czytaj logi PHP, zamiast zgadywać.
Wtedy, gdy gotowe rozwiązania nie obsługują Twojej logiki: nietypowego cennika, dedykowanego ERP albo specyficznej integracji kurierskiej. Pisanie własnego modułu ma sens, gdy koszt obejść i pracy ręcznej przewyższa koszt developmentu. Strukturę modułu opisuje dokumentacja deweloperska PrestaShop — warto ją przejrzeć jeszcze przed rozmową z wykonawcą.
Może, jeśli moduł nie był testowany z nowszą wersją rdzenia. Dlatego przed aktualizacją sprawdź wydania modułów, zrób kopię i przetestuj sklep na kopii. Sposób czytania wydań i planowania aktualizacji opisujemy w artykule PrestaShop news. Jeśli korzystasz z modułu motywu, zobacz też materiał o motywach PrestaShop.
Jeśli chcesz przejść przez wybór i wdrożenie modułów bez przestojów w sprzedaży, zajrzyj na naszą stronę PrestaShop albo napisz do nas z listą funkcji, których brakuje w Twoim sklepie.