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

Moduł PrestaShop to katalog plików w /modules/, który sklep rozpoznaje po pliku głównym z klasą dziedziczącą po Module. W nim definiujesz hooki (actionValidateOrder, displayAdminProductsExtra), tworzysz tabele przez install(), dodajesz kontroler w /controllers/admin/ i szablony .tpl. Instalujesz go z panelu (Moduły → Menedżer modułów) albo wgrywasz ZIP-em. To wszystko dzieje się w środku sklepu: moduł ma dostęp do koszyka, sesji klienta, cenników i uprawnień pracownika.

Wtyczka WooCommerce to katalog w /wp-content/plugins/ z nagłówkiem Plugin Name w pliku głównym. Podpinasz się pod akcje i filtry WordPressa (add_action, add_filter), a w WooCommerce pod hooki typu woocommerce_checkout_create_order czy woocommerce_cart_calculate_fees. Ekran ustawień robisz na Settings API albo własnym kontrolerze. Efekt ten sam: kod działa wewnątrz CMS-a i dziedziczy jego logikę.

Granica biegnie tam, gdzie kończy się CMS. Jeśli proces ma obsłużyć kilku klientów, działać poza sklepem (np. aplikacja dla handlowca w terenie) albo wymaga własnej bazy i API — to już aplikacja dedykowana, nie moduł. Moduł rozszerza sklep, aplikacja żyje obok niego.

Dwa kontrastowe przykłady. Pierwszy: dopisanie pola „numer projektu” do pozycji zamówienia i wypisanie go w mailu — jedno rozszerzenie hooka, około 20 linii w jednym pliku, bez nowych tabel, bez panelu. Drugi: dwukierunkowa integracja z ERP — mapowanie 40 pól, kolejka, ponawianie błędów, panel do ręcznego wznowienia, logi i testy na danych produkcyjnych. To okolice 200 godzin, niezależnie od tego, czy pracujesz w PrestaShop, czy w WooCommerce. Start: dokumentacja deweloperska PrestaShop.

Gotowa wtyczka czy własny moduł – tabela decyzyjna

Nie zaczynaj od pytania „ile kosztuje moduł”. Zacznij od policzenia nietypowych warunków, których nie obsłuży żadna wtyczka z marketplace’u. Praktyczny próg: 0–1 warunek — bierz gotową wtyczkę. 2–3 warunki — wtyczka plus krótki dopisek (20–40 godzin). 4 i więcej (cennik B2B z limitami, dwa magazyny, integracja ERP, nietypowa numeracja dokumentów) — licz się z modułem własnym, bo sklejanie czterech wtyczek kończy się konfliktem na hookach.

Drugi próg to skala. Do około 300 zamówień miesięcznie gotowa wtyczka zwykle wystarcza wydajnościowo. Powyżej — sprawdź, ile zapytań do bazy generuje na liście produktów. Wtyczki pisane „na wszelki wypadek” potrafią dorzucić kilkadziesiąt zapytań na kategorię.

Trzeci próg to koszt w czasie. Wtyczka abonamentowa 800 zł/rok przez 3 lata to 2400 zł. Własny moduł 4000 zł jednorazowo plus 400 zł/rok utrzymania to w tym samym okresie 5200 zł — czyli w trzy lata drożej. Uczciwie: przy tych liczbach moduł wygrywa na kontroli i braku limitów licencji, a nie na cenie. Punkt przełamania policz sam: 4000 + 400×n = 800×n daje dziesięć lat. Ale jeśli wtyczka kosztuje 2500 zł/rok i wymaga dopłaty za każdą kolejną domenę albo stanowisko, zwrot wypada już po dwóch latach.

Czerwona flaga, przy której nie negocjuj: wtyczka z 2016 roku, brak aktualizacji od 18 miesięcy, autor nie odpowiada na forum wsparcia. Taka wtyczka po podniesieniu PHP do 8.x potrafi wywalić sklep, a nikt tego nie naprawi. Zanim kupisz — sprawdź datę ostatniej wersji, listę zmian i aktywność wątku wsparcia.

Ile to realnie kosztuje – widełki dla PrestaShop i WooCommerce

Wycena modułu to godziny pomnożone przez stawkę. W polskim rynku MŚP stawka za pracę przy PrestaShop i WooCommerce waha się od 120 do 220 zł/h. Na dolnej granicy znajdziesz prostsze prace i mniejsze studia, na górnej — zespoły z własnym QA, środowiskiem staging i dokumentacją. Na widełki wpływa też rodzaj pracy: front sklepu i administracja to zwykle niższa stawka, integracje i przenoszenie danych — wyższa.

Trzy zakresy, które pokrywają większość zapytań:

• Prosty moduł funkcjonalny (dodatkowe pole w formularzu, drobna zmiana logiki rabatu, etykieta płatności) — 6–12 godzin, czyli 900–1800 zł przy 150 zł/h.
• Średni moduł z panelem w adminie (lista ustawień, własna tabela, eksport CSV, uprawnienia) — 25–60 godzin, 3750–9000 zł.
• Integracja ERP z mapowaniem danych (dwukierunkowa synchronizacja, kolejka, ponawianie błędów, logi) — 80–200 godzin, 12 000–30 000 zł.

Te liczby mają sens tylko wtedy, gdy wiesz, co siedzi w wycenie. Powinny być tam: analiza (10–15% budżetu, kończy się opisem pól i przypadków brzegowych), kod, testy na środowisku staging, krótka dokumentacja wdrożeniowa, publikacja na produkcji i okres gwarancji (typowo 3–6 miesięcy). Zapytaj też, czego w wycenie nie ma: hostingu, licencji zewnętrznych, zmian po odbiorze, szkolenia zespołu.

Pułapka numer jeden: brak etapów płatności. Ustal kamienie milowe — analiza, działający prototyp, odbiór. Drugiej rzeczy pilnuj przy cenniku: jeśli moduł dotyka cen B2B, przetestuj go na realnych grupach klientów przed wdrożeniem. Zasady rozbicia prac na etapy opisujemy szerzej przy temacie niestandardowych modułów dla cennika i organizacji pracy.

Jak wygląda proces wdrożenia krok po kroku

Niestandardowy moduł to projekt z siedmioma etapami. Każdy kończy się artefaktem do akceptacji — dzięki temu wiesz, za co płacisz na bieżąco, a nie dopiero przy odbiorze. Tak wygląda typowy przebieg w projektach realizowanych jako aplikacje dedykowane na zamówienie.

1. Brief. 1–2 h warsztatu plus pisemny opis procesu. Klient dostarcza przykładową fakturę i WZ z ERP, zrzut ekranu z listą rabatów, informację kto i kiedy zmienia ceny.
2. Analiza i wycena godzinowa. Rozbicie na zadania z widełkami: integracja z Subiektem 40–80 h, reguły wysyłki 16–30 h, panel B2B 30–60 h. Unikaj wycen „za całość” bez listy zadań.
3. Makieta i akceptacja. Ekrany w Figmie lub klikalny prototyp, akceptacja na piśmie z datą — to moment zamrożenia zakresu.
4. Development na kopii. Praca na lokalnej kopii (Docker lub serwer deweloperski), kod w repozytorium Git, osobny branch na każde zadanie.
5. Testy na stagingu. Kopia bazy produkcyjnej z anonimizacją danych osobowych, scenariusze testowe spisane punkt po punkcie.
6. Wdrożenie produkcyjne. Okno serwisowe, backup bazy i plików przed wypchnięciem, tag wersji w repo, plan rollbacku.
7. Okres wsparcia. Typowo 30–90 dni na poprawki błędów po stronie wykonawcy, potem umowa serwisowa z SLA.

Rola klienta nie kończy się na podpisaniu umowy. Na starcie potrzebne są: konto testowe w ERP (najlepiej read-only albo na kopii bazy), dostępy sandboxowe kurierów (InPost, DPD i DHL udostępniają środowiska testowe), przykładowy cennik z realnymi rabatami oraz jedna osoba decyzyjna, która akceptuje etapy. Jeśli konta testowego kuriera nie ma, testy wysyłki odbędą się na produkcji — i ktoś wyśle prawdziwą paczkę.

Raport postępu: raz w tygodniu mail z podsumowaniem (co zrobione, co blokuje, co w kolejce) plus lista zadań w tickecie — GitHub Issues, Jira, Trello, cokolwiek, byle klient miał do niej wgląd. Na koniec każdego etapu krótkie demo (15–20 min) i pytanie „akceptujesz?”. To wystarcza, by wyłapać rozjazd po dwóch tygodniach, a nie po trzech miesiącach.

Najczęstsze przypadki – kiedy MŚP naprawdę potrzebuje własnego modułu

W polskim MŚP trzy sytuacje wracają najczęściej — i w każdej gotowa wtyczka z marketplace’u zwykle się wykłada.

1. Integracja z ERP. Subiekt GT/nexo, Comarch Optima, WF-Mag. Gotowe mostki obsługują standard: stan magazynowy, nowe zamówienie, faktura. Pękają przy nietypowej numeracji dokumentów — faktury z prefiksem oddziału (FA/2024/KRK/001), korekty z własną serią, WZ wystawiane ręcznie, albo dwa magazyny, gdzie jedno zamówienie trzeba rozbić na dwie dostawy. Do tego idempotencja: jeśli mostek ponowi zapytanie po timeoucie, nie może powstać druga faktura do tego samego zamówienia. To wymaga mapowania dokumentów w obie strony i tabeli stanu synchronizacji.

2. Reguły wysyłki. InPost, DPD, DHL — mapowanie stref (kody pocztowe, tereny trudno dostępne), gabarytów, wagi gabarytowej i COD za granicą. Przykład: przesyłka pobraniowa na Słowację bywa niedostępna dla wybranej usługi, a sklep nadal pokazuje ją w koszyku. Efekt: klient składa zamówienie, które trzeba odrzucić albo dopłacić za wysyłkę z własnej kieszeni.

3. Cennik B2B. 200–500 kontrahentów, rabaty na grupy produktów, limity kredytowe, płatność odroczona, zamówienia na zamówienie (produkcja pod klienta) z własnym obiegiem akceptacji. Standardowy mechanizm „grupa klienta = rabat procentowy” nie wystarcza, bo rabat zależy od kategorii, wolumenu i historii płatności. Takie wdrożenie zwykle robimy na PrestaShop, ale logika cennika jest przenośna także na WooCommerce.

Policz to na godzinach. Ręczne przepisywanie zamówień przy 50 zamówieniach dziennie to łatwo 1,5–2 h pracy biura każdego dnia, czyli 350–480 h w roku. Przy stawce biurowej 40–60 zł/h mówimy o 15–30 tys. zł rocznie na czynność, która nie generuje sprzedaży.

Pułapki, które kosztują najwięcej – i jak je wykryć przed zakupem

Zanim podpiszesz umowę, zadaj trzy pytania. Odpowiedzi powiedzą więcej niż portfolio.

Repozytorium i własność kodu. Zapytaj, gdzie będzie kod (GitHub, GitLab, Bitbucket — repo prywatne) i kiedy dostaniesz dostęp. Poproś o podgląd historii commitów: jeśli na trzy miesiące pracy przypadają cztery commity z opisem „update”, to znak, że kod nie był wersjonowany na bieżąco. W umowie musi być zapis o przeniesieniu majątkowych praw autorskich i przekazaniu kodu wraz z dostępami po odbiorze i zapłacie. Bez tego zostajesz z działającym modułem, którego nie możesz zlecić komu innemu.

Hard-code i nadpisania. W PrestaShop zapytaj wprost, czy moduł wrzuca pliki do katalogu nadpisań i czy modyfikuje tabele core. Nadpisania klas i kontrolerów potrafią się wysypać przy aktualizacji — moduł przestaje działać albo, gorzej, działa częściowo i nikt tego nie zauważa przez tygodnie. Dokumentacja deweloperska PrestaShop opublikowana pod adresem devdocs.prestashop-project.org opisuje właściwy sposób rozszerzania sklepu: hooki, własne tabele z prefiksem, brak ingerencji w pliki spoza katalogu modułu. W WooCommerce sprawdź, czy zmiany siedzą w child theme, czy ktoś edytował pliki wtyczki (po aktualizacji znikną) i czy kod nie jest dopisany do functions.php motywu.

Jak sprawdzić jakość. Zamów code review u drugiego dewelopera (2–6 h pracy) albo audyt przed odbiorem. Checklista akceptacyjna powinna zawierać: scenariusze testowe na stagingu z kopią danych, test aktualizacji (kopia sklepu, update PrestaShop lub WooCommerce, sprawdzenie czy moduł nadal działa), przegląd logów błędów i zapytań SQL pod kątem zapytań w pętli, oraz test ponowienia operacji — co się stanie, gdy ERP nie odpowie w ciągu 30 sekund.

Utrzymanie, aktualizacje i bezpieczeństwo własnych modułów

Moduł oddany na produkcję nie jest „skończony” — jest wersją, która działa na konkretnej wersji CMS-a. PrestaShop 1.7 → 8 to zmiana warstwy Symfony, sposobu rejestracji hooków i struktury katalogów modułu; kod, który w 1.7 działał, w 8 potrafi wywalić biały ekran albo przestać zapisywać dane. WooCommerce 8 → 9 zmieniło obsługę zamówień (HPOS, tabele wc_orders zamiast wp_posts/wp_postmeta), więc wtyczka pisząca bezpośrednio do wp_postmeta zacznie gubić zamówienia albo dublować stany. Dochodzi PHP: przejście z 7.4 na 8.1/8.2 to ostrzeżenia o przestarzałych funkcjach, a w 8.3 część z nich staje się błędami krytycznymi. Pierwszy objaw braku aktualizacji to zwykle nie „brzydki wygląd”, a niedziałające zamówienia, brakujące faktury albo rozjechane stany magazynowe.

SLA to najczęściej pomijany punkt umowy utrzymania. Powinny być w nim cztery liczby: czas reakcji, czas naprawy, kanał zgłoszeń i godziny obowiązywania. Do tego monitoring błędów (np. Sentry albo logi PHP z alertem na maila), kopie zapasowe plików i bazy przed każdą aktualizacją oraz procedura rollbacku.

Parametr	Co zapisać	Przykładowa wartość
Czas reakcji	potwierdzenie przyjęcia zgłoszenia	4 h w dni robocze
Czas naprawy – błąd krytyczny	od zgłoszenia do poprawki na produkcji	24 h
Czas naprawy – błąd kosmetyczny	kolejka zadań	5 dni roboczych
Zakres utrzymania	co wchodzi w abonament	aktualizacja przy nowej wersji CMS, poprawki błędów
Kopie zapasowe	częstotliwość i retencja	1x dziennie, 30 dni
Monitoring	narzędzie i odbiorca alertów	Sentry + logi PHP na maila

Bezpieczeństwo czterech rzeczy nie negocjuj:

• walidacja wejścia — każde dane z formularza lub URL przechodzą przez Tools::getValue() i walidację typu/zakresu w PrestaShop albo sanitize_text_field()/absint() w WordPress,
• escaping wyjścia — esc_html(), esc_attr(), esc_url(), a nie surowe $_GET w szablonie,
• zero SQL klejonego stringiem — $wpdb->prepare() w WP, rzutowanie (int) plus pSQL w PrestaShop. Zapis „WHERE id = ” . $_GET['id'] to dziura, nie skrót,
• uprawnienia plików: 644 dla plików, 755 dla katalogów, 777 tylko tymczasowo i nigdy na produkcji. Katalog modułu nie może zawierać .git ani pliku z danymi do bazy.

Wzorce i wymagania wersji sprawdzisz w dokumentacji dla deweloperów PrestaShop — przy wątpliwościach jest to szybszy punkt odniesienia niż forum.

Jak wybrać wykonawcę – pytania, które zadaj przed podpisaniem umowy

Pięć pytań zadanych przed podpisaniem umowy filtruje więcej niż całe portfolio. Jeśli wykonawca odpowiada ogólnikami, nie odpowiada wcale.

• Kto będzie kodował? Oczekuj imienia, nicku na GitHubie i informacji, kto robi code review. Odpowiedź „nasz zespół deweloperów” bez nazwisk oznacza zwykle, że praca pojedzie do podwykonawcy, który nie zna Twojego sklepu.
• Jak wyceniacie — godziny czy fixed? Przy niestandardowym module uczciwa jest stawka godzinowa plus szacunek w przedziale (np. 40–60 h) i raport z przepracowanych godzin. Fixed price da się podać tylko wtedy, gdy zakres jest zamknięty — a przy module do ERP zwykle nie jest.
• Co z prawami do kodu? W umowie musi być przeniesienie autorskich praw majątkowych na Ciebie, bez licencji ograniczającej. Kod w Twoim repozytorium od pierwszego commita, nie „przekażemy po zakończeniu”.
• Jaki macie SLA? Konkret: czas reakcji na błąd krytyczny (np. 4 h w dni robocze), czas naprawy, kanał zgłoszeń. „Reagujemy na bieżąco” to nie SLA.
• Jak wygląda repozytorium i przekazanie? Git z dostępem dla Ciebie, tagi wersji, README z instalacją i opisem hooków, informacja, jak wygląda deployment na staging i produkcję.

Czerwone flagi, które powinny zatrzymać rozmowę: brak repozytorium (kod wysyłany ZIP-em przez mail), brak jakiejkolwiek dokumentacji, brak okresu wsparcia po wdrożeniu, brak próbki kodu do wglądu przed startem.

Pracując bezpośrednio z deweloperem, zgłoszenie krytyczne trafia od razu do osoby, która zna ten kod. Przez pośrednika idzie przez handlowca i project managera — a marża 20–40% doliczana jest do każdej godziny, także do poprawki błędu. Efekt widzisz w czasie reakcji mierzonym w dniach i w rachunku za coś, co autor naprawiłby w godzinę. Zanim wybierzesz wykonawcę, sprawdź, czy pracujesz na PrestaShop czy WordPress — kompetencje w obu systemach nie zawsze idą w parze. Jeśli projekt wykracza poza sklep, popatrz też na aplikacje dedykowane.

Checklista przed zamówieniem modułu lub wtyczki

Wydrukuj i odklikaj przed podpisaniem umowy. Każdy nieodklikany punkt wróci jako zmiana zakresu albo spór o dopłatę.

Punkt	Co konkretnie sprawdzić
1. Zakres	opisany scenariusz po scenariuszu, razem z przypadkami brzegowymi (np. zamówienie B2B powyżej limitu)
2. Wycena godzinowa	stawka za godzinę i szacunek w przedziale
3. Próg przekroczenia	zapis, że wykonawca informuje przy np. +20% ponad szacunek
4. Prawa do kodu	przeniesienie praw majątkowych w umowie, bez licencji ograniczającej
5. Repozytorium	Git z Twoim dostępem od pierwszego commita
6. Staging	osobne środowisko testowe z kopią danych produkcyjnych
7. Testy i akceptacja	lista scenariuszy do przetestowania i kto je podpisuje
8. Wydajność	wpływ na czas ładowania strony i na zapytania do bazy
9. SLA i wsparcie	czas reakcji, czas naprawy, długość gwarancji na błędy (np. 3–6 miesięcy)
10. Dokumentacja	instrukcja instalacji, opis hooków i ustawień
11. Aktualizacje	kto i kiedy dostosowuje moduł do nowej wersji CMS
12. Kopie i rollback	backup przed wdrożeniem i procedura przywrócenia

W akceptacji powinni brać udział dwie osoby: właściciel (decyduje o zakresie i koszcie) oraz osoba, która codziennie obsługuje sklep — to ona zauważy, że formularz limitu B2B liczy netto zamiast brutto albo że numer dokumentu nie idzie do ERP. Akceptacja „na oko” przez jedną osobę to najczęstsze źródło poprawek po odbiorze.

Jeśli prowadzisz firmę na Lubelszczyźnie, szerszy opis stawek i kolejności etapów znajdziesz w materiale o niestandardowych modułach i wtyczkach dla Zamościa — cennik i organizacja.

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

Lista kontrolna do odklikania

• Zapis o własności kodu — Sprawdź przed podpisaniem umowy: przeniesienie praw, obowiązek przekazania repozytorium i dokumentacji, zakaz używania kodu u konkurencji.
• Repozytorium Git i historia commitów — Poproś o dostęp do repo już w trakcie prac. Historię commitów widać od pierwszego tygodnia — brak commitów zwykle oznacza, że kod powstaje na ostatni dzień.
• Override zamiast edycji core — Zapytaj, które pliki core będą zmieniane. Poprawna odpowiedź: żadne, całość przez hooki i override w module.
• Test aktualizacji — Zrób na stagingu aktualizację PrestaShop lub WooCommerce oraz podbicie wersji PHP. Testuj przed odbiorem, nie po.
• Data ostatniej aktualizacji wtyczki — Dla gotowej wtyczki: changelog, data wydania nowej wersji, deklarowane wsparcie dla Twojej wersji CMS-a. Brak wpisu od 12–18 miesięcy to czerwona flaga.
• Kanał wsparcia i czas reakcji — Ustal, gdzie zgłaszasz problemy: ticket, e-mail, telefon. Wpisz do umowy czas reakcji, np. 1 dzień roboczy dla błędów blokujących.
• Zakres wyceny — Wycena ma zawierać: analizę, kod, testy, dokumentację, wdrożenie i okres gwarancji. Pozycja „inne” bez opisu to zaproszenie do dopłat.
• Stawka godzinowa i limit — Ustal stawkę (dla MŚP w Polsce zwykle 120–220 zł/h) oraz limit godzin na etap. Chcesz wiedzieć, kiedy koszt przekroczy założenie.
• Środowisko staging i kopia zapasowa — Przed startem prac: kopia plików i bazy, osobny adres stagingu, opisany sposób wycofania zmian na produkcji.
• Dostępy testowe — Przygotuj konta testowe ERP, kurierów (InPost, DPD, DHL) i przykładowy cennik. Bez tego development stoi, a godziny lecą.
• Rozliczenie etapami — Płać po odbiorze etapu, nie z góry za całość. Trzy–cztery kamienie milowe to zdrowy standard przy module powyżej 60 h.
• Gwarancja i utrzymanie po odbiorze — Sprawdź długość gwarancji (typowo 3–6 miesięcy) i co dokładnie obejmuje. Osobno policz koszt rocznego utrzymania.
• Plan na wypadek zmiany wykonawcy — Zapytaj, co się stanie, jeśli współpraca się skończy. Poprawna odpowiedź: przekazanie repo, dokumentacji i dostępów w ciągu 14 dni.

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