Moduł to paczka kodu podpinana do sklepu przez hooki – bez dotykania plików core. Dobry moduł aktualizuje się razem z platformą i PHP, nie zostawia śmieci w bazie po odinstalowaniu i nie dokłada sekundy do czasu odpowiedzi na każdej podstronie. Zły potrafi zrobić dokładnie odwrotnie: spowolnić sklep, wysypać się po aktualizacji albo wypuścić dane osobowe z formularza do zwykłego pliku tekstowego. Poniżej masz listę cech, które sprawdzamy przed każdym wdrożeniem, najczęstsze błędy oraz pytania, które warto zadać producentowi modułu, zanim zapłacisz.
Moduł w PrestaShop to paczka kodu w katalogu /modules/, zawierająca plik główny (np. mojmodul.php) z klasą dziedziczącą po Module. Moduł rejestruje się przez hooki – metody takie jak registerHook('displayHeader') – i nie modyfikuje plików core. Działa jak wtyczka w WordPressie, ale w PrestaShop ma ściśle określoną strukturę. Oficjalna dokumentacja PrestaShop dla deweloperów opisuje strukturę modułu i dostępne hooki.
Override to plik w katalogu /override/, który nadpisuje klasę core (np. Cart.php). Po aktualizacji PrestaShop override może przestać działać, bo zmieniła się sygnatura metody. To dług techniczny: przy każdej aktualizacji musisz sprawdzać, czy override nie łamie nowej wersji. Podobnie własny kod w motywie (np. w functions.php WooCommerce) to ryzyko – zmiana motywu go usuwa, a błędy trudno debugować.
W polskim sklepie najczęściej instalowane moduły to: bramki płatności (Przelewy24, PayU, tpay), kurierzy (InPost, DPD, DHL), faktury (Fakturownia, ifirma), magazyn (Subiekt, WF-Mag) i ERP (Comarch Optima). W PrestaShop 1.7 i 8 moduły mogą korzystać z Symfony i service container – nowoczesne moduły używają services.yml i wstrzykiwania zależności. W WooCommerce wtyczka to zwykły plugin PHP w WordPressie, komunikujący się przez add_action i add_filter. Nie myl go z motywem.
Przed wdrożeniem modułu przechodzimy przez 12 punktów kontrolnych. Każdy ma konkretne kryterium sprawdzenia – patrzymy na kod, konfigurację i dokumentację. Oto lista, którą stosujemy w DropDigital.
Jeśli moduł nie przechodzi któregoś punktu, odpada.
Decyzja między modułem gotowym a pisanym pod sklep sprowadza się do kosztów i kontroli. Typowe modele licencjonowania modułów z marketplace to: jednorazowa opłata (200–2000 zł netto), subskrypcja roczna (100–500 zł/rok), licencja na domenę lub na instancję (np. przy multistore płacisz za każdy sklep). Przed zakupem sprawdź, czy cena obejmuje aktualizacje i wsparcie.
Ukryty koszt modułu zewnętrznego: nie masz dostępu do kodu, więc poprawka błędu może zająć dni lub tygodnie. Jeśli producent nie odpowiada w 24 h, a Ty masz black Friday, tracisz sprzedaż. Jesteś też zależny od jego roadmapy – funkcja, której potrzebujesz, może nigdy nie powstać. Przykład: moduł do InPost działa, ale nie obsługuje nietypowej reguły pakowania – wtedy i tak zlecasz custom.
Moduł własny wygrywa, gdy: masz nietypową logikę cenową (rabaty progresywne zależne od marży), specyficzne B2B (ceny ukryte, limity kredytowe), niestandardowy proces zamówienia (np. zamówienia składane przez przedstawiciela). Wtedy gotowy moduł nie pasuje, a obejście go override to dług techniczny.
Gotowy moduł wygrywa przy standardowej integracji z kurierem lub bramką płatniczą z aktywnym wsparciem. Przykład: Przelewy24 – moduł producenta aktualizowany przy zmianach API. Koszt własnego to 3000–8000 zł, a gotowy 500 zł/rok.
Ryzyko zamrożenia wersji: gdy producent przestaje aktualizować moduł, a platforma wchodzi na nowe PHP (np. PHP 8.2), moduł może przestać działać. Wtedy masz dwie opcje: płacisz za fork lub piszesz od nowa. Dlatego przed zakupem sprawdź datę ostatniej aktualizacji i deklarację wsparcia dla PHP 8.x.
Zły moduł poznasz po liczbach, nie po opisie. Pierwszy sygnał to wzrost TTFB (Time To First Byte) po włączeniu wtyczki. Różnica powyżej 100–150 ms na każdej podstronie oznacza, że moduł robi coś, czego robić nie powinien. Drugi sygnał to zapytania w pętli: lista 50 zamówień w panelu generuje 50 osobnych zapytań do bazy albo 50 odpytań API operatora o ten sam słownik statusów. Trzeci, najbardziej kosztowny: moduł pobiera dane kurierskie (mapę punktów, cennik, statusy przesyłek) na każdej podstronie — także na stronie głównej i w karcie produktu, gdzie nikt o to nie prosił.
Jak to zmierzyć w 20 minut:
TTFB przekłada się na LCP, więc opóźnienia widać też w danych z Search Console — mechanikę opisuje dokumentacja Web Vitals.
Bezpieczeństwo — cztery błędy, które widzimy najczęściej:
Ostatnia pułapka: konflikt z pełnym cache i kompilacją szablonów. Po włączeniu modułu wyczyść cache i przekompiluj szablony, a potem sprawdź sklep jako niezalogowany gość. Moduł, który działa wyłącznie przy wyłączonym cache, nie nadaje się do produkcji.
| Objaw | Jak sprawdzić | Co to najczęściej znaczy |
|---|---|---|
| TTFB wyższy o 150 ms+ na każdej podstronie | Pomiar po wyłączeniu modułu, ta sama kopia bazy | Zapytanie do API lub bazy w hooku globalnym |
| Lista zamówień ładuje się dłużej po instalacji | Profiler / Query Monitor, liczba zapytań na wiersz | Zapytania N+1 przy renderowaniu listy |
| Mapa punktów ładowana poza krokiem dostawy | Sprawdzenie źródła strony w kartach produktu | Skrypt i dane wgrywane na wszystkich stronach |
| Zmiany widoczne tylko przy wyłączonym cache | Test w trybie incognito, po wyczyszczeniu cache | Zły hook albo brak obsługi kompilacji szablonów |
Większość awarii po wdrożeniu modułu nie wynika z błędów w kodzie, tylko z różnicy środowisk. Dlatego przed instalacją na produkcji przechodzimy matrycę testów. To nie biurokracja — to 2–3 godziny, które ratują weekend kampanii promocyjnej.
Testuj na kopii z realnymi danymi, nie na pustej instalacji. Pusta baza nie ujawni problemów wydajnościowych ani konfliktów z innymi modułami. Potrzebujesz kopii, która ma: kilkaset–kilka tysięcy produktów z wariantami, historię zamówień, aktywny motyw z nadpisaniami szablonów i wszystkie moduły produkcyjne. Wtedy widzisz, czy nowy modul nie dubluje hooka, nie przesłania szablonu i nie spowalnia koszyka.
Środowisko staging i procedura cofnięcia. Przed wdrożeniem: kopia plików i bazy (snapshot), zapisany czas wdrożenia, lista zmienionych plików. Plan rollbacku musi odpowiadać na pytanie, co zrobić z tabelami w bazie, które moduł tworzy — wyłączenie modułu ich nie usuwa. Wdróż poza szczytem sprzedażowym, najlepiej rano w dzień roboczy, i zostań przy komputerze przez godzinę po.
Wielosklepowość. Sprawdź, czy konfiguracja modułu jest globalna, czy per sklep — w PrestaShopie część ustawień zapisuje się dla wszystkich sklepów naraz. Zapytaj producenta: czy moduł dzieli magazyn między sklepami, czy ma osobnych nadawców i osobne webhooki. Jeśli nie, etykieta z jednego sklepu może polecieć z danymi drugiego.
Panel administracyjny. Zmierz czas ładowania listy zamówień i produktów przed i po instalacji. Moduł dodający kolumnę z danymi z API potrafi wydłużyć wczytywanie listy z 1 s do 6 s — pracownicy obsługi odczują to pierwszego dnia. Szczegóły hooków i nadpisań szablonów opisuje dokumentacja dla deweloperów PrestaShop.
| Wymiar | Co sprawdzić | Typowy problem |
|---|---|---|
| Wersja platformy | Dokładna wersja i wersja modułu z changeloga | Moduł pisany pod starszą gałąź, brak wsparcia dla nowej |
| Wersja PHP | Zgodność z wersją docelową, nie tylko obecną | Deprecated warnings i błędy po podniesieniu PHP |
| MySQL / MariaDB | Wersja, tryb ONLY_FULL_GROUP_BY, kodowanie utf8mb4 | Zapytania wywalające się po zmianie serwera |
| Motyw | Nadpisania szablonów i szablony maili | Zmiany modułu niewidoczne po aktualizacji motywu |
| Inne moduły | Kolejność w hooku, dublowane funkcje | Podwójne pobieranie danych lub konflikt JS |
| Multistore | Zakres konfiguracji i podział danych | Ustawienia nadpisane między sklepami |
Tu teoria kończy się najszybciej, bo każda awaria API to realny klient, który nie dostał paczki. Zasada numer jeden: zamówienie musi się zapisać nawet wtedy, gdy API operatora nie odpowiada. Moduł, który blokuje checkout, bo nie dostał odpowiedzi z API płatności albo kuriera, jest wadliwy — kropka.
API i webhooki. Pytaj o kolejkę i ponowienia. Dobre zachowanie: żądanie trafia do kolejki, jest ponawiane z rosnącym odstępem (np. 1 min, 5 min, 30 min), po ustalonej liczbie prób ląduje w logu z błędem do ręcznej obsługi. Timeout żądania powinien wynosić 5–10 s, nie 30 s. Webhooki muszą być idempotentne — ten sam status przysłany dwa razy nie może wygenerować dwóch maili do klienta.
Tryb testowy (sandbox). Sprawdź, czy moduł ma osobne dane dostępowe do środowiska testowego i czy po przełączeniu na produkcję nie zostawia testowych numerów przesyłek. Testuj pełną ścieżkę: wybór punktu odbioru na mapie, generowanie etykiety i listu przewozowego, zamówienie kuriera.
Statusy zamówień. To najczęstsze źródło bałaganu. Ustal tabelę mapowania: jaki status w sklepie odpowiada jakiemu zdarzeniu u operatora, kto go ustawia (moduł czy człowiek) i które statusy wysyłają maila. Bez tego dokumentu po miesiącu nikt nie wie, dlaczego klient dostał powiadomienie o wysyłce przed jej nadaniem.
ERP. Ustal kierunek przepływu: stany magazynowe i ceny zwykle idą z ERP do sklepu, zamówienia i faktury ze sklepu do ERP. Zdecyduj o częstotliwości (co 5 minut, co godzinę, na zdarzenie) i o tym, kto nadaje numer faktury — musi być ciągły. Na koniec: moduł powinien logować identyfikator zamówienia, numer przesyłki, kod błędu operatora i czas odpowiedzi. Wtedy w 5 minut ustalisz, czy problem jest po stronie sklepu, czy operatora.
| Sytuacja | Oczekiwane zachowanie modułu | Czerwona flaga |
|---|---|---|
| API kuriera zwraca błąd 500 lub timeout | Kolejka, ponowienie, wpis w logu, status zamówienia bez zmian | Błąd 500 widoczny dla klienta w koszyku |
| Webhook przychodzi dwukrotnie | Ta sama operacja wykonana raz, brak duplikatów maili | Dwa powiadomienia o tej samej zmianie statusu |
| Brak danych punktu odbioru | Blokada złożenia zamówienia z jasnym komunikatem | Zamówienie bez punktu, etykieta z błędnym adresem |
| ERP niedostępny w trakcie synchronizacji | Synchronizacja wznawiana, brak nadpisania cen zerem | Zerowanie cen lub stanów magazynowych |
| Zmiana statusu u operatora | Jeden przypisany status sklepu, zdefiniowany kto go ustawia | Kilka statusów ustawianych równolegle |
Nie ma uczciwej odpowiedzi w stylu „moduł kosztuje 2 000 zł”. Koszt to liczba godzin pomnożona przez stawkę zespołu. Żeby ta liczba była prawdziwa, najpierw trzeba wiedzieć, co moduł ma robić i w jakim sklepie ma działać.
Widełki godzinowe
Co wydłuża pracę
Co skraca pracę: sandbox dostawcy API, gotowe SDK, webhooki działające na środowisku testowym, opisany krok po kroku proces biznesowy, dostępy przekazane w ciągu 24 godzin. Te pięć rzeczy potrafi ściąć wycenę o jedną trzecią.
Co powinna zawierać wycena: analizę (4–8 h), kod, testy z listą przypadków, wdrożenie na produkcję, dokumentację konfiguracji i hooków, 30–90 dni opieki powdrożeniowej oraz SLA z zapisanym czasem reakcji, np. 4 h w dni robocze. Jeśli w ofercie jest tylko „moduł plus wdrożenie”, brakuje połowy roboty.
Wycena bez poznania sklepu jest zawsze nieprawdziwa, bo cena zależy od liczby modułów, override’ów w core, customowego szablonu, wersji PHP i konfiguracji hostingu. Rzetelny proces wygląda tak: rozmowa 30–45 minut o procesie, potem audyt techniczny 2–4 h na kopii sklepu, a dopiero na końcu oferta z zakresem, założeniami i listą wykluczeń. Zakres techniczny modułu po stronie PrestaShop opisuje dokumentacja dla deweloperów PrestaShop — warto zajrzeć choćby po to, żeby rozumieć, o co pyta wykonawca.
| Typ modułu | Widełki godzinowe | Co zawiera | Główne ryzyko |
|---|---|---|---|
| Prosty funkcjonalny | 16–40 h | 1–2 hooki, panel w back office, brak zewnętrznego API | Moduł porzucony przez autora |
| Średni | 40–100 h | Eksport danych, integracja z jednym API, konfiguracja w panelu | Zmiany w API po stronie dostawcy |
| Integracyjny | 100–250 h i więcej | Synchronizacja, webhooki, obsługa scenariuszy błędów, kolejka zadań | Brak sandboxa i dokumentacji API |
Pięć pytań, na które odpowiadasz przed podpisaniem zamówienia. Jeśli na którekolwiek nie umiesz odpowiedzieć, nie kupujesz — najpierw zbierasz dane.
Rekomendacja dla MŚP: gotowy moduł na wszystko, co standardowe, własny tam, gdzie budujesz przewagę konkurencyjną. Własny moduł ma sens dopiero wtedy, gdy proces realnie różni cię od konkurencji i wiesz, że nie zmieni się co kwartał.
Opieka po wdrożeniu: ustal, kto odbiera zgłoszenia w piątek o 16:00 przed kampanią i w jakim czasie reaguje. W umowie zapisz kanał zgłoszeń, czas reakcji, zakres poprawek w cenie i to, kto przechowuje dostępy oraz kopie zapasowe.
Lista kontrolna przed zakupem
Zakup modułu na podstawie strony sprzedażowej, bez sprawdzenia deklarowanej zgodności z wersją platformy i PHP 8.x.
Jak wykryć: Zajrzyj w changelog: brak wpisów o PHP 8.x i ostatnia aktualizacja starsza niż 12 miesięcy to czerwona flaga. Sprawdź też, czy producent wprost podaje wspierane wersje PrestaShop lub WordPress/WooCommerce.
Jak naprawić: Zapytaj producenta pisemnie o wsparcie dla konkretnej wersji platformy i PHP, jakiej używasz. Przetestuj moduł na kopii sklepu (staging), zanim wdrożysz go na produkcję.
Instalacja modułu, który edytuje pliki core albo wrzuca własne pliki do katalogu override.
Jak wykryć: Porównaj pliki core z czystą instalacją tej samej wersji (możesz użyć repozytorium platformy lub kopii zapasowej) i przejrzyj zawartość katalogu override. Każdy plik, którego tam nie było przed instalacją, jest podejrzany.
Jak naprawić: Poproś dewelopera o przepisanie logiki na hooki. Jeśli to niemożliwe, zaplanuj wersjonowanie zmian i sprawdzanie konfliktów po każdej aktualizacji platformy – inaczej przy pierwszym większym upgradzie sklep padnie.
Włączenie modułu bezpośrednio na produkcji, bez pomiaru czasu odpowiedzi i liczby zapytań SQL przed i po.
Jak wykryć: Zapisz TTFB oraz liczbę zapytań na kluczowych stronach (strona główna, kategoria, karta produktu, koszyk, checkout) przed instalacją i po niej. Wzrost TTFB o więcej niż kilkadziesiąt milisekund lub skok liczby zapytań wymaga wyjaśnienia.
Jak naprawić: Wdrażaj na stagingu, profiluj zapytania, a dopiero potem przenoś na produkcję. Jeśli moduł pobiera dane z zewnętrznego API, sprawdź, czy nie robi tego na każdej podstronie.
Brak sprawdzenia, co moduł zostawia w bazie i konfiguracji po odinstalowaniu.
Jak wykryć: Zrób kopię bazy, zainstaluj i odinstaluj moduł na stagingu, a następnie porównaj listę tabel oraz wpisów w tabeli configuration (PrestaShop) albo options i wpisy własnych tabel (WooCommerce).
Jak naprawić: Jeśli moduł nie czyści po sobie, ustal z deweloperem zakres sprzątania albo zaplanuj ręczne usunięcie pozostałości i udokumentuj to w instrukcji utrzymania sklepu.
Klucze API i dane osobowe w miejscach, do których ma dostęp frontend lub zbyt wiele osób.
Jak wykryć: Wyszukaj klucze w plikach motywu i skryptach ładowanych do przeglądarki, sprawdź podgląd źródła strony. Przejrzyj logi modułu i pliki eksportu CSV – jeśli trafiają tam adresy, telefony lub e-maile, masz problem.
Jak naprawić: Przenieś klucze do konfiguracji po stronie serwera, ogranicz dostęp do katalogów z eksportami, ustaw retencję plików z danymi osobowymi i uzgodnij z producentem modułu zasady przetwarzania danych.
Założenie, że zakup modułu oznacza natychmiastowe wsparcie producenta.
Jak wykryć: Wyślij testowe zapytanie do supportu przed zakupem i zmierz czas odpowiedzi. Sprawdź, czy wsparcie jest wliczone w licencję, czy płatne osobno, i czy obejmuje konflikty z innymi modułami.
Jak naprawić: Ustal kanał kontaktu, oczekiwany czas reakcji i zasady zgłaszania błędów jeszcze przed zakupem. Jeśli moduł obsługuje krytyczny proces (płatności, kurierzy, faktury), wpisz te ustalenia do umowy lub regulaminu.
Moduł to element architektury sklepu, a nie ozdoba – albo działa w ramach reguł platformy, albo je łamie i generuje dług techniczny. Przed zakupem sprawdź zgodność z Twoją wersją platformy i PHP, brak modyfikacji core, jakość zapytań SQL, bezpieczeństwo i to, co moduł zostawia po odinstalowaniu. Kupuj gotowe rozwiązania tam, gdzie logika jest standardowa, a pisz własne tam, gdzie procesy są nietypowe. Każdą instalację zmierz na stagingu, zanim trafi na produkcję.
Funkcjonalnie to to samo: dodatkowa paczka kodu rozszerzająca sklep. Różni się architektura. W PrestaShop moduł podpina się przez hooki, a od wersji 1.7 część kodu działa w oparciu o Symfony i service container. W WooCommerce wtyczka to plugin WordPressa korzystający z akcji i filtrów. Dokumentację techniczną PrestaShop znajdziesz w PrestaShop Developer Documentation.
Gotowy moduł wygrywa przy standardowych integracjach: bramka płatnicza, kurier, faktury, księgowość – tam liczy się aktualne wsparcie i gotowe testy. Własny moduł wygrywa, gdy logika jest nietypowa: indywidualne progi cenowe, specyficzne B2B, niestandardowy proces zamówienia. Policz koszt licencji, czasu wdrożenia i utrzymania oraz ceny awaryjnej poprawki po stronie producenta i porównaj to z jednorazowym kosztem napisania modułu, który możesz edytować bez ograniczeń.
Zmierz TTFB i liczbę zapytań SQL na najważniejszych stronach przed włączeniem modułu i po nim. Wyłącz moduł na chwilę (najlepiej na stagingu), powtórz pomiar i porównaj wyniki. Sprawdź też, czy moduł nie pobiera danych z zewnętrznego API na każdej podstronie – to typowa przyczyna wolnego sklepu. Punkt odniesienia dla metryk znajdziesz w web.dev – Web Vitals.
Override to dług techniczny. Nadpisuje klasy core, więc po każdej aktualizacji platformy trzeba sprawdzić, czy plik nadal pasuje do nowej wersji. W większości przypadków tę samą funkcję da się osiągnąć hookiem. Jeśli override jest jedynym wyjściem, zapisz go, udokumentuj i pamiętaj o nim przy każdym upgradzie.
Trzy rzeczy: jakie dane moduł zbiera, gdzie je wysyła i jak długo trzyma. Sprawdź logi, eksporty CSV i to, czy dane nie trafiają do plików dostępnych publicznie. Jeśli moduł przekazuje dane do zewnętrznego serwisu, potrzebujesz umowy powierzenia i informacji, na jakich serwerach dane są przetwarzane. Warto też ustalić czas retencji plików i ograniczyć liczbę osób z dostępem.
Tak i zdarza się to często. Moduły tworzą własne tabele i wpisy w konfiguracji, a część z nich nie usuwa ich przy deinstalacji. Sprawdź to na kopii bazy: zainstaluj, skonfiguruj, odinstaluj i porównaj stan tabel oraz konfiguracji. Jeśli pozostałości nie da się usunąć automatycznie, zaplanuj sprzątanie ręczne i opisz je w instrukcji utrzymania.
Nie ma jednej dobrej odpowiedzi, bo zależy to od tempa zmian platformy i PHP. Praktyczne kryterium to aktualizacje reagujące na nowe wersje platformy i PHP – jeśli w changelogu od roku nic się nie dzieje, ryzyko jest wysokie. Zapytaj producenta o politykę wsparcia i plan na kolejne wersje PHP. Brak odpowiedzi też jest odpowiedzią.
Jeśli nie masz pewności, czy moduł, który rozważasz, albo ten już zainstalowany, nie szkodzi sklepowi, napisz do nas – sprawdzimy kod, zapytania SQL i konfigurację na kopii sklepu. Doradzimy też, co opłaca się kupić, a co lepiej napisać pod Twój proces.