Czym są niestandardowe moduły i wtyczki — i czym nie są

W PrestaShop moduł niestandardowy to katalog w /modules/, np. /modules/kalkulatordostawy/, z plikiem głównym kalkulatordostawy.php. Klasa dziedziczy po Module, a metoda install() rejestruje hooki i tworzy własne tabele. Rejestracja hooka to wpis w bazie (ps_hook_module), więc odinstalowanie musi być przemyślane — inaczej zostają osierocone wpisy i kolumny. W WordPressie wtyczka to katalog w /wp-content/plugins/, a podpięcie do systemu to add_action() i add_filter(); hooki istnieją tylko w kodzie i znikają razem z dezaktywacją pliku. Jedna różnica techniczna, ale dwa cykle życia: moduł PrestaShop trzeba sprawdzać przy każdej aktualizacji sklepu (1.7.x vs 8.x), wtyczka WordPress najczęściej sypie się po zmianie wersji PHP albo WooCommerce.

Zamawiając „niestandardowy moduł”, dostajesz zwykle jeden z trzech wariantów, a każdy ma inny koszt utrzymania:

• Kod od zera — pełna kontrola, ale cała odpowiedzialność za aktualizacje po Twojej stronie.
• Fork istniejącego pluginu — szybki start, za to każda aktualizacja oryginału to ręczne scalanie zmian. Po dwóch latach fork staje się nieaktualizowalny.
• Child theme lub override szablonu — do warstwy wyglądu, nie do logiki. Nie nadaje się na kalkulatory i integracje.

Czym to nie jest: snippet wklejony w functions.php, poprawka w pliku core, kupiony plugin z marketplace z drobną zmianą koloru. Trzy powody: pierwsza aktualizacja kasuje zmiany, nie ma wersjonowania, nikt nie wie, kto to pisał.

Przykład: sklep z produktami regionalnymi z Krasnobrodu potrzebuje kalkulatora dostawy — paczkomat InPost plus odbiór osobisty w Punkcie przy rynku. To logika zależna od wagi gabarytowej i strefy, nie od wyglądu — czyli moduł, nie override. Jak ustawić kolejność zadań przy takim projekcie, opisaliśmy w artykule o organizacji pracy nad niestandardowymi modułami i wtyczkami.

Własny moduł czy gotowy plugin? Tabela decyzyjna

Sześć kryteriów, które przechodzisz przed każdą wyceną:

• Unikalność procesu — czy da się to obsłużyć standardowym mechanizmem sklepu?
• Liczba integracji — im więcej zewnętrznych API (InPost, kurier, płatności, Subiekt), tym większy sens ma własny kod.
• Roczny koszt licencji — 400–1500 zł/rok za plugin to norma, powyżej 3000 zł licz się z alternatywą.
• Ryzyko porzucenia pluginu — sprawdź datę ostatniej aktualizacji i liczbę wspieranych wersji PHP.
• Wymagania wydajnościowe — wtyczki robiące zapytania w pętli potrafią wyłożyć stronę przy 5 tys. SKU.
• Dane osobowe — jeśli plugin wysyła dane klientów na zewnętrzny serwer, ocena ryzyka jest Twoja, nie autora.

Reguła praktyczna: jeśli proces występuje u mniej niż ~100 firm w Polsce — np. specyficzny cennik usług uzdrowiskowych z zabiegami łączonymi albo wypożyczalnia sprzętu wodnego z kaucją — buduj własny. Jeśli to standard: faktury, koszyk, formularz kontaktowy, newsletter — kupuj gotowy.

Przykład kosztowy: plugin 500 zł/rok przez 5 lat to 2500 zł. Własny moduł: 40 h × 150 zł = 6000 zł jednorazowo, plus utrzymanie. Własny kod nadal się opłaca, gdy daje przewagę, której nie kupisz (własny algorytm wyceny dostawy), gdy nie ma żadnej alternatywy na rynku albo gdy dane klientów muszą zostać na Twoim serwerze.

Sygnał ostrzegawczy: plugin z 200 tys. instalacji i ostatnią aktualizacją sprzed 3 lat. Instalacje nic nie znaczą — znaczy data commita i testy z bieżącą wersją PHP.

Ile to realnie kosztuje: widełki godzinowe i złotowe

Stawka godzinowa na polskim rynku w 2025 to 120–220 zł netto — zależnie od seniority, regionu i tego, czy pracuje zespół czy jedna osoba. Sama stawka nie mówi nic o końcowym koszcie: wykonawca za 120 zł, który pierwszy raz widzi hooki PrestaShop, zrobi robotę w 60 h, a osoba za 200 zł w 25 h. Liczy się iloczyn, nie cena za godzinę.

Co siedzi w każdej godzinie: analiza i brief 15–25%, kod 40–50%, testy 15–20%, dokumentacja i przekazanie 5–10%. Wsparcie po wdrożeniu wycenia się osobno — najczęściej pakietem 5–10 h.

Przykład pełnego wyliczenia dla Krasnobrodu: kalkulator dostawy z regułami wagi gabarytowej (próg 25 kg na paczkomat), strefami odbioru i odbiorem w Punkcie przy rynku — 28 h × 150 zł = 4200 zł netto, plus 6 h wsparcia po starcie. W tej kwocie jest 6 h analizy (ustalenie, co robić, gdy produkt nie mieści się w skrytce), 14 h kodu, 5 h testów na realnych zamówieniach i 3 h dokumentacji: gdzie zmienić próg wagi i jak dodać nową strefę bez dzwonienia do dewelopera.

Dlaczego godziny są bezpieczniejsze niż sztywne „od–do”: wycena bez zakresu prawie zawsze kończy się dopłatą albo niedokończonym modułem. Wycena w godzinach z rozpisanym zakresem pozwala porównać dwie oferty punkt po punkcie — i zobaczyć, że tańsza oferta ma o 10 h mniej testów. Przy integracjach z Subiektem, baselinkerem czy ERP rozstrzał jest największy, bo zależy od jakości dokumentacji API dostawcy. Więcej o tym w materiale o integracjach z ERP, płatnościami i kurierami.

Proces od briefu do wdrożenia w 7 krokach

Ten sam układ kroków stosujemy przy module do PrestaShop i przy wtyczce do WordPressa. Różni się tylko technologia, nie kolejność.

1. Rozmowa i cele biznesowe — 1–2 h. Kończy się notatką: jaki problem znika i po czym poznamy, że zniknął. Nie „usprawnienie obsługi”, ale „pracownik nie przepisuje ręcznie 40 zamówień dziennie do ERP”.
2. Brief i kryteria akceptacji — 2–4 h. Dokument, do którego wracamy przy odbiorze.
3. Wycena i zakres — 1–2 h. Kwota, termin i osobna lista rzeczy „poza zakresem”.
4. Prototyp logiki bez UI — 4–8 h. Najpierw sprawdzamy reguły na przykładowych danych, zanim ktokolwiek dotknie wyglądu.
5. Implementacja. Czas zależy od zakresu — to zwykle największa pozycja w wycenie. Kod ląduje w repozytorium Git, commit po commicie.
6. Testy na kopii sklepu. Czas zależy od liczby przypadków testowych. Na produkcji nie testujemy nigdy.
7. Wdrożenie produkcyjne i szkolenie. Krótkie nagranie ekranu plus jednostronicowa instrukcja dla pracownika.

Krok	Czas	Efekt
1. Rozmowa i cele	1–2 h	notatka z celem i miarą sukcesu
2. Brief i kryteria akceptacji	2–4 h	lista warunków odbioru
3. Wycena i zakres	1–2 h	kwota, termin, lista „poza zakresem”
4. Prototyp logiki bez UI	4–8 h	działające reguły na danych testowych
5. Implementacja	wg wyceny	kod w repozytorium
6. Testy na kopii sklepu	wg liczby przypadków	lista sprawdzonych scenariuszy
7. Wdrożenie i szkolenie	1–3 h	działający moduł i instrukcja

Definition of Done to lista zdań, nie „moduł działa”. Przykład: moduł poprawnie liczy koszt dostawy przy 500 produktach w katalogu i 3 strefach dostawy, loguje każdy nieudany request do integracji z datą i numerem zamówienia, jest w repozytorium z historią commitów, da się wyłączyć jednym kliknięciem, a instrukcja ma maksymalnie 2 strony.

Środowisko testowe: kopia sklepu na subdomenie (np. test.twojadomena.pl), baza zanonimizowana — zamówienia i klienci na danych fikcyjnych, bo kopia produkcyjnej bazy to dane osobowe. Wdrożenie planujemy poza szczytem ruchu, zanim zacznie się poranny szczyt zamówień.

Wsparcie powdrożeniowe: pierwsze 30 dni poprawki błędów blokujących na koszt wykonawcy — o ile w umowie jest definicja takiego błędu („uniemożliwia złożenie zamówienia lub pokazuje błędną kwotę”). Potem pakiet godzinowy, np. 5 h miesięcznie. Zapisz też czas reakcji i kanał zgłoszeń oraz zdanie, że nowa funkcja nie jest poprawką błędu. To jest utrzymanie i opieka techniczna sklepu w praktyce.

Plan wycofania: flaga włącz/wyłącz w konfiguracji i zero twardych zależności w szablonie — szablon wywołuje hook, nie kod modułu. Wtedy wyłączenie modułu w panelu przywraca poprzednie zachowanie sklepu. Podobne zasady porządkowania etapów opisaliśmy w tekście o tym, jak zorganizować pracę nad niestandardowym modułem.

Brief, który nie wygeneruje trzech razy więcej godzin

Brief to nie elaborat — jednostronicowy dokument, który czytasz na głos w 5 minut. Musi mieć osiem punktów i każdy z nich zapisany konkretnie.

Punkt briefu	Co musi być zapisane konkretnie	Przykład
Cel biznesowy	liczba, nie hasło	„skrócenie pakowania zamówienia o 30%”
Użytkownicy	kto klika i z jakim prawem	magazynier na tablecie, tylko rola „Magazyn”
Przypadki użycia	krok po kroku, co robi człowiek	„skanuje etykietę, system drukuje list przewozowy”
Reguły biznesowe	warunki i wyjątki	„powyżej 31,5 kg wyłącz paczkomat”
Integracje zewnętrzne	nazwy systemów i kierunek danych	ERP do sklepu: stany magazynowe co 15 min
Wydajność	liczby	lista 5000 zamówień wczytuje się w 3 s
Dane i RODO	co zapisujemy i jak długo	logi z numerem zamówienia, bez danych klienta, 90 dni
Kryteria akceptacji	zdania, które da się przetestować	przy 500 produktach koszt dostawy liczy się w 1 s

Osobno opisz przypadki brzegowe. Cztery, które w praktyce generują najwięcej godzin: produkt o wadze 31,5 kg, który nie mieści się w paczkomacie; kod rabatowy łączony z ceną B2B — czy mnożą się, czy się sumują; brak dostępności strefy InPost, gdy kurier nie odpowiada; zamówienie z odbiorem osobistym, które nie powinno doliczać żadnej wysyłki. Każde z tych niedopowiedzeń to zwykle 2–8 dodatkowych godzin na etapie testów — płacisz za nie Ty, bo wykonawca i tak musi coś wymyślić.

Zmień też procedurę zmiany zakresu na pisemną. Każda zmiana to osobny mail z zakresem, liczbą godzin i nową datą oddania, zatwierdzony przed rozpoczęciem pracy. Bez tego po dwóch tygodniach nie ustalisz, co było ustalone.

Dobre briefy mają jeszcze jedno: ustalenia o kodzie. Nazewnictwo, repozytorium, brak nadpisywania plików core — opisaliśmy to w tekście o porządku w kodzie niestandardowych modułów i wtyczek. Jeśli moduł dotyka kurierów lub płatności, zajrzyj też do materiału o integracjach z ERP, płatnościami i kurierami.

Pułapki: dług techniczny, konflikty z aktualizacjami, brak testów

Cztery błędy wracają w niemal każdym modułze, który trafia do nas po innym wykonawcy.

1. Nadpisywanie plików core i szablonu. Zmiana idzie do pliku PrestaShop zamiast do hooka. Pierwsza aktualizacja sklepu kasuje zmianę albo blokuje aktualizację.
2. Brak użycia hooków. Kod wklejony na sztywno do szablonu sprawia, że wyłączenie modułu nie wyłącza funkcji.
3. Praca bez repozytorium Git. Pliki wysyłane FTP-em. Nie ma historii, nie ma cofnięcia, nie ma podziału na wersje.
4. Brak logowania błędów. Gdy integracja padnie o 3:00 w nocy, nie ma śladu, co poszło nie tak.

Skutki widać po fakcie: aktualizacja WooCommerce wysypuje sklep, bo moduł nadpisał szablon; nikt nie wie, która linia odpowiada za błędną kwotę dostawy; dwa moduły konkurują o ten sam hook i o kolejności wywołań decyduje przypadek. Frameworki mają na to gotowe mechanizmy — warto sprawdzić w dokumentacji dla deweloperów PrestaShop, czy wykonawca faktycznie z nich korzysta, czy tylko tak twierdzi.

Pytanie do wykonawcy	Konkretna odpowiedź
Gdzie jest kod?	W repozytorium Git, z linkiem i dostępem dla Ciebie — nie „na serwerze wykonawcy”
Jak wdrożyć na czystą instalację?	Instrukcja krok po kroku; test: stawiamy moduł na pustym sklepie w 15 minut
Co się stanie po aktualizacji?	Lista dotykanych hooków i tabel, zero nadpisań plików core
Gdzie są logi?	Ścieżka pliku albo tabela w bazie, plus sposób zmiany poziomu logowania
Kto ma prawa do repozytorium?	Ty jako właściciel projektu; wykonawca dostaje dostęp, nie własność

Zanim podpiszesz umowę, poproś o historię commitów z innego projektu, sprawdź, czy istnieje katalog z testami, i zobacz, czy moduł da się wyłączyć jednym kliknięciem w panelu. Trzy minuty sprawdzania.

Dług techniczny w liczbach: moduł pisany dwa dni bez testów kosztuje zwykle 1–2 dni roboczych rocznie więcej na utrzymanie niż moduł z testami. Przy stawce 150–250 zł za godzinę to 1200–4000 zł rocznie za oszczędzone wcześniej pół dnia. Więcej o tym, jak utrzymać porządek pracy przy modułach i wtyczkach, piszemy osobno.

Wydajność, bezpieczeństwo i zgodność: RODO, KSeF, OSS

Wydajność modułu psuje się najczęściej w jednym miejscu: w pętli, która odpytuje bazę przy każdym obrocie. Eksport zamówień, który w foreach po 500 rekordach wykonuje 500 osobnych zapytań, robi 501 zapytań zamiast jednego. Naprawa jest zawsze taka sama: pobierz dane jednym zapytaniem z IN() albo JOIN, a obróbkę zrób w PHP. Drugi powód zwolnień to brak cache — jeśli moduł liczy to samo przy każdym wejściu na stronę, wynik trzymaj w cache z kluczem i TTL 300 s, czyszczonym przy zapisie. Trzeci: brak indeksów na kolumnach używanych w WHERE i JOIN. Dodaj je w metodzie install() i sprawdź plan zapytania przez EXPLAIN. Na VPS domyślne memory_limit 128–256 MB i max_execution_time 30 s to twarda granica — generowanie 2000 PDF-ów w jednym żądaniu ją przekroczy, więc rób to partiami po 100 rekordów z crona, z zapisem postępu. Szczegóły techniczne modułów znajdziesz w dokumentacji dla deweloperów PrestaShop.

Bezpieczeństwo: każde dane z $_GET i $_POST przechodzi walidację i rzutowanie, a wyjście jest escapowane (htmlspecialchars, escape w Smarty). Akcje AJAX muszą mieć nonce i sprawdzenie uprawnień — w WordPressie check_ajax_referer i current_user_can, w PrestaShop token i kontrola roli pracownika. Żadnych haseł, tokenów i kluczy API w plikach modułu — trzymaj je w konfiguracji platformy, nigdy w repozytorium. Przeglądaj zależności: biblioteka PDF albo SDK kuriera z 2022 roku to gotowy wektor.

RODO w praktyce: minimalizacja (jeśli eksportujesz zamówienia do CSV, nie pobieraj e-maila, gdy nie jest potrzebny), okres retencji logów modułu — 90 dni to bezpieczny punkt wyjścia, wpis w rejestrze czynności przetwarzania i umowa powierzenia z wykonawcą. KSeF: obowiązek wystawiania faktur w systemie obejmuje coraz więcej firm, a moduł sklepu musi umieć dokument wysłać i odebrać — ustal to na etapie zakresu, nie po wdrożeniu. OSS VAT: przy sprzedaży do krajów UE moduł musi stosować właściwą stawkę i przekazywać dane do rozliczenia. To typowy powód budowy własnego rozwiązania, bo gotowe wtyczki tego nie obsługują.

Utrzymanie po wdrożeniu: SLA, aktualizacje, monitoring

Koszt modułu to nie jednorazowy wydatek, tylko pozycja w budżecie na cały czas życia sklepu. Realna opieka techniczna obejmuje: aktualizacje rdzenia i modułów, kopie zapasowe z testem odtworzenia (raz na kwartał, bo kopia, której nikt nie odtworzył, nie jest kopią), monitoring dostępności co minutę z alertem SMS oraz pomiar czasu odpowiedzi, a także wsparcie w godzinach roboczych — zwykle 8:00–16:00.

SLA zapisz w umowie liczbami. Awaria blokująca sprzedaż — bramka płatności odrzuca transakcje, sklep zwraca błąd 500, nie działa dodawanie do koszyka — to czas reakcji 4 h. Zgłoszenie zwykłe, np. nie generuje się PDF dla jednego typu zamówienia: 1 dzień roboczy. Prace planowane, jak aktualizacja modułu czy zmiana API kuriera, robimy w oknie serwisowym poza szczytem, np. 2:00–5:00, z zapowiedzią 24 h wcześniej.

Koszt utrzymania to zwykle 15–25% wartości wdrożenia rocznie. Moduł za 12 000 zł to 1 800–3 000 zł/rok. Alternatywa to pakiet 5–10 h miesięcznie. Pakiet godzinowy bywa tańszy, gdy moduł jest mały, stabilny i nie dotyka płatności ani magazynu — wystarczą 1–2 h kwartalnie na przegląd i aktualizację. Abonament z SLA ma sens wtedy, gdy moduł obsługuje sprzedaż, stany magazynowe albo KSeF: wtedy płacisz za gotowość, a nie za godziny.

Moduł niestandardowy aktualizujesz razem z aktualizacją platformy, po zmianie API kuriera lub bramki płatności, po zmianie przepisów (KSeF, OSS, stawki VAT) i przed sezonem. Zakres takiej opieki opisaliśmy szerzej w artykule o utrzymaniu i opiece technicznej sklepów w Krasnobrodzie.

Krasnobród i Roztocze: jak pracujemy lokalnie i zdalnie

Krasnobród jest około 30 km od Zamościa, więc spotkanie na miejscu przy briefie i przy odbiorze prac jest w pełni wykonalne — zwykle w jednym dniu. Brief na miejscu skraca ustalenia o tygodnie, bo od razu widzimy katalog, cenniki i to, jak pracownicy obsługują zamówienia. Resztę pracy prowadzimy zdalnie na stagingu: kopia sklepu z wyłączoną indeksacją i zabezpieczeniem hasłem, do której dostajesz link i login. Testujesz na kopii, wdrożenie na produkcję robimy poza godzinami ruchu.

Kontakt wygląda tak: rozmawiasz bezpośrednio z deweloperem, który pisze kod, bez pośredników i handlowców. Kanał ustalamy w umowie — zwykle mail do zgłoszeń i telefon do awarii. Zgłoszenia w jednym miejscu, żeby nie ginęły w wątkach na kilku komunikatorach.

Branże z regionu mają konkretne wymagania, których gotowe moduły nie pokrywają. Obiekty noclegowe i uzdrowiskowe: cennik zależny od sezonu, długości pobytu, liczby osób i dnia tygodnia. Sklepy z produktami regionalnymi: wysyłka, OSS VAT i faktury. Wypożyczalnie sprzętu: kalendarz dostępności, kaucje, opłaty za przetrzymanie. Firmy B2B z Roztocza sprzedające hurtowo: ceny indywidualne per klient, limity kredytowe, wymiana stanów z ERP. Te ostatnie przypadki opisaliśmy w tekście o integracjach z ERP, płatnościami i kurierami w Krasnobrodzie.

Podział ról jest prosty i warto go ustalić przed startem: po Twojej stronie decyzje biznesowe, dane i akceptacja zakresu, po naszej analiza, kod, testy i dokumentacja.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Cel biznesowy zapisany jednym zdaniem — Sprawdź na starcie projektu, czy umiesz powiedzieć, co ten moduł ma poprawić: mniej ręcznej pracy, szybsze zamówienia, wyższy koszyk. Jeśli nie — zakres będzie rósł.
• Lista funkcji i lista wykluczeń — Zweryfikuj przed podpisaniem umowy. Wykluczenia chronią obie strony: „nie obejmuje integracji z Subiektem w tej fazie” to konkret, nie wymówka.
• Wersje PrestaShop / WordPress / PHP ustalone na piśmie — Sprawdź to, zanim dostaniesz wycenę. Moduł pisany pod PHP 7.4 bywa niekompatybilny z PHP 8.2 — a to zmienia zakres i koszt.
• Środowisko staging dostępne przed pierwszym commitem — Zweryfikuj na początku prac, nie na końcu. Jeśli wykonawca nie ma gdzie testować, będzie testował na Twoich klientach.
• Kopia bazy i plików przed każdym wdrożeniem — Sprawdź zapis w umowie lub w mailu. Kopia to warunek odbioru, nie uprzejmość wykonawcy.
• Repozytorium Git i dostęp dla Ciebie — Sprawdź, czy masz konto w repozytorium z prawem odczytu. Bez tego przy zmianie firmy zaczynasz od zera.
• Podział godzin na etapy w ofercie — Zweryfikuj proporcje: analiza 15–25%, kod 40–50%, testy 15–20%, dokumentacja 5–10%. Duże odchylenia warto dopytać.
• Stawka godzinowa i sposób rozliczania dodatków — Ustal przed startem, jak rozliczane są zmiany w zakresie. Czy to nowa wycena, czy godziny z bieżącej stawki — i od jakiej kwoty wymagana jest akceptacja.
• Testy na realnych scenariuszach zamówień — Sprawdź przy odbiorze: zamówienie z paczkomatem, z odbiorem osobistym, z produktem o nietypowej wadze, z kodem rabatowym, z fakturą. Wyniki zapisz.
• Wpływ na czas ładowania po wdrożeniu — Zmierz przed i po na kluczowych stronach. Zmiany w kodzie potrafią pogorszyć Core Web Vitals — punkt odniesienia znajdziesz w dokumentacji web.dev.
• Dokumentacja: hooki, filtry, ustawienia, scenariusze awaryjne — Zweryfikuj przy przekazaniu. Minimum to lista wykorzystywanych hooków i miejsce konfiguracji. Punkt odniesienia dla PrestaShop: dokumentacja deweloperska PrestaShop.
• Plan aktualizacji sklepu lub WordPressa po wdrożeniu — Ustal, kto i kiedy aktualizuje rdzeń oraz jak sprawdzacie, czy moduł działa po aktualizacji. Najlepiej na stagingu, z listą kontrolną.
• Kontakt serwisowy i czas reakcji — Sprawdź zapis w umowie utrzymaniowej: czy zgłoszenie idzie mailem, jaki jest czas reakcji w dni robocze i co jest poza zakresem wsparcia.
• Właściciel kodu i prawa majątkowe — Zweryfikuj przed podpisaniem. Ustal, czy po opłaceniu faktury masz pełne prawa do kodu i możliwość zlecenia jego dalszego rozwoju innemu wykonawcy.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów