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

Moduł (PrestaShop) i wtyczka (WooCommerce) to w praktyce to samo: paczka kodu, którą dokładasz do sklepu i która zmienia jego działanie. Różnica siedzi w mechanice.

PrestaShop — moduł to katalog w /modules/ z plikiem głównym (np. mojmodul/mojmodul.php) i klasą dziedziczącą po Module. Moduł „zaczepia się” o hooki: displayHook (np. displayShoppingCart) coś wyświetla na stronie, a actionHook (np. actionCartSave) reaguje na zdarzenie i nic nie pokazuje. Rejestracja hooków dzieje się w metodzie install().

WooCommerce — wtyczka to plik PHP z nagłówkiem Plugin Name, a praca opiera się na dwóch mechanizmach WordPressa: akcjach (add_action) i filtrach (add_filter). Akcja uruchamia kod, filtr zmienia wartość — np. woocommerce_package_rates podmienia koszt dostawy, zanim zobaczy go klient w koszyku.

Przykład z życia: sklep z materiałem sypkim sprzedawanym na palety. Koszt dostawy zależy od dwucyfrowego kodu pocztowego, wagi palety i tego, czy klient zapewnia rozładunek. Gotowe wtyczki liczą strefy i progi wagowe, ale takiego złożenia zwykle nie mają. Bez własnego kodu zostaje ręczne przeliczanie 30–50 zamówień miesięcznie.

Trzy pytania przed decyzją o budowie własnego kodu:

• Czy proces powtarza się co najmniej raz w tygodniu i czy w firmie jest osoba, która zna go od podszewki?
• Czy dane wejściowe są już w sklepie (kod pocztowy, waga, wymiary) czy ktoś musi je wpisywać ręcznie?
• Czy istnieje gotowa wtyczka, którą da się przetestować na demo, zanim cokolwiek zamówisz?

Jeśli na któreś pytanie odpowiadasz „nie wiem”, to jeszcze nie moment na wycenę. Szersze ujęcie tematu znajdziesz w materiale o niestandardowych modułach i wtyczkach w Bełżcu. Katalog hooków i strukturę modułu opisuje dokumentacja PrestaShop dla deweloperów.

Kiedy opłaca się budować własny moduł, a kiedy kupić gotową wtyczkę

Próg opłacalności policz na kartce, zanim poprosisz o wycenę. Wzór: roczny koszt licencji × liczba lat + czas obsługi (aktualizacje, konfiguracja, poprawki) versus jednorazowe 20–40 godzin pracy nad własnym rozwiązaniem.

Przykład pierwszy: wtyczka do indywidualnego cennika, licencja 400 zł rocznie, 3 lata to 1200 zł, a własny moduł to około 25 godzin. Sama licencja wypada taniej — dopóki nie policzysz pracy ludzi. Jeśli dział zamówień spędza 10 godzin miesięcznie na ręcznym przepisywaniu danych, to 120 godzin w roku. Wtedy własny kod zwraca się w pierwszym kwartale, niezależnie od ceny licencji.

Przykład drugi to antywzorzec: sklep z 30 zamówieniami miesięcznie, jedna firma kurierska, prosty cennik. Gotowa wtyczka plus tabela stref wysyłki w WooCommerce załatwia temat. Budowa i utrzymywanie własnego modułu przy każdej aktualizacji WooCommerce to koszt bez zwrotu.

Kryterium	Kup wtyczkę	Buduj własny kod
Dopasowanie do procesu	proces standardowy, mieści się w ustawieniach	proces ma wyjątki, których nie da się obejść ustawieniami
Liczba integracji zewnętrznych	0–1 (np. jeden kurier)	2 i więcej (ERP, magazyn, kilku kurierów, płatności)
Ryzyko konfliktu z innymi dodatkami	wtyczka od znanego wydawcy, testowana z nowymi wersjami	konflikt rozwiązujesz raz, w jednym miejscu
Koszt licencji na 3 lata	znany z góry, przewidywalny	jednorazowo 20–40 h, potem utrzymanie
Wsparcie po polsku	jest, z deklarowanym czasem reakcji	po stronie wykonawcy — ustal, co po gwarancji

Konflikt, który realnie blokuje checkout: trzy wtyczki kurierskie na jednej instalacji WooCommerce, każda filtruje woocommerce_package_rates i dopisuje swoje metody wysyłki. Objaw: przy „Złóż zamówienie” biały ekran lub błąd 500, płatność przechodzi, ale zamówienie nie powstaje. Diagnostyka jest prosta: włącz WP_DEBUG_LOG, wyłączaj wtyczki po jednej i sprawdzaj, po której problem wraca. Najczęstsze wyjście to przepisanie integracji w jedną własną wtyczkę z osobnymi metodami wysyłki. Podobne przypadki opisujemy w materiałach o modułach i wtyczkach w Lublinie oraz o organizacji pracy nad wtyczkami w Biłgoraju.

Jak wygląda budowa własnego modułu krok po kroku

Kolejność etapów jest sztywna. Zamiana ich miejscami to najczęstszy powód dopłat i opóźnień.

Etap	Co się dzieje	Co dostajesz
1. Analiza	rozmowa o procesie: ile zamówień, ile czasu zajmuje dziś, kto go obsługuje	notatkę z ustaleniami
2. Specyfikacja (1–2 strony)	cel, dane wejściowe i wyjściowe, hooki, przypadki brzegowe oraz lista rzeczy, których moduł NIE robi	dokument do akceptacji
3. Wycena godzinowa	liczba godzin, stawka, zasada rozliczania zmian zakresu	wycenę z limitem
4. Praca na kopii sklepu	kod powstaje na środowisku deweloperskim, nie na produkcji	działającą wersję testową
5. Testy na stagingu	pełna ścieżka zamówienia, aktualne wersje PHP i sklepu	listę przetestowanych scenariuszy
6. Wdrożenie produkcyjne	okno poza szczytem sprzedaży, kopie plików i bazy, wyłączony cache	moduł na produkcji
7. Dokumentacja i przekazanie	instrukcja instalacji, lista hooków, repozytorium, kontakt na wsparcie	kod i opis

Definicja „done” jest węższa, niż się wydaje. Moduł jest skończony, gdy: działa po aktualizacji sklepu lub PHP, nie generuje wpisów w logach błędów (w PrestaShop katalog var/logs, w WordPress plik z WP_DEBUG_LOG), ma spisaną listę hooków i instrukcję instalacji oraz odinstalowania. Ustal też z góry, czy odinstalowanie usuwa dane z bazy, czy je zostawia.

Staging jest obowiązkowy, gdy moduł dotyka koszyka, checkoutu, płatności, cen albo wysyłki. Test na produkcji w godzinach sprzedażowych oznacza ryzyko utraconych zamówień, a nie tylko brzydkiego widżetu. Minimum: kopia plików i bazy z ostatnich 24 godzin, osobna domena stagingowa z wyłączonym indeksowaniem i wyłączonymi mailami do klientów, żeby test nie wysłał potwierdzenia zamówienia prawdziwej osobie. Praktykę wdrożeniową z innych miast opisujemy przy okazji modułów i wtyczek w Krasnobrodzie oraz porządku pracy nad wtyczkami we Frampolu.

PrestaShop czy WooCommerce: różnice techniczne, które wpływają na koszt i ryzyko

Ten sam pomysł — np. „pole z datą dostawy na checkout” — kosztuje inaczej w PrestaShop i inaczej w WooCommerce. Różnica nie jest widzimisię wykonawcy, tylko wynika z tego, jak platforma pozwala dopiąć się do swojego rdzenia.

PrestaShop. Standardowa droga to moduł w katalogu /modules/nazwa_modulu, klasa dziedzicząca po Module i hooki, np. hookActionCartSave czy hookDisplayProductAdditionalInfo. Problem zaczyna się, gdy trzeba zmienić logikę kontrolera — wtedy powstaje override, np. /override/controllers/front/ProductController.php. Override działa do pierwszej aktualizacji sklepu. Po aktualizacji plik rdzenia się zmienia, a Twój override albo nie pasuje do nowej sygnatury metody, albo działa dalej i po cichu liczy coś inaczej. Objaw: błąd 500 po aktualizacji albo ceny zaniżone o kilka złotych w jednej grupie klientów.

WooCommerce. Tu override nie istnieje. Rozbudowę robi się przez child theme (style.css z wpisem Template: nazwa-motywu) oraz filtry i akcje: add_filter('woocommerce_product_get_price', ...), add_action('woocommerce_checkout_create_order', ...). To z definicji mniej inwazyjne, bo aktualizacja WooCommerce nie kasuje Twojego kodu. Ale każdy filtr wykonuje się przy każdym żądaniu — nadmiar filtrów to jedna z częstszych przyczyn wolnego checkoutu.

Wydajność. Liczba zapytań do bazy to najprostszy miernik jakości modułu. Kategoria z 24 produktami powinna zmieścić się w kilkudziesięciu zapytaniach. Jeśli kod w pętli woła get_post_meta() lub Product::getProductName() dla każdego produktu osobno, masz N+1 zapytań — 24 produkty to 24 dodatkowe zapytania przy każdym wejściu. Cachowanie (transient API, Object Cache, Cache::store) nie jest ozdobą.

PHP 8.x. Zgodność z nowymi wersjami PHP i platformy to pozycja w wycenie, nie dodatek. Struktury modułów i mechanizm override opisuje dokumentacja dla deweloperów PrestaShop — warto tam zajrzeć przed rozmową z wykonawcą.

Ile to kosztuje: widełki w godzinach, nie cennik z sufitu

Niestandardowe moduły i wtyczki w Narolu wycenia się według tych samych widełek co w większych miastach — stawka zależy od typu pracy, nie od kodu pocztowego. Realne przedziały netto: prace modułowe 80–150 zł/h, prace integracyjne (API, ERP, kurierzy) 120–220 zł/h, serwis i interwencje 100–180 zł/h. W mniejszych ośrodkach dolne widełki są osiągalne, ale najtańsza oferta często oznacza brak doświadczenia z konkretną platformą — wtedy sama analiza zajmuje 8 godzin zamiast 3.

Trzy typowe wyceny, które zobaczysz w ofertach:

• Prosty moduł funkcjonalny — 16–24 h. Np. dodatkowe pole „numer zamówienia klienta” na checkout, walidacja i eksport zamówień do CSV.
• Kalkulator lub konfigurator produktu — 24–40 h. Np. kalkulator metrażu z ceną zależną od trzech opcji i przekazaniem konfiguracji do koszyka.
• Integracja z ERP lub systemem magazynowym — 60–120 h. Np. synchronizacja stanów i zamówień z Subiektem albo WMS-em przez API, z kolejką i obsługą błędów.

Co siedzi w wycenie: analiza (2–6 h), kod, testy (minimum 15–20% czasu projektu), dokumentacja (2–4 h), wdrożenie na produkcję (1–3 h, poza godzinami sprzedaży) i szkolenie z obsługi (1–2 h). Co jest osobną pozycją: migracja danych, licencje i abonamenty zewnętrznych API, rozszerzenie hostingu, SLA z czasem reakcji. Jeśli oferta ma jedną kwotę bez rozbicia — pytaj, co jest w środku.

Zmiana zakresu w trakcie prac. Przykład zapisu, który warto wkleić do umowy: „Prace ponad ustalony zakres rozliczane są stawką 140 zł/h netto, w blokach po 4 godziny, po potwierdzeniu e-mail. Kod nieobjęty zakresem nie wchodzi do wdrożenia bez akceptacji.” Bez takiego zdania kalkulator rozjeżdża się o 6–10 h, bo w trakcie okazuje się, że potrzebny jest jeszcze eksport do PDF i integracja z płatnością. Więcej o kolejności kroków pisaliśmy przy okazji organizacji pracy nad modułami w Lublinie.

Pułapki w niestandardowych modułach: jak je wykryć przed i po wdrożeniu

Jakości kodu nie ocenisz, czytając pliki, ale kilka objawów da się zmierzyć bez wiedzy programistycznej.

1. Liczba zapytań do bazy. W PrestaShop włącz profilowanie (_PS_DEBUG_PROFILING_) i sprawdź liczbę zapytań na stronie kategorii. W WooCommerce zainstaluj Query Monitor na kopii sklepu i podejrzyj kolumnę „Queries”. Punkt odniesienia: 30–60 zapytań na stronę kategorii to norma. 300+ i czas zapytań liczony w dziesiątkach milisekund oznacza N+1 — typowo pętla po produktach, w której dla każdego produktu osobno pobierane są metadane, zdjęcia i stany magazynowe. To najczęstsza przyczyna skoku czasu ładowania po wdrożeniu.

2. Overrides blokujące aktualizacje. Zajrzyj do katalogu /override/. Jeśli leży tam kilkanaście plików i nikt nie potrafi powiedzieć, do czego służą — przy najbliższej aktualizacji coś padnie. Prosty test: rozpakuj czystą paczkę tej samej wersji PrestaShop i porównaj sumy kontrolne plików rdzenia. Każda różnica to Twoje ryzyko.

3. Brak obsługi błędów. Test z życia: w module od kuriera podmień klucz API na błędny i złóż zamówienie. Jeśli koszyk znika albo pojawia się biała strona, moduł nie ma try/catch ani logowania. Powinien pokazać komunikat na checkout i zapisać zdarzenie w pliku logu, zamiast wywalać cały proces zakupowy.

4. Zadania cron bez limitów. Objaw: sklep zwalnia równo raz na godzinę. Zadanie cykliczne bez set_time_limit, bez przetwarzania partiami i bez blokady (flock) potrafi uruchomić się dwa razy równolegle i zapchać bazę. Przykład: indeksowanie 40 tys. produktów co godzinę.

5. Brak repozytorium. Pytanie kontrolne do wykonawcy: „Pokaż mi repozytorium i ostatnie commity.” Brak Gita oznacza, że przy dwóch osobach pracujących nad sklepem pliki są sobie nadpisywane. Sposób ułożenia tych kroków w mniejszym zespole opisaliśmy w materiale o porządku pracy przy wtyczkach we Frampolu.

Utrzymanie i SLA: co musi być w umowie po wdrożeniu

Wdrożenie niestandardowego modułu to nie koniec projektu. Błędy wychodzą po dwóch–trzech tygodniach: bramka płatności przestaje odpowiadać po aktualizacji PrestaShop, feed do porównywarki wysyła ceny brutto po zmianie VAT, eksport zamówień do ERP gubi zamówienia z odbiorem osobistym. Jeśli umowa nie mówi, w jakim czasie dostawca ma zareagować, w praktyce reaguje wtedy, gdy ma wolny termin.

Ustal trzy poziomy i zapamiętaj jedno: „czas reakcji” to nie „czas naprawy”. Reakcja w 4 h oznacza, że ktoś odebrał zgłoszenie, potwierdził je i zaczął diagnozę — nie że sklep działa po 4 h. Rozpisz też, co dokładnie jest awarią blokującą. Bez przykładów dostawca zakwalifikuje wszystko jako P3.

Poziom	Przykład zdarzenia	Czas reakcji	Czas naprawy
P1	Błąd 500 w koszyku, brak możliwości złożenia zamówienia, niedziałająca płatność	4 h, dni robocze 8:00–18:00	8 h roboczych albo obejście w tym samym dniu
P2	Moduł nalicza złą kwotę dostawy, nie eksportuje części zamówień do ERP	24 h	2 dni robocze
P3	Zmiana tekstu w mailu, dodatkowe pole w formularzu, korekta progu darmowej dostawy	48 h	najbliższe okno wdrożeniowe, zwykle raz w tygodniu

Kopia zapasowa przed każdą zmianą: pliki i baza, wykonane maksymalnie 30 minut przed wdrożeniem i sprawdzone — samo to, że zadanie w cronie się wykonało, nic nie znaczy. Kopia trzymana na tym samym serwerze to nie backup. Wdrożenie idzie najpierw na środowisko testowe, potem na produkcję, w oknie poza szczytem sprzedaży (6:00–8:00, nie 12:00 w dzień wyprzedaży). Rollback opisany na papierze: kto podejmuje decyzję, w jakim czasie od wykrycia problemu (np. 30 minut) i jak wracamy — pełnym przywróceniem snapshotu, nie ręcznym cofaniem plików, po którym połowa zmian zostaje. Zobacz, jak wygląda organizacja pracy nad modułami w Bełżcu — te zasady nie zależą od odległości od wykonawcy.

Własność kodu i repozytorium: zapisz wprost, że kod i majątkowe prawa autorskie przechodzą na Ciebie po zapłacie ostatniej faktury. W praktyce dostęp do repozytorium (GitHub, GitLab) jako współpracownik, nie „u wykonawcy na dysku”, plus README, lista użytych hooków, zależności i instrukcja aktualizacji. Przy rozstaniu odbierasz repozytorium, zrzut bazy i konfigurację serwera w tym samym dniu.

Monitoring i alerty. Minimum: uptime sprawdzany co minutę, alert przy kodzie 500, przy czasie odpowiedzi serwera powyżej 1,5 s oraz przy spadku liczby zamówień o 30% dzień do dnia. Progi warto oprzeć o wskaźniki Web Vitals opisane przez web.dev. Zapisz, kto odbiera alert — Ty czy dostawca — i czy monitoring jest wliczony w abonament.

Praca z deweloperem z Narola i okolic: zdalnie czy na miejscu

Moduł do PrestaShop, wtyczkę do WooCommerce, integrację z API kuriera czy program do fakturowania można zrobić w 100% zdalnie i tak wygląda większość takich projektów. Programista nie musi być w Twoim biurze, żeby dodać metodę płatności albo poprawić naliczanie kosztu dostawy. Struktura modułu w PrestaShop jest opisana w dokumentacji dla deweloperów PrestaShop — warto tam zajrzeć, żeby sprawdzić, czy wykonawca trzyma się standardu (hooki zamiast nadpisywania plików core).

Na miejscu realnie potrzebne są trzy rzeczy. Pierwsza: inwentaryzacja procesu magazynowego — jak pracownicy zbierają zamówienia, w jakiej kolejności, czy skanują kody, gdzie ważą i pakują paczki. To, co jest w opisie procesu, rzadko pokrywa się z tym, co dzieje się na hali. Druga: podłączenie do sprzętu i systemów lokalnych — serwer ERP stojący w biurze, waga, drukarka kodów, terminale na hali, czasem osobne łącze albo VPN. Trzecia: szkolenie zespołu, jeśli moduł zmienia codzienną pracę.

Element projektu	Zdalnie czy na miejscu	Co przygotować po Twojej stronie
Płatności, dostawy, faktury, feedy produktowe	100% zdalnie	Dokumentację API i dane testowe od dostawcy usługi
Integracja z ERP lub bazą SQL	Zdalnie, jeśli serwer jest dostępny z internetu	Adres serwera, konto VPN, kopię bazy na testy
Inwentaryzacja procesu magazynowego	Wizyta na miejscu, 1–2 dni	Dostęp do hali i osoby, które realnie zbierają zamówienia
Waga, drukarka kodów, terminal w hali	Na miejscu	Sprzęt, instrukcje i kontakt do jego dostawcy
Szkolenie zespołu przed startem	Zdalnie (2 × 1 h) albo na miejscu	Listę osób i scenariusze najczęstszych zamówień

Dostępy przekazujesz na kontach technicznych, nie na danych właściciela. W praktyce: SFTP z dostępem tylko do katalogu modułu, konto w panelu z rolą ograniczoną do zamówień i modułów, osobne konto do bazy (nie root), SSH z kluczem, panel hostingu. Hasła w menedżerze (Bitwarden, 1Password), nie w mailu ani na Messengerze. Po zakończeniu współpracy odbierasz dostępy i zmieniasz hasła.

Komunikacja: jedno miejsce na zgłoszenia (Trello, Basecamp albo GitHub Issues), każde z datą i priorytetem. Raz w tygodniu podsumowanie godzin z podziałem na zadania — widzisz, ile poszło na poprawki po Twojej stronie, a ile na nowe funkcje. Ustal limit godzin w miesiącu i co się dzieje po jego przekroczeniu. Demo na środowisku testowym przed każdym wdrożeniem na produkcję. Jeśli szukasz wykonawcy w okolicy, zobacz, jak wygląda praca przy modułach w Lublinie, Biłgoraju, Frampolu, Józefowie i Krasnobrodzie.

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

Lista kontrolna do odklikania

• Właściciel modułu po stronie sklepu — Jedna osoba, która podejmuje decyzje o zakresie i akceptuje odbiór. Ustal ją przed pierwszym spotkaniem — bez tego każda drobna zmiana wróci na biurko właściciela firmy.
• Zakres na papierze — 1–2 strony: co moduł robi, czego nie robi, jakie dane pobiera i skąd. Sprawdź, czy wykonawca powtórzył zakres własnymi słowami — to najszybszy test, czy zrozumiał temat.
• Wycena rozbita na etapy — Poproś o podział na analizę, kod, testy i dokumentację. Przy odbiorze porównaj faktycznie przepracowane godziny z tym podziałem, zamiast patrzeć tylko na sumę.
• Repozytorium kodu — Przed startem ustal, gdzie trafia kod i kto ma dostęp. Sprawdź, czy widzisz historię zmian, a nie wyłącznie ostatni plik do pobrania.
• Kopia sklepu do prac — Wykonawca powinien pracować na własnej kopii z danymi testowymi. Jeśli loguje się do panelu produkcyjnego „tylko coś sprawdzić”, zatrzymaj to od razu.
• Staging zgodny z produkcją — Ta sama wersja PHP, ta sama wersja platformy i ten sam zestaw dodatków. Zweryfikuj to przed pierwszym testem — inaczej testy nie znaczą nic.
• Dane testowe — Produkty, strefy wysyłki, metody płatności i konta klientów przygotowane na kopii. Testuj przypadki brzegowe, nie tylko ścieżkę „wszystko działa”.
• Test po aktualizacji platformy — Zanim odbierzesz prace, poproś o aktualizację platformy na stagingu i ponowne uruchomienie modułu. To jedyny moment, kiedy można to sprawdzić bez ryzyka.
• Logi po wdrożeniu — Pierwsze 24–48 godzin. Sprawdź logi błędów i logi płatności, nie tylko to, czy strona się ładuje — część problemów nie jest widoczna na pierwszy rzut oka.
• Pomiar wydajności — Zapytaj, ile zapytań do bazy dodaje moduł w pętli produktowej i czy wyniki są cachowane. Przy większym katalogu różnicę zobaczysz w czasie ładowania listy produktów.
• Plan wyłączenia — Moduł musi dać się wyłączyć jednym kliknięciem, bez psucia widoku sklepu. Przetestuj to na stagingu, nie wtedy, gdy będzie potrzebne na produkcji.
• Dokumentacja i przekazanie — Przed ostatnią fakturą. Powinna zawierać listę hooków, instrukcję instalacji i konfiguracji oraz informację, gdzie jest kod źródłowy.
• Okno wdrożeniowe — Poza godzinami sprzedażowymi, najlepiej wtedy, gdy nikt nie składa zamówień. Zapisz datę i godzinę w kalendarzu razem z wykonawcą i osobą decyzyjną.
• Przegląd po 30 dniach — Umów go z góry. Po miesiącu zbiera się lista drobiazgów — lepiej zaplanować je jako jeden blok niż zgłaszać pojedynczo przez pół roku.

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