Własny moduł do PrestaShop albo wtyczka do WooCommerce to wydatek rzędu kilku tysięcy złotych, więc decyzję warto oprzeć na liczbach, a nie na przeczuciu. W tym tekście skupiamy się na organizacji pracy: co ustalić przed pierwszym commitem, jak zweryfikować wykonawcę i czego wymagać na koniec. Znajdziesz tu listę błędów, które najczęściej podnoszą koszt, checklistę przed startem i odpowiedzi na pytania wracające przy każdym wdrożeniu. Widełki godzinowe i szczegóły techniczne omawiamy w pozostałych sekcjach artykułu.
Zanim zamówisz kod, odpowiedz pisemnie na pięć pytań. Każde „nie wiem” to sygnał, że najpierw potrzebujesz warsztatu, a dopiero potem programisty.
Próg opłacalności jest prosty: gdy roczna licencja przekracza ok. 1500 zł i potrzebujesz 3 lub więcej integracji, własny moduł zwraca się zwykle w 12–24 miesiące. Kolejność etapów i rozłożenie płatności opiszemy też w materiale o kosztach i organizacji modułów w Zamościu.
| Wariant | Kiedy ma sens | Typowy zakres prac | Główne ryzyko |
|---|---|---|---|
| Gotowa wtyczka | 1 integracja, standardowy proces, budżet do ok. 1500 zł/rok | 1–3 dni konfiguracji | Autor porzuca rozwój, konflikt po aktualizacji |
| Wtyczka + własne dopiski | Proces nietypowy w 20–30% przypadków | 8–20 h pracy programisty | Kod doklejony do cudzego, aktualizacja go nadpisze |
| Moduł pisany od zera | 3+ integracje, dane wrażliwe, proces daje przewagę | 40–120 h | Wymagania rosną w trakcie, brak specyfikacji |
| Przebudowa procesu bez kodu | Da się uprościć procedurę zamiast automatyzować bałagan | 2–6 h warsztatu | Zespół wraca do starych nawyków |
Siedem etapów to siedem punktów kontrolnych. Po każdym powinieneś dostać coś na piśmie albo do wglądu.
actionValidateOrder, displayAdminOrder, actionOrderStatusPostUpdate; w WooCommerce woocommerce_checkout_create_order, woocommerce_order_status_changed. Pomocny jest przy tym oficjalny opis hooków i struktury modułu PrestaShop.Na koniec dostajesz: repozytorium z historią zmian, README z opisem hooków i konfiguracji, instrukcję wdrożenia dla swojego administratora oraz 30 dni gwarancji na poprawki błędów — nie na nowe funkcje. Jeśli chcesz sprawdzić, jak wygląda utrzymanie takiego kodu przez kolejne lata, zobacz materiał o porządku w kodzie modułów w Szczebrzeszynie.
Wycena własnego modułu to godziny razy stawka plus bufor na niespodzianki po stronie systemów zewnętrznych. Trzy przykłady z realnych wdrożeń:
Stawka za godzinę to zwykle 120–200 zł netto. Wyższa oznacza doświadczenie w konkretnym API, pracę z architektem lub branżę regulowaną. Czas wydłużają: brak dokumentacji po stronie partnera (dodaj 20–40% godzin), brak środowiska testowego (prace idą na produkcji, więc każdy błąd jest droższy) oraz liczba języków i walut — każdy dodatkowy język to nowe pola, tłumaczenia i osobne przypadki testowe.
Rozbicie wyceny wygląda mniej więcej tak: analiza 10–15%, kod 50–60%, testy 15–20%, wdrożenie 5–10%, opieka przez 30 dni 5–10%. Poza ceną zostają zwykle: licencje i abonamenty zewnętrznych usług, zmiany wymagań w trakcie prac, migracja danych historycznych oraz prace po stronie dostawcy API. Ustal to przed startem — szczegóły rozliczeń opisujemy w artykule o cenie i organizacji modułów w Zamościu.
| Zadanie | Godziny | Kwota przy 120 zł/h | Kwota przy 200 zł/h |
|---|---|---|---|
| Eksport zamówień do ERP | 16–24 h | 1 920–2 880 zł | 3 200–4 800 zł |
| Integracja kurierska z mapą punktów | 24–40 h | 2 880–4 800 zł | 4 800–8 000 zł |
| Konfigurator produktu | 60–120 h | 7 200–14 400 zł | 12 000–24 000 zł |
W PrestaShop każdy moduł to katalog w /modules, np. /modules/mojmodul/, z plikiem głównym mojmodul.php i klasą dziedziczącą po Module. Rozszerzanie sklepu odbywa się przez hooki: registerHook() w metodzie install() podłącza moduł do punktów takich jak displayHeader, actionValidateOrder, actionOrderStatusPostUpdate czy displayAdminOrderMain. Jeśli hook istnieje, używamy hooka.
Override wchodzi w grę tylko wtedy, gdy platforma nie wystawia żadnego hooka i logiki nie da się podmienić inaczej. Plik trafia wtedy do /override/classes/... i dosłownie nadpisuje metodę rdzenia. Działa to do pierwszej aktualizacji: PrestaShop 8.x zmienił część sygnatur i przeniósł panel administracyjny na Symfony, więc override pisany pod 1.7 potrafi wywalić błąd 500 po aktualizacji. Do tego dwa moduły mogą nadpisywać tę samą metodę — wygrywa ten zainstalowany później, a drugi przestaje działać bez komunikatu. Wymagaj od wykonawcy deklaracji zgodności z 1.7 i 8.x oraz testu na obu wersjach; 8.x wymaga PHP 8.1+, a kod pisany pod PHP 7.x sypie się na dynamicznych właściwościach.
W WooCommerce nie ma override — są akcje i filtry (add_action, add_filter). Kod czytający zamówienia musi być zgodny z HPOS (High-Performance Order Storage): zamiast get_post_meta($order_id, '_billing_email') trzeba użyć wc_get_order($id) i metod typu get_billing_email(), a kompatybilność zadeklarować przez FeaturesUtil::declare_compatibility(). Szablony zmieniamy wyłącznie w child theme. Jak trzymać porządek w takich plikach, opisujemy przy okazji tematu porządku w kodzie modułów i wtyczek. Szczegóły techniczne hooków i struktury katalogów znajdziesz w dokumentacji deweloperskiej PrestaShop.
| Element | PrestaShop | WooCommerce |
|---|---|---|
| Miejsce kodu | /modules/nazwa/ | /wp-content/plugins/nazwa/ |
| Punkt rozszerzeń | hooki (registerHook) | akcje i filtry (add_action, add_filter) |
| Zmiana logiki rdzenia | override w /override/ — ostateczność | brak — tylko hooki i child theme |
| Co najczęściej psuje aktualizacja | override i nieudokumentowane pola | odczyt zamówień przez postmeta przy HPOS, edycja parent theme |
| Minimalna wersja PHP | 8.1 dla PrestaShop 8.x | zależna od wersji WordPress i WooCommerce — potwierdź przed startem |
Moduł integracyjny nie jest ozdobą sklepu, tylko elementem procesu. Zanim padnie pierwsza linijka kodu, ustal mapowanie statusów: co w sklepie odpowiada jakiemu stanowi w ERP i u kuriera. Bez tego zdarza się klasyka — zamówienie oznaczone w sklepie jako „w realizacji” w ERP widnieje jako „nowe” i magazyn pakuje je drugi raz.
Idempotencja wysyłki to drugi must. Jeśli po timeoutcie ponowisz żądanie bez klucza idempotencji (np. numer zamówienia plus typ dokumentu), w systemie kuriera powstaną dwie etykiety, a Ty zapłacisz za dwie przesyłki. Praktyka: zapisz w bazie rekord „etykieta zamówiona” przed wysłaniem żądania, a po odpowiedzi dopisz numer przesyłki. Kolejki i ponowienia ustaw na 3–5 prób z rosnącym odstępem (np. 1, 5, 30 minut) i osobną kolejką dla żądań, które nie przejdą — inaczej błąd API blokuje checkout klienta.
InPost, DPD i DHL mają limity zapytań po swojej stronie. Listę punktów odbioru pobieraj raz na dobę do własnej tabeli i odświeżaj cronem, zamiast odpytywać API przy każdym wejściu klienta na stronę dostawy. Ustal też, skąd bierze się waga i gabaryty paczki (pole produktu, wartość domyślna), kto decyduje o podziale na wiele paczek i kiedy numer śledzenia trafia mailem — dopiero po potwierdzeniu z API, nie „na wszelki wypadek” od razu.
Płatności: źródłem prawdy jest webhook, nie powrót klienta na stronę. Weryfikuj podpis webhooka, deduplikuj zdarzenia po identyfikatorze transakcji i nie oznaczaj zamówienia jako opłacone, jeśli połączenie zerwało się w trakcie. Wtedy ustaw status „oczekuje na potwierdzenie” i sprawdź stan zapytaniem do bramki. Widełki czasowe i stawki takich prac opisujemy w materiale o koszcie i organizacji wdrożenia modułu.
| Zdarzenie | Status w sklepie | Co ma się stać dalej |
|---|---|---|
| Webhook potwierdza płatność | Opłacone | utworzenie zamówienia w ERP |
| Wygenerowano etykietę | Wysyłka w przygotowaniu | zapis numeru śledzenia |
| Paczka nadana | Wysłane | aktualizacja stanów magazynowych |
| Zwrot zarejestrowany | Zwrot | korekta dokumentu i przyjęcie na magazyn |
Odbiór modułu to nie „działa u mnie na testowym zamówieniu”. Zacznij od OWASP w praktyce. Dane wejściowe waliduj i czyszcz: w WooCommerce sanitize_text_field(), absint(), filter_var(); w PrestaShop Tools::getValue() plus rzutowanie typu. Wyjście zawsze escapuj — esc_html(), esc_attr(), esc_url(). Sprawdzaj uprawnienia: w WooCommerce current_user_can() z konkretną capability, w PrestaShop profil pracownika i jego dostęp do danego kontrolera. Zapytań SQL nie skleja się ze stringów — używaj $wpdb->prepare() albo metod Db z parametrami. Sekrety (klucze API kurierów, bramek płatności) trzymaj poza repozytorium: .env lub opcje w bazie, a wpis w .gitignore. Jeśli klucz trafił do repo, nie „usuwaj commita” — unieważnij klucz i wygeneruj nowy.
Logi mają pomagać, nie gromadzić dane osobowe. Do logów trafia: identyfikator zamówienia, identyfikator transakcji, kod błędu API, czas, identyfikator żądania. Nie loguj pełnych danych klienta, numerów kart, tokenów ani całych odpowiedzi z API. Ustaw rotację logów i retencję, np. 30–90 dni.
Utrzymanie zaplanuj na piśmie: kto aktualizuje PrestaShop, WooCommerce i PHP (przejście z 8.1 na 8.2/8.3 to realne ryzyko dla starych wtyczek), na jakim środowisku testujecie, jak wygląda kopia zapasowa (pliki i baza, z testem odtworzenia raz na kwartał) i jak wracacie do poprzedniej wersji — tag w repozytorium plus kopia przed wdrożeniem. Jak ułożyć taki plan pracy, opisujemy też w tekście o organizacji pracy przy niestandardowych wtyczkach.
| Poziom | Przykład | Reakcja | Naprawa |
|---|---|---|---|
| Krytyczny | sklep nie przyjmuje zamówień, błąd płatności | do 2 h w godzinach pracy | do 8 h |
| Wysoki | nie generują się etykiety kurierskie | do 4 h | do 24 h |
| Średni | błędny status w ERP przy części zamówień | 1 dzień roboczy | 3 dni robocze |
| Niski | literówka w mailu, kosmetyka w panelu | 3 dni robocze | najbliższe wydanie |
Do takiego audytu nie potrzebujesz dostępu do serwera ani umiejętności pisania w PHP. Wystarczy terminal, konto w repozytorium i dwa pytania do wykonawcy. Oto siedem sygnałów, które w praktyce najczęściej kończą się przepisywaniem modułu.
git log --oneline | head -20. Brak historii oznacza, że nie ustalisz, kto i kiedy zmienił logikę cen czy wysyłki./modules/nazwa_modulu, w WooCommerce w wp-content/plugins/nazwa-wtyczki. Sprawdzenie: git log --stat --since="6 months ago" i wyłapanie ścieżek spoza tych katalogów. Nadpisany core zniknie przy pierwszej aktualizacji sklepu.Dwa pytania rozstrzygają najwięcej. Pierwsze: „wypisz hooki, których używa moduł” — poprawna odpowiedź to lista, np. actionValidateOrder, displayHeader, actionOrderStatusPostUpdate, a nie „różne”. Drugie: „jak wygląda aktualizacja modułu?” — oczekuj skryptów upgrade-1.2.0.php i numeru wersji w pliku głównym. Mechanizm hooków i strukturę katalogów opisuje dokumentacja dla deweloperów PrestaShop.
Gdy moduł działa, ale nie ma dokumentacji, kolejność jest stała: 1) przejmij repozytorium, 2) oznacz obecną wersję tagiem, 3) wypisz hooki poleceniem grep -rn "registerHook\|add_action\|add_filter", 4) dopisz README z listą hooków, tabel i zadań cron, 5) dopiero potem zlecaj rozwój. Taniej jest napisać od nowa, gdy kod ma ponad 3–5 tys. linii bez testów i przy każdym zadaniu trzeba go czytać od zera. Zanim odrzucisz wykonawcę, uporządkuj proces po swojej stronie — pomoże w tym materiał o organizacji pracy nad modułami w Zamościu.
| Sygnał | Jak sprawdzić w 15 minut | Typowy skutek |
|---|---|---|
| Brak repozytorium | git log --oneline | Brak możliwości cofnięcia zmiany, 2–4 h na odtworzenie historii |
| Zmiany poza katalogiem modułu | git log --stat, diff z czystą instalacją | Awaria po aktualizacji sklepu |
| Stary PHP | Wymagania w pliku głównym modułu | Moduł przestaje działać po zmianie hostingu |
| Brak obsługi błędów API | Szukanie curl/file_get_contents bez try/catch | Utracone zamówienia, trudne do wykrycia |
| Błędy widoczne dla klienta | Test na staging z wyłączonym kluczem API | Wyciek danych, spadek zaufania |
| Brak tłumaczeń | Brak plików .php/.po w /translations | Poprawka tekstu wymaga dewelopera |
| Brak scenariuszy testowych | Pytanie o listę przypadków testowych | Każda zmiana to 1–2 h ręcznego klikania |
Praca zdalna z deweloperem nie różni się dziś od pracy z biurem obok — pod warunkiem, że ustalisz rytm. Rozmawiasz bezpośrednio z osobą, która pisze kod, a nie z handlowcem przekazującym ustalenia dalej. Z Szczebrzeszyna do Lublina jest około 90 km, ale odległość ma znaczenie właściwie tylko przy odbiorze końcowym. Kod, repozytorium i środowisko testowe są dostępne przez przeglądarkę.
Konkretne ustalenia, które warto mieć zapisane w umowie albo w e-mailu: okno odpowiedzi (np. reakcja do 4 godzin w dni robocze, w godzinach 9:00–16:00), jedno 30-minutowe spotkanie w tygodniu i demo na stagingu co dwa tygodnie. Dzięki temu nie musisz dopytywać „co tam słychać” — widzisz listę zadań i commity. Jeśli wolisz jeden wyjazd na miejscu, to zwykle wystarcza na warsztat startowy i odbiór.
Cztery pytania, które zadaj przed podpisaniem umowy:
Dopisz też, czy rozliczenie jest godzinowe, czy ryczałtowe, i co dzieje się przy przekroczeniu zakresu. Pytanie o stawkę za dodatkową godzinę zadane przed startem jest znacznie tańsze niż spór w trakcie. Sposób prowadzenia takiego projektu od pierwszego commita opisujemy w artykule o porządku w kodzie modułów i wtyczek w Szczebrzeszynie, a sposób kalkulowania budżetu — w materiale o koszcie i organizacji prac nad modułami w Zamościu.
Wycena bez specyfikacji, ustalanie zakresu na czacie
Jak wykryć: Wykonawca podaje kwotę po jednej rozmowie, bez listy funkcji. Na pytanie o przypadki brzegowe odpowiada, że „to się doprecyzuje w trakcie”.
Jak naprawić: Zamów warsztat 1-2 h i specyfikację na 2-4 strony z listą funkcji oraz przypadków brzegowych. Dopiero na tej podstawie porównuj oferty — inaczej porównujesz dwa różne zakresy.
Praca bez repozytorium i środowiska staging
Jak wykryć: Pliki zmieniane przez FTP, brak historii zmian, poprawki wchodzą od razu na produkcję, nikt nie potrafi wskazać brancha.
Jak naprawić: Wymagaj Gita z osobnym branchem i kopii sklepu na stagingu. Wdrożenie produkcyjne w oknie serwisowym, po testach i po wykonaniu kopii zapasowej bazy oraz plików.
Testy na czystej instalacji zamiast na kopii produkcyjnej bazy
Jak wykryć: Moduł działa na demo, a na sklepie sypie się na zamówieniach z wieloma walutami albo na starych rekordach po migracji.
Jak naprawić: Testy wykonuj na zanonimizowanej kopii bazy produkcyjnej. Czysta instalacja nie odtwarza historii zamówień, nietypowych adresów ani danych po wcześniejszych wtyczkach.
Override tam, gdzie wystarczyłby hook
Jak wykryć: W kodzie lub dokumentacji widać pliki w katalogu /override. Po aktualizacji PrestaShop moduł przestaje działać albo funkcje dublują się w dwóch miejscach.
Jak naprawić: Zamień override na hook, jeśli platforma daje taki punkt rozszerzenia. Override zostawiaj tylko tam, gdzie nie ma alternatywy — i zapisz każdy taki przypadek w README.
Brak idempotencji i ponowień w integracjach
Jak wykryć: Po błędzie API pracownik klika „wyślij ponownie” i powstają dwie etykiety na to samo zamówienie. Nikt nie wie, ile zapytań wysyła sklep w ciągu minuty.
Jak naprawić: Ustal klucz idempotencji po numerze zamówienia, dodaj kolejkę i ponowienia z odstępem. Sprawdź limity zapytań po stronie usługodawcy i zapisz je w specyfikacji.
Brak dokumentacji i praw do kodu po odbiorze
Jak wykryć: Kod zostaje na serwerze wykonawcy, nie ma README ani instrukcji wdrożenia, a każda poprawka jest wyceniana jak nowe prace.
Jak naprawić: Wpisz do umowy przekazanie repozytorium, README z opisem hooków i punktów styku, instrukcję wdrożenia oraz 30 dni gwarancji na poprawki błędów.
Własny moduł nie jest celem samym w sobie — to narzędzie do obsługi procesu, którego nie da się kupić w gotowej wtyczce. Najważniejsze decyzje zapadają przed pierwszym commitem: specyfikacja, lista hooków, mapowanie statusów i wycena w godzinach. Jeśli wykonawca pokazuje repozytorium, dokumentację i 30 dni gwarancji, ryzyko spada bardziej niż przy najlepszej obietnicy. Praktyczny próg to licencja powyżej 1500 zł rocznie i co najmniej trzy integracje — wtedy własny kod zaczyna się zwracać.
Nie. Przy prostym sklepie bez integracji gotowa wtyczka za kilkaset złotych rocznie jest zwykle tańsza i szybsza. Własny kod ma sens, gdy roczna licencja przekracza około 1500 zł i potrzebujesz trzech lub więcej integracji — wtedy zwrot następuje zwykle w 12-24 miesiące.
Warsztat 1-2 h, specyfikacja na 2-4 strony, lista hooków i mapowanie statusów zamówień. Dopiero na tej podstawie dostajesz wycenę w godzinach, którą można porównać z inną ofertą. O porządkowaniu pracy przy takich projektach piszemy w tekście o organizacji prac nad modułami w Zamościu.
Eksport zamówień do ERP to zwykle 16-24 h, integracja kurierska z mapą punktów odbioru 24-40 h, a konfigurator produktu 60-120 h. Do tego dolicz analizę, testy i 30 dni opieki po wdrożeniu. Terminy podawane wyłącznie w dniach, bez godzin, zwykle nic nie znaczą.
Najczęstsza przyczyna awarii to override plików core oraz kod sięgający do nieudokumentowanych pól w bazie. Zapytaj wykonawcę, gdzie siedzą hooki i czy moduł korzysta z override. PrestaShop opisuje mechanizm hooków i wymagania wersji w dokumentacji dla deweloperów.
Repozytorium z historią zmian, README z opisem hooków i punktów styku, instrukcję wdrożenia oraz 30 dni gwarancji na poprawki błędów. Jeśli wykonawca nie chce przekazać kodu, to sygnał ostrzegawczy. Kolejność etapów opisujemy w tekście o porządku w kodzie modułów i wtyczek.
Nie. Czysta instalacja nie ma starych zamówień, nietypowych adresów, wielu walut ani danych po wcześniejszych migracjach. Dlatego testy wykonuje się na zanonimizowanej kopii produkcyjnej bazy. Dopiero tam wychodzą przypadki, które psują integrację dwa tygodnie po starcie.
Od warsztatu i spisania procesu: kto, co i kiedy robi po złożeniu zamówienia, gdzie trafiają dane i kto reaguje na błąd. Bez tego specyfikacja będzie zgadywaniem, a wycena — loterią. Zobacz też, jak wygląda organizacja pracy w Chełmie i w Hrubieszowie.
Jeśli chcesz przejść przez ten proces z zespołem, który pokaże Ci godziny, repozytorium i zakres na piśmie — napisz do DropDigital. Powiemy wprost, kiedy wystarczy gotowa wtyczka, a kiedy własny moduł ma sens.