Czym są niestandardowe moduły i wtyczki — definicja bez żargonu

Moduł PrestaShop to katalog w /modules/ — na przykład /modules/mojmodul/. W środku musi leżeć plik główny o tej samej nazwie (mojmodul.php) z klasą dziedziczącą po Module, plik config.xml oraz metody install() i uninstall(). Moduł podpina się pod hooki (registerHook('displayOrderConfirmation'), hookActionValidateOrder), a jego ustawienia trafiają do tabeli ps_configuration i pokazują się w back office przez getContent() oraz HelperForm.

Wtyczka WordPress to katalog w /wp-content/plugins/moja-wtyczka/ z plikiem, który ma nagłówek Plugin Name. Logikę podpinasz przez add_action() i add_filter(), a czynności przy włączaniu i wyłączaniu przez register_activation_hook() i register_deactivation_hook(). WooCommerce dokłada własne punkty zaczepienia, np. woocommerce_checkout_create_order albo woocommerce_cart_calculate_fees. Całość to standard opisany w [dokumentacji dla deweloperów PrestaShop](https://devdocs.prestashop-project.org/).

Różnica między modułem a kodem doklejonym do szablonu jest praktyczna, nie estetyczna. Jeśli walidację NIP wpiszesz w functions.php motywu, pierwsza aktualizacja motywu ją usunie, a zmiana motywu zabierze ją na zawsze. Kod w module lub wtyczce leży osobno, wyłączasz go jednym kliknięciem i przenosisz na inną instalację bez kopiowania fragmentów z szablonu.

Osobny temat to override. W PrestaShop moduł może nadpisać plik core, wrzucając własną wersję do /override/classes/ albo /override/controllers/front/. Brzmi wygodnie, ale przy aktualizacji PrestaShop nadpisane pliki nie idą za zmianami w core — działają na starej logice, a po większym skoku wersji potrafią przestać działać. Sięgaj po override tylko wtedy, gdy nie istnieje hook, i zapisz to w dokumentacji projektu. Jak ułożyć całą tę organizację — od właściciela plików po sposób wdrażania — opisujemy w materiale o [organizacji niestandardowych modułów i wtyczek](https://dropdigital.pl/niestandardowe-moduly-i-wtyczki-zamosc-organizacja).

Kiedy gotowa wtyczka przestaje wystarczać — 7 sygnałów

Zanim zamówisz kod, sprawdź, czy problemu nie rozwiąże konfiguracja albo wtyczka premium. Poniżej siedem sygnałów, które realnie przemawiają za własnym rozwiązaniem.

• Proces obsługi zamówienia nie mieści się w standardzie. Przykład: zamówienia B2B mają czekać na akceptację handlowca przed przekazaniem do magazynu, a WooCommerce domyślnie od razu ustawia status „w realizacji”.
• Integracja z wewnętrznym ERP lub systemem magazynowym. Gotowe wtyczki łączą się z popularnymi SaaS, a nie z systemem, który w firmie działa od ośmiu lat.
• Nietypowa logika cenowa lub rabatowa B2B. Rabat zależny jednocześnie od grupy klienta, progu ilościowego, historii zamówień i kontraktu — tego nie ustawisz w panelu.
• Dane wymagane przez prawo lub księgowość. Numeracja dokumentów zgodna z systemem księgowym, dodatkowe pola na fakturze, eksport pod konkretny format.
• Wydajność: trzy, cztery wtyczki robią to samo. Każda dokłada zapytania do bazy i skrypty na froncie — strona się dławi, a Ty płacisz za trzy licencje.
• Koszt subskrypcji rośnie z czasem. Licencja roczna po odnowieniu bywa droższa, a warunki zmieniają się bez Twojego udziału.
• Brak dostępu do kodu przy awarii. Jeśli wtyczka jest zakodowana (ionCube, zamknięte API), nie naprawisz błędu sam — czekasz na wsparcie, a sklep stoi.

Próg opłacalności policz na kartce. Jeśli płacisz 1500 zł rocznie za trzy licencje, po trzech latach to 4500 zł i nadal nic nie jest Twoje. Własny moduł kupujesz raz.

Kontrprzykład, żeby nie sprzedawać usługi na siłę: standardowy koszyk, zwykła bramka płatnicza (Przelewy24, PayU, Stripe mają oficjalne integracje) i newsletter to miejsca, w których własny kod to strata pieniędzy. Konfiguracja w zupełności wystarcza.

Ile to realnie kosztuje — widełki, godziny, przykłady

Nie ma cennika z sufitu. Jest zakres prac i godziny. Poniżej typowy podział dla jednego niestandardowego modułu lub wtyczki.

Ile to realnie kosztuje — widełki, godziny, przykłady (ciąg dalszy)

Trzy scenariusze z życia. Prosty: walidacja NIP i REGON przy zamówieniu B2B, z blokadą złego numeru i komunikatem w koszyku — 20-35 h. Średni: integracja z kurierem albo nietypowa wysyłka paletowa z liczeniem stref i gabarytów — 40-80 h. Duży: integracja z ERP lub systemem księgowym, synchronizacja stanów i statusów w dwie strony — 80-180 h.

Rozstrzał 16-60 h w implementacji to nie niechlujstwo wyceny. To różnica między modułem czytającym jedno pole a modułem, który synchronizuje stany magazynowe i obsługuje konflikty, gdy ktoś kupi ostatnią sztukę w sklepie i w BOK-u w tej samej minucie.

Koszt integracji z ERP zależy głównie od jednej rzeczy: czy dostawca udostępnia API (REST, SOAP, webhooki), czy trzeba pracować na plikach wymiany (CSV, XML na FTP). W drugim przypadku dochodzi cykl importu, obsługa błędów, kolejkowanie, cron i uzgadnianie rozjazdów — wycena rośnie nawet dwukrotnie, mimo że sam „kod” wygląda podobnie.

Kwotę liczysz sam: godziny × stawka z umowy. Pamiętaj, że cena kodu to nie całość. Dochodzi utrzymanie: po każdej aktualizacji PrestaShop, WooCommerce, PHP albo motywu trzeba sprawdzić, czy moduł nadal działa. Realnie 2-6 h rocznie, a przy mocno powiązanych integracjach więcej — opisujemy to w materiale o [utrzymaniu i opiece technicznej sklepów](https://dropdigital.pl/utrzymanie-i-opieka-techniczna-sklepow-szczebrzeszyn).

Jak wygląda proces od briefu do wdrożenia — krok po kroku

Wdrożenie niestandardowego modułu da się rozłożyć na osiem etapów. Każdy kończy się dokumentem albo decyzją do podpisu, a nie kolejnym „spotkaniem statusowym”.

1–3. Rozmowa, spisanie procesu, brief i wycena. Pierwsze spotkanie trwa 60–90 minut i kończy się opisem procesu w 10–20 zdaniach oraz listą wyjątków. Brief musi zawierać: proces opisany zdaniami, 2–3 przykłady prawdziwych danych (konkretne zamówienie, konkretny produkt) oraz zachowanie systemu w sytuacjach brzegowych — produkt bez stanu, klient chce fakturę na inne dane niż w zamówieniu, kod rabatowy wygasł, zwrot częściowy. Wycena powstaje w godzinach: na przykład 40 h implementacji, 8 h testów, 4 h dokumentacji. Jeśli zakres się zmieni, zmienia się liczba godzin, a nie stawka.

4–6. Staging, implementacja, testy scenariuszowe. Staging to kopia plików i bazy na tej samej wersji PHP oraz tej samej wersji PrestaShop albo WordPressa/WooCommerce co produkcja. Testy robi się na prawdziwych danych: 30–50 zamówień z ostatniego miesiąca plus scenariusze wyjątków z briefu. Gdy sklep generuje sprzedaż, testowanie na produkcji oznacza, że każdy błąd kosztuje realne zamówienia i maile od klientów.

7–8. Wdrożenie i przekazanie. Publikacja poza godzinami szczytu — najczęściej 6:00–8:00 albo po 22:00 — po kopii zapasowej plików i bazy oraz z gotowym planem wycofania. Na koniec dokumentacja: instrukcja dla osoby obsługującej zamówienia, opis techniczny i szkolenie 1–2 h. To moment, w którym przechodzisz do utrzymania i opieki technicznej sklepu — bez tego etapu za rok nikt nie będzie wiedział, dlaczego moduł działa tak, a nie inaczej.

Realny czas: od 2 tygodni (jeden moduł, jedna integracja, brak zmian w wyglądzie) do 8 tygodni i więcej (integracja z ERP, płatnościami i magazynem, wielosklepowość, migracja danych).

PrestaShop czy WooCommerce — co zmienia się przy pisaniu modułu

Technologia zmienia nie tylko kod, ale i ryzyko, które potem utrzymujesz. PrestaShop i WooCommerce mają inne sposoby rozszerzania systemu i inne miejsca, w których moduł potrafi narobić szkód.

PrestaShop. Moduł to katalog /modules/nazwa/ z plikiem nazwa.php, w którym klasa dziedziczy po Module. W install() rejestrujesz hooki, tworzysz tabele i dodajesz zakładkę w back office (klasa Tab), a konfigurację wystawiasz przez getContent() z HelperForm albo HelperOptions. Sensowna implementacja pracuje na hookach (hookDisplayHeader, hookActionOrderStatusPostUpdate, hookDisplayAdminOrder). Jeśli moduł wchodzi w pliki główne, robi to przez katalog /override/ — a wtedy każda aktualizacja PrestaShop wymaga sprawdzenia, czy override nadal pasuje. Przy wielosklepowości pamiętaj o Configuration::get() z id_shop_group i id_shop, inaczej jedno ustawienie rozleje się na wszystkie sklepy. Wersje PHP wspierane przez daną gałąź PrestaShop sprawdzasz w dokumentacji deweloperskiej PrestaShop — nie zgaduj i nie zakładaj, że „na pewno zadziała”.

WooCommerce. Wtyczka to plugin WordPress: nagłówek w pliku głównym, własne typy treści, REST API przez register_rest_route(). Zadania czasochłonne (synchronizacja stanów, wystawianie faktur, pobieranie danych z API kuriera) powinny iść przez kolejkę — w WooCommerce służy do tego Action Scheduler. Największe ryzyko to konflikty: dwie wtyczki podpinające się pod ten sam hook potrafią wzajemnie nadpisywać dane zamówienia.

Cache i wydajność. Moduł odpytujący zewnętrzne API przy każdej odsłonie strony to najczęstsza przyczyna skoku czasu ładowania. Progi Core Web Vitals to 2,5 s dla LCP, 200 ms dla INP i 0,1 dla CLS — samo jedno żądanie do API potrafi wyczerpać ten budżet. Dane z API buforuje się (transient albo Configuration, cache na 5–15 minut) lub przetwarza zadaniowo w tle.

Skala też ma znaczenie: sklep z 300 produktami i jedną integracją a sklep z 30 000 SKU, kilkoma magazynami i pięcioma integracjami to dwa różne projekty. Przy tym drugim cache i kolejki to osobny etap prac, a nie dodatek na końcu.

Pułapki, na które trafia się przy zamawianiu modułu — i jak je wykryć

Nie chodzi o to, żeby wykonawca był idealny. Chodzi o to, żebyś przed podpisem umowy wiedział, co dokładnie kupujesz i co zostaje u Ciebie po zakończeniu projektu.

• Moduł nadpisuje pliki główne (override). W PrestaShop modyfikacje core lądują w /override/classes i /override/controllers. Zapytaj wprost o listę plików głównych modyfikowanych przez moduł. Dobra odpowiedź: „zero override” albo krótka, uzasadniona lista.
• Brak kodu i dostępu — moduł zaszyfrowany (ionCube, encoded). Jeśli nie masz kodu, nie kupiłeś modułu, tylko wynająłeś go na czas nieokreślony. Żądaj w umowie przekazania pełnego kodu w repozytorium, do którego masz dostęp.
• Brak dokumentacji. Poproś o przykładową dokumentację z poprzedniego projektu: 2–3 strony z opisem hooków, tabel w bazie i ustawień. Jeśli wykonawca nie ma czego pokazać, nie przygotuje jej też dla Ciebie.
• Brak testów scenariuszowych. Zapytaj, na jakim środowisku i na jakich danych będą sprawdzane wyjątki: brak stanu, faktura na inne dane, wygasły rabat. Odpowiedź „przetestujemy na produkcji” oznacza, że za testy płacisz swoimi klientami.
• Brak planu aktualizacji. Zapytaj, co się dzieje, gdy po aktualizacji PrestaShop albo WooCommerce moduł przestanie działać i kto za to płaci. Dobra odpowiedź to zapis w umowie: gwarancja na przykład 3–6 miesięcy i stawka za dostosowanie poza nią.
• Prace bezpośrednio na produkcji bez wersjonowania. Poproś o dostęp do repozytorium Git i zapytaj o częstotliwość commitów. Praca przez FTP, bez historii zmian, oznacza brak możliwości cofnięcia wdrożenia.
• Wycena z sufitu, bez rozbicia na godziny. Pytaj o stawkę godzinową, budżet godzinowy i procedurę przy zmianie zakresu. Kwota 12 000 zł bez rozbicia na godziny nie mówi nic o tym, ile zapłacisz, gdy w trakcie okaże się, że trzeba dodać drugą integrację.

Zanim podpiszesz, ustal też właściciela plików: kto trzyma repozytorium, kto ma dostęp do serwera i co się dzieje, gdy współpraca się kończy. Kolejność tych ustaleń — od briefu po przekazanie — opisaliśmy w artykule Niestandardowe moduły i wtyczki Zamość: jak to zorganizować.

Utrzymanie modułu po wdrożeniu — aktualizacje, kompatybilność i jasne SLA

Wdrożenie modułu to nie koniec projektu, a początek jego utrzymania. W praktyce rozsądny budżet na opiekę nad jednym niestandardowym modułem to 15–25% wartości wdrożenia rocznie. Jeśli wykonawca twierdzi, że moduł nie wymaga żadnej opieki, najczęściej oznacza to, że nikt tej pracy nie wycenił — a nie że nie istnieje.

Co konkretnie wchodzi w utrzymanie:

• Testy po aktualizacji PrestaShop (np. 8.1 → 8.2), WooCommerce lub WordPressa: przejście ścieżki zamówienia, płatności, wysyłki maili, faktury, statusów.
• Testy po zmianie wersji PHP na serwerze — u większości hostingów dzieje się to automatycznie i bez pytania.
• Poprawki błędów zgłoszonych po wdrożeniu, w ramach gwarancji lub opieki.
• Drobne zmiany — np. dodatkowe pole w formularzu, zmiana progu darmowej dostawy, nowy status zamówienia.
• Monitorowanie logów — var/logs w PrestaShop, wp-content/debug.log w WordPressie, log błędów PHP na serwerze.
• Kopie zapasowe plików i bazy przed każdą aktualizacją, z możliwością odtworzenia.

Kwestia PHP jest krytyczna, bo każda nowa gałąź wycofuje stare funkcje i zachowania. Kod pisany pod PHP 7.4 potrafi przestać działać na 8.1 i 8.2 — nie dlatego, że był zły, ale dlatego, że nikt go nie utrzymywał. Dlatego warto pilnować zgodności z aktualnym wsparciem, o którym pisze dokumentacja dla deweloperów PrestaShop.

SLA nie musi być rozbudowane, ale musi być zapisane. Największy błąd to obiecanie „szybkiej reakcji” bez liczb.

Szczebrzeszyn i okolice — jak wygląda współpraca z deweloperem

W praktyce 90% pracy nad modułem nie wymaga obecności na miejscu. Potrzebny jest dostęp do panelu administracyjnego, do repozytorium kodu i do kopii bazy na środowisku testowym. To wystarcza, żeby napisać moduł, wdrożyć go i utrzymywać. Wizyta na miejscu ma sens w trzech sytuacjach:

• Analiza procesu zamówień — gdy trzeba przejść krok po kroku przez to, co faktycznie robi handlowiec i magazynier, a nie przez to, co wynika z opisu w mailu.
• Wdrożenie u firmy z własnym magazynem — integracja ze skanerem kodów, drukarką etykiet czy wewnętrznym systemem magazynowym wymaga testu na prawdziwym sprzęcie, nie na makiecie.
• Szkolenie zespołu — 2–3 godziny na miejscu plus nagranie i krótka notatka potrafią zastąpić kilkanaście maili z pytaniami „jak to kliknąć”.

Drugi aspekt to godziny pracy. Zgłoszenie awarii o 9:00 rano powinno trafić do kogoś, kto w tym momencie pracuje, a nie do zespołu, który obudzi się o 15:00 naszego czasu. Dlatego przy wyborze wykonawcy warto ustalić wprost: w jakich godzinach odbierane są zgłoszenia, w jakim języku i czy osoba odbierająca telefon rozumie kontekst sklepu, czy tylko przekazuje zgłoszenie dalej.

Lokalny kontekst ma jeszcze jedną warstwę praktyczną: firmom z Lubelszczyzny i wschodniej Polski najbliższym większym centrum technicznym jest zwykle Zamość. To ma znaczenie głównie przy wdrożeniach wymagających obecności — a zasady organizacji takiego projektu opisaliśmy przy okazji tematu niestandardowych modułów i wtyczek dla Zamościa.

Nie chodzi więc o to, żeby deweloper był z tej samej ulicy. Chodzi o to, żeby był osiągalny wtedy, gdy sklep nie sprzedaje.

Lista kontrolna sebelum zamawiasz moduł lub wtyczkę

Ta lista ma jedną funkcję: wrócić do niej przed rozmową z wykonawcą, a nie po podpisaniu umowy. Sprawdź trzy obszary.

1. Pytania do wykonawcy. Kto jest autorem kodu i czy przenosi prawa majątkowe? Gdzie fizycznie leży kod — w repozytorium Git u Ciebie, u wykonawcy czy na serwerze produkcyjnym (to najgorszy wariant)? Czy jest dokumentacja: opis konfiguracji, lista hooków, wymagane wersje PHP i PrestaShop/WooCommerce? Co się dzieje po zakończeniu współpracy — dostajesz pełne repo z historią commitów czy tylko archiwum ZIP?

2. Zakres w umowie. Etapy z terminami, liczba godzin z rozbiciem na analizę, kod i testy, wyraźna lista tego, co jest poza zakresem (np. integracja z kolejnym API, migracja danych, poprawki po stronie szablonu). Warunki odbioru: kto testuje i na jakim środowisku. Warunki utrzymania: czy wdrożenie obejmuje jakiś okres gwarancji i co dokładnie on pokrywa.

3. Elementy techniczne przed wdrożeniem. Środowisko staging z kopią danych produkcyjnych. Kopia zapasowa plików i bazy wykonana bezpośrednio przed wgraniem. Plan wycofania (rollback): wiesz, który plik podmienić, żeby wrócić do poprzedniej wersji. Wpływ na czas ładowania — sprawdzony na realnym ruchu, nie na pustym sklepie; wskaźniki opisuje dokumentacja web.dev.

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

Lista kontrolna do odklikania

• Repozytorium kodu — Sprawdź, czy kod leży w Git i czy dostęp ma Twoja firma, a nie wyłącznie wykonawca.
• Konwencja nazewnictwa — Nazwa katalogu modułu lub wtyczki: małe litery, bez spacji i polskich znaków, z czytelnym prefiksem. Ustal to przed pierwszym commitem.
• Środowisko staging — Ta sama wersja PHP, MySQL i PrestaShop/WooCommerce co produkcja. Zweryfikuj przed pierwszym testem, nie po.
• Kopia zapasowa przed wdrożeniem — Pliki i baza. Sprawdź, czy kopię da się realnie odtworzyć — raz na jakiś czas zrób test odtworzenia.
• Okno wdrożeniowe — Wdrożenie na produkcję poza szczytem sprzedaży, z konkretną godziną i osobą odpowiedzialną za rollback.
• Testy scenariuszowe — Na prawdziwych danych: zamówienie B2B, zamówienie bez stanu, kod rabatowy po terminie. Sprawdź wszystkie wyjątki z briefu.
• Lista hooków i zdarzeń — Zapisz, na których hookach opiera się kod. Ułatwia to diagnozę po aktualizacji i przy zmianie wykonawcy.
• Zależności zewnętrzne — API kuriera, ERP, bramka płatnicza — zapisz limity zapytań i sposób autoryzacji. To najczęstsze źródło awarii w godzinach szczytu.
• Procedura rollback — Ustal, jak w 15 minut wrócić do poprzedniej wersji. Brak takiej procedury to najdroższy element wdrożenia.
• Monitorowanie błędów — Logi PHP i alerty o błędach krytycznych. Bez tego pierwszym monitoringiem jest telefon od klienta.
• Cykl aktualizacji — Zapisz w kalendarzu, kto i kiedy sprawdza zgodność modułu z nowymi wersjami PHP, PrestaShop i WooCommerce.
• Dane osobowe — Sprawdź, jakie dane moduł zapisuje i gdzie. Jeśli trafiają do zewnętrznego systemu, opisz to w dokumentacji i w rejestrze czynności.
• Dokumentacja i szkolenie — README z opisem konfiguracji oraz krótkie przekazanie wiedzy osobie, która będzie moduł obsługiwać na co dzień.

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