Czym są niestandardowe moduły i wtyczki i kiedy naprawdę ich potrzebujesz

Moduł w PrestaShop to katalog plików PHP w /modules/, który rejestruje się w sklepie i rozszerza jego działanie przez hooki, bez ingerencji w pliki rdzenia. Wtyczka w WordPress/WooCommerce to katalog w /wp-content/plugins/ z nagłówkiem opisującym wtyczkę w pliku głównym — WordPress sam ją wykrywa, uruchamia i pokazuje na liście wtyczek.

Trzy sygnały, że gotowa wtyczka tego nie pokryje:

• Proces zamówienia odbiega od standardu. Wycena zależy jednocześnie od wagi, strefy dostawy i terminu, albo klient B2B zamawia według własnego cennika przypisanego do grupy klientów i płaci na 30 dni.
• Dane muszą trafić do systemu, dla którego nie ma gotowego łącznika. Własny ERP, hurtownia z API zwracającym nietypowy format, program księgowy, który oczekuje eksportu po zamknięciu dnia.
• Gotowa wtyczka pokrywa około 80% potrzeb. Pozostałe 20% to logika właściwa tylko twojej firmie — i próba doklejenia jej „obok” wtyczki kończy się dwoma źródłami prawdy o zamówieniu.

Rozgraniczenie jest kluczowe: konfiguracja istniejącej wtyczki to ustawienia, reguły, szablony i uprawnienia — nie powstaje nowy kod, nie ma czego utrzymywać. Moduł niestandardowy to kod, który zostaje w repozytorium, ma dokumentację, wymaga testów po każdej aktualizacji PHP i PrestaShop oraz przeglądu przy zmianie motywu. Jeśli wykonawca proponuje ci „moduł niestandardowy”, a w środku są wyłącznie zmiany w panelu, to nie ta kategoria i nie powinieneś za to płacić jak za rozwój.

Prowadzimy takie wdrożenia dla firm z Józefowa i okolic — Krasnobrodu, Zwierzyńca, Szczebrzeszyna, Zamościa. Zanim zamówisz kod, zadaj jedno pytanie: czy ten problem da się rozwiązać ustawieniem? Jeśli tak, zacznij od tego. Jeśli nie, zaplanuj też, kto przejmie po module utrzymanie i opiekę techniczną sklepu w Józefowie po zakończeniu prac. Terminologia i struktura modułów są opisane w dokumentacji dla deweloperów PrestaShop — warto zajrzeć choćby po to, żeby rozumieć, o czym mówi wykonawca.

Gotowa wtyczka czy własny moduł: porównanie kosztów i ryzyk

Porównanie robi się źle, gdy patrzy się tylko na pierwszy rok. Policz trzy lata i dołóż koszt pracy przy podnoszeniu wersji PHP — tam gotowe wtyczki potrafią zaskoczyć.

Typowa wtyczka premium do WooCommerce to wydatek rzędu 200–800 zł za rok, zależnie od zakresu i tego, czy licencja jest rozliczana w USD (dochodzi ryzyko kursowe i VAT). Przy dwóch–trzech integracjach działających równocześnie — płatności ratalne, wysyłka kurierska, faktury — schodzi się na 600–2400 zł rocznie, czyli 1800–7200 zł w trzy lata. Część wtyczek przeszła na czysty abonament: brak opłaty nie blokuje działającej strony, ale odcina aktualizacje, a to oznacza brak poprawek bezpieczeństwa.

Drugie ryzyko: autor porzuca wtyczkę. Sygnały są widoczne w nagłówku pliku — pole „WC tested up to” zatrzymane na starej wersji, brak deklaracji zgodności z HPOS (High-Performance Order Storage), ostatnia aktualizacja sprzed dwóch lat. Efekt przy PHP 8.3: ostrzeżenia w logach, konflikty z nowszym WooCommerce, czasem luka bezpieczeństwa łatana ręcznie na produkcji.

Praktyczne kryterium decyzyjne: skonfiguruj wtyczkę uczciwie i policz, ile logiki zostaje poza nią — własne przeliczenia, reguły rabatowe, mapowanie pól w integracji. Jeśli to około 20% i rośnie przy każdym nowym wymaganiu, własny kod jest tańszy w trzyletnim horyzoncie niż kolejne doklejki w pliku functions.php motywu, których nikt później nie rozczyta. Czytelnikom pracującym na WordPressie polecam też materiał o tym, jak świadomie rozszerzać stronę bez rozsypywania jej przy aktualizacji: niestandardowe bloki responsywne w Elementorze — przewodnik.

Jak zbudowany jest moduł PrestaShop i wtyczka WooCommerce

Moduł PrestaShop ma powtarzalną strukturę. Plik główny /modules/mojmodul/mojmodul.php zawiera klasę dziedziczącą po Module z metodami install(), uninstall(), getContent() i metodami hooków. Obok leżą: /controllers/front/ i /controllers/admin/ (własne endpointy i ekrany w panelu), /views/templates/front/, /views/templates/hook/, /views/templates/admin/, /views/css/, /views/js/, /upgrade/ ze skryptami SQL migracji oraz /config/ z plikiem config.xml. Jeśli po wdrożeniu nie ma katalogu /upgrade/, to znaczy, że przy kolejnej zmianie bazy ktoś będzie klikał ręcznie w phpMyAdmin.

Hooki, które najczęściej wchodzą w grę przy koszyku i zamówieniu: displayShoppingCart i displayShoppingCartFooter (dodatkowe pola i komunikaty w koszyku), actionCartSave (przeliczenie zawartości), actionValidateOrder (modyfikacja danych zamówienia przed zapisem), actionOrderStatusPostUpdate, displayOrderConfirmation, paymentOptions i displayAdminOrder. Opis wszystkich hooków znajdziesz w dokumentacji deweloperskiej PrestaShop.

Wtyczka WooCommerce ma plik główny z nagłówkiem (Plugin Name, Version, Requires PHP, WC requires at least, WC tested up to, Text Domain) — te pola to nie ozdoba, bo po nich poznasz, czy wtyczka jest utrzymywana. Dalej działają add_action() i add_filter(); przy filtrach podawaj priorytet, inaczej kolejność wykonania zależy od przypadku. Szablony nadpisujesz w motywie w katalogu woocommerce/, a zgodność z HPOS deklarujesz przez FeaturesUtil::declare_compatibility(). Szczegóły są w dokumentacji WooCommerce.

W obu systemach composer.json i autoloader PSR-4 to różnica między kodem, który da się rozwijać, a zbiorem require sprzed lat. Nadpisywanie plików core — edycja klas w /classes/, kopiowanie szablonów wtyczki do motywu — to dług techniczny, którego unikamy: pierwsza aktualizacja kasuje zmiany, a nikt nie pamięta, co tam było.

Proces wdrożenia krok po kroku: od briefu do produkcji

Każdy projekt prowadzimy w czterech etapach. Każdy etap kończy się konkretnym plikiem albo dostępem, a nie ustnym „zrobione”.

Etap 1: analiza procesu i spisanie przypadków brzegowych. Zanim powstanie pierwsza linijka kodu, opisujemy proces: kto klika co, w jakiej kolejności i co się dzieje przy anulowaniu zamówienia, zwrocie, płatności za pobraniem oraz zamówieniu rozbitym na dwie paczki. Efekt to dokument na 2–5 stron z listą przypadków brzegowych — zwykle 10–15 pozycji. Bez tego etapu każdy nietypowy scenariusz staje się osobnym, dodatkowo płatnym zleceniem w trakcie prac.

Etap 2: prototyp na środowisku stagingu. Pracujemy na kopii sklepu, np. na subdomenie staging.twojsklep.pl, z kopią bazy i plików, wyłączoną wysyłką maili do klientów i wyłączonymi płatnościami. Zero pracy bezpośrednio na produkcji. Na tym etapie moduł ma już działającą strukturę (katalog /modules/ w PrestaShop, /wp-content/plugins/ w WooCommerce) i pierwszy przepływ danych.

Etap 3: kod, testy, code review. Praca w repozytorium Git, osobne gałęzie, każda zmiana przechodzi przez pull request i przegląd drugiej osoby. Testy obejmują co najmniej: poprawne dane, brak odpowiedzi API, błędny format odpowiedzi i przekroczenie limitu czasu. Strukturę modułu opisuje dokumentacja dla deweloperów PrestaShop — warto ją przejrzeć przed rozmową z wykonawcą.

Etap 4: wdrożenie z możliwością wycofania zmian. Kopia plików i bazy przed startem, wdrożenie w oknie poza godzinami szczytu (np. 6:00–8:00), tag wersji w repozytorium. Jeśli w ciągu 48 godzin monitoringu pojawi się błąd, wracamy do kopii jednym poleceniem, a nie „łatamy na żywo”.

Co dostajesz po każdym etapie: dokumentację powdrożeniową (co robi moduł, jakie ma ustawienia, co zrobić przy błędzie), repozytorium z historią zmian oraz dostępy do stagingu, panelu i repozytorium zapisane na Twoje konto firmowe, nie na prywatne konto wykonawcy.

Ile to kosztuje: widełki wyceny według liczby godzin

Najczęstsze pytanie brzmi: ile to będzie kosztować. Uczciwa odpowiedź to liczba godzin pomnożona przez stawkę, a nie ryczałt wzięty z sufitu. Wycenę rozbijamy na pięć pozycji:

• analiza i spisanie przypadków brzegowych — 8–16 h,
• kod — 40–120 h (zależnie od liczby integracji),
• testy, w tym testy błędnych odpowiedzi API — 10–20 h,
• wdrożenie i konfiguracja na produkcji — 4–8 h,
• dokumentacja i przekazanie projektu — 4–8 h.

Dla porównania: prosty moduł integracyjny (np. dodatkowe pole w zamówieniu plus eksport CSV do programu księgowego) to zwykle 30–60 h. Moduł z logiką biznesową — rabaty zależne od kategorii i historii zakupów, własny algorytm kosztu wysyłki, łącznik z ERP — startuje od 120 h i potrafi dojść do 250–300 h.

Skąd ten rozrzut? Z liczby wyjątków. Pierwsza wersja funkcji to często 40% pracy, reszta to obsługa sytuacji, których nikt nie przewidział na starcie. Dlatego do wyceny doliczamy bufor ryzyka 15–20% i mówimy o tym otwarcie, zamiast chować go w stawce.

Ryczałt bez analizy jest ryzykowny dla obu stron. Wykonawca zabezpiecza się z góry, czyli zawyża, a klient nie wie, za co płaci. Jeśli po miesiącu okaże się, że potrzebny jest jeszcze eksport faktur do ERP, przy ryczałcie zaczyna się spór o zakres. Przy rozliczeniu godzinowym po prostu dopisuje się kolejne 12 godzin do aneksu i temat jest zamknięty.

Projekt dzielimy na etapy, gdy budżet jest ograniczony, proces nie jest do końca opisany albo integrujemy się z API, do którego nie ma pełnej dokumentacji. Po każdym etapie klient decyduje, czy idziemy dalej — budżet nie jest zamrożony, a zakres można zmienić. Podobne podejście opisaliśmy w tekście o organizacji pracy przy modułach i wtyczkach w Krasnobrodzie.

Integracje z ERP, płatnościami i kurierami jako typowy scenariusz modułu

Większość zamawianych modułów to łączniki: kurier, płatności, ERP albo program księgowy. Typowy scenariusz wygląda tak.

Etykiety i numery przesyłek. W panelu zamówienia pojawia się przycisk „Nadaj przesyłkę”. Moduł wysyła dane odbiorcy i wymiary paczki do API kuriera, odbiera etykietę w PDF albo ZPL (ZPL idzie od razu na drukarkę termiczną) i zapisuje numer przesyłki w zamówieniu. Ten numer trafia do maila do klienta automatycznie, bez ręcznego kopiowania. Pułapka: literówka w kodzie pocztowym wraca jako błąd walidacji, więc moduł musi pokazać komunikat przy konkretnym polu, a nie ogólne „błąd integracji”.

Synchronizacja z ERP. Kierunek przepływu jest kluczowy: produkty, stany magazynowe i ceny płyną z ERP do sklepu, bo ERP jest źródłem prawdy. Zamówienia, płatności i dane klientów płyną ze sklepu do ERP. Faktury wystawione w ERP wracają do sklepu jako plik do pobrania w panelu klienta. Odwrócenie tego kierunku, czyli ręczne poprawianie stanów w sklepie, kończy się rozjazdem magazynu w ciągu kilku tygodni.

Błędy API u kuriera. API padają, to normalne. Dlatego każde żądanie trafia do kolejki w bazie, a zadanie cron próbuje je wysłać co 5 minut. Trzy nieudane próby z rosnącym odstępem (1, 5, 15 minut), a potem zgłoszenie w panelu z logiem odpowiedzi i mailem do administratora. Bez kolejki jeden timeout oznacza etykietę, która nigdy nie powstanie, i paczkę, o której nikt nie pamięta.

Własny łącznik czy płatna wtyczka? Gotowa wtyczka wygrywa przy standardowym procesie i dokumentacja WooCommerce zwykle wystarcza, żeby ją wdrożyć. Przegrywa, gdy masz nietypowe mapowanie metod wysyłki, wysyłkę wielopaczkową, pobranie albo kilka magazynów — wtedy walczysz z ustawieniami, których nie da się nadpisać, i dokupujesz kolejne rozszerzenia.

Szerszy kontekst organizacji projektu, krok po kroku, znajdziesz w materiale o tym, jak zorganizować pracę przy modułach i wtyczkach w Zamościu.

Utrzymanie modułu po wdrożeniu: aktualizacje, kompatybilność, bezpieczeństwo

Wdrożenie modułu to moment, w którym zaczyna się jego najtrudniejszy okres. Moduł napisany pod PHP 8.1 potrafi wywalić sklep po przejściu na 8.2 — najczęściej przez dynamiczne właściwości i funkcje usunięte w PHP 8. Klient dowiaduje się o tym przy pierwszym zamówieniu, nie przy wdrożeniu.

Aktualizacja PHP i rdzenia (PrestaShop 1.7 → 8.x, WordPress + WooCommerce) powinna mieć procedurę, nie być improwizacją:

• Rejestr wersji. W dokumentacji modułu zapisz, na czym był testowany: PHP, PrestaShop lub WooCommerce, WordPress, MySQL/MariaDB. Bez tego każda kolejna aktualizacja to zgadywanka.
• Staging 1:1. Ta sama wersja PHP i te same rozszerzenia (mysqli, intl, mbstring, curl, gd). Aktualizujesz najpierw tam, dopiero potem na produkcji.
• Retest po aktualizacji rdzenia. Osobny punkt SLA z terminem, np. 3 dni robocze od wydania poprawki bezpieczeństwa. Test całej ścieżki: koszyk, płatność, mail potwierdzający, panel admina — nie tylko samo otwieranie strony.
• Monitoring. Log błędów PHP z alertem na fatal error, monitoring dostępności co 1–5 minut, przegląd logów modułu. Awaria ma być widoczna u Ciebie wcześniej niż u klienta.
• Kopie. Snapshot przed każdą zmianą, retencja minimum 30 dni.

Bezpieczeństwo to druga strona medalu. Jeśli moduł ma własny endpoint, musi walidować wejście, używać tokenów CSRF i nie logować danych osobowych. Tryb developerski (_PS_MODE_DEV_, WP_DEBUG) na produkcji — nigdy.

Zakres takiej opieki, to co wchodzi w pakiet, a co jest płatne dodatkowo, opisaliśmy na stronie utrzymania i opieki technicznej sklepów Józefów. Warto też wiedzieć, o co pytać wykonawcę — dokumentacja dla deweloperów PrestaShop opisuje standard hooków i override.

Pułapki przy zamawianiu niestandardowych modułów i jak je wykryć

Większość problemów nie wynika z tego, że kod jest zły, ale z tego, że nikt nie zabezpieczył się na przyszłość. Poniżej sygnały, które widać w pierwszych pięciu minutach rozmowy z wykonawcą.

Pytania, które zadaj w jednej wiadomości i oceń odpowiedź, a nie gadkę:

• Podaj link do repozytorium i pokaż README z instrukcją instalacji. Brak repo oznacza, że kod istnieje tylko na komputerze wykonawcy — przy zmianie firmy zaczynasz od zera.
• Czy modyfikujesz pliki rdzenia? Jeśli tak, które? W PrestaShop pliki core nadpisze aktualizacja; poprawna droga to hooki i override. W WooCommerce edycja plików wtyczki zniknie po jej aktualizacji.
• Jak wdrażasz zmiany — repozytorium i staging czy FTP na produkcję?
• Ile godzin przewidujesz na analizę i czy jest wyceniona osobno?
• Co się stanie z modułem, gdy zaktualizujemy PrestaShop do 8.1 albo WordPressa do kolejnej wersji?

Rzetelny wykonawca odpowie konkretami w ciągu jednego dnia. Odpowiedź typu „to zależy, sprawdzimy przy testach” bez żadnych szczegółów oznacza, że analizy nie było.

Ostatnia pułapka to cena. Oferta 400 zł za „prosty moduł” prawie zawsze pomija etap analizy. Pierwsza zmiana wymagań po trzech miesiącach — dodatkowe pole w formularzu, inny sposób liczenia dostawy — kosztuje wtedy więcej niż różnica między tanią i rzetelną wyceną. Tania wersja nie jest tańsza, jest tylko krócej widoczna w budżecie.

Praca z deweloperem w Józefowie i okolicach: na co zwrócić uwagę

Praca z pośrednikiem a bezpośrednio z deweloperem różni się trzema rzeczami: ceną, szybkością decyzji i dostępem do kodu. Pośrednik — agencja, broker, „kolega zna programistę” — dolicza zwykle 20–40% marży i wydłuża pętlę komunikacji: pytanie przechodzi przez dwie osoby, zanim dotrze do tego, kto pisze kod. Plus jest taki, że ktoś prowadzi projekt i pilnuje terminów. Minus: repozytorium i dokumentacja często zostają po stronie pośrednika.

Bezpośredni kontakt z deweloperem skraca tę drogę, ale znaczy też, że to Ty pilnujesz zakresu, odbioru i terminów. Jeśli nie chcesz robić tego sam, lepiej wybrać model, w którym jedna firma odpowiada i za kod, i za utrzymanie.

Odległość nie jest problemem — praca z Józefowa nad modułem pisanym 200 km dalej wygląda dziś normalnie. Problemem jest brak rytmu. Ustal na starcie:

• Jeden kanał na ustalenia (mail lub zgłoszenia), żeby został ślad — nie tylko telefony.
• Jedno demo tygodniowo na stagingu z listą tego, co zostało zrobione.
• Czas odpowiedzi na pytania, np. do końca następnego dnia roboczego.
• Krótkie podsumowanie ustaleń po każdej rozmowie.

Na koniec SLA. „W razie problemów dzwoń” to nie SLA. W umowie powinno być wprost: czas reakcji, czas naprawy błędu krytycznego, liczba godzin w pakiecie, co jest poza pakietem i kto płaci za aktualizacje zgodnościowe. Podobny układ opisaliśmy przy współpracy przy niestandardowych modułach i wtyczkach w Krasnobrodzie oraz przy porządku pracy przy modułach i wtyczkach w Zwierzyńcu — zasady są te same, zmienia się skala sklepu.

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

Lista kontrolna do odklikania

• Brief na piśmie — Przed pierwszą wyceną. Powinien opisywać proces po kolei: kto, co i w jakiej kolejności robi w sklepie, oraz co ma się dziać w sytuacjach nietypowych.
• Spis przypadków brzegowych — Sprawdź, czy dokument zawiera m.in. zamówienie z kilkoma metodami dostawy, zwrot, anulowanie, brak towaru w magazynie i ponowienie płatności.
• Lista integracji i wersje API — Ustal, z czym moduł się łączy (ERP, system księgowy, płatności, kurierzy) i czy dokumentacja API jest publiczna. Brak dokumentacji API to realne ryzyko opóźnienia.
• Wersje środowiska — Zapisz wersję PHP, PrestaShop lub WordPressa, WooCommerce oraz motywu. Moduł pisany pod PHP 7.4 a hosting na PHP 8.2 to gotowy problem przy pierwszym uruchomieniu.
• Środowisko stagingowe — Sprawdź przed startem prac, czy istnieje kopia sklepu z aktualną bazą i czy da się na niej odtworzyć prawdziwe zamówienie bez wysyłki maili do klientów.
• Repozytorium i dostępy — Ustal, na czyim koncie powstaje repozytorium i kto ma do niego dostęp. Powinno być po stronie klienta albo z wyraźnym zapisem przekazania na koniec umowy.
• Kryteria akceptacji — Przed startem: lista konkretnych sytuacji, które muszą zadziałać, żeby uznać etap za zakończony. Bez tego odbiór zamienia się w dyskusję o odczuciach.
• Plan wycofania zmian — Zapytaj, jak wdrożenie zostanie cofnięte, jeśli po godzinie okaże się, że koszyk przestaje działać. Odpowiedź „poprawimy na bieżąco” nie jest planem.
• Testy na kopii danych produkcyjnych — Uzgodnij, czy testy idą na danych anonimizowanych, czy na kopii bazy. Testowanie na pustym sklepie pomija najwięcej błędów.
• Dokumentacja i changelog — Po każdym etapie sprawdź, czy do repozytorium trafił opis zmian. Brak changelogu oznacza, że za pół roku nikt nie ustali, co dokładnie zmieniono.
• Kto aktualizuje po wdrożeniu — Ustal jedną osobę lub firmę odpowiedzialną za aktualizacje po wydaniu nowej wersji PrestaShop, WooCommerce i PHP. Najczęstsza luka w umowach.
• Własność kodu i licencje — Sprawdź, kto ma prawa do kodu modułu i czy nie zawiera on bibliotek na licencji, która blokuje dalszy rozwój. Zapisz to w umowie, nie w mailu.
• Monitoring błędów po wdrożeniu — Przez pierwsze dni po wdrożeniu ktoś powinien patrzeć w logi błędów i kolejki zadań w tle. Cichy błąd w module potrafi zatrzymać zamówienia bez żadnego maila.

Najczęściej zadawane pytania

Źródła i materiały

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