Czym są niestandardowe moduły i wtyczki w firmie – definicja bez ściemy

Moduł w PrestaShop to katalog z plikami PHP, w którym główna klasa dziedziczy po klasie Module. Sklep wykrywa taki katalog, rejestruje go i uruchamia w wybranych hookach – na przykład displayHeader, actionCartSave albo displayAdminOrder. Wtyczka w WordPress to katalog w wp-content/plugins z plikiem głównym opatrzonym nagłówkiem Plugin Name, który podpina się do akcji i filtrów przez add_action i add_filter. Tyle wystarczy, żeby wiedzieć, o czym rozmawiamy: to rozszerzenie funkcji sklepu albo strony, nic więcej.

Różnica nie siedzi w definicji, tylko w tym, co kod ma robić. Konfiguracja gotowej wtyczki to przestawienie opcji, które przewidział autor. Obejście to dopisanie kilkunastu linii w functions.php, w szablonie .tpl albo przez plugin typu Code Snippets – działa do pierwszej aktualizacji. Kod pisany pod proces firmy to trzecia kategoria.

Przykład z praktyki: sklep z materiałami budowlanymi ma cennik dostawy zależny od tabeli gabarytów paletowych i strefy dojazdu. Gotowe wtyczki liczą wagę albo wartość koszyka. Moduł pisany pod proces pobiera wymiary z atrybutów produktu, sprawdza tabelę i dolicza transport w koszyku. Drugi przykład: moduł, który przy zmianie statusu zamówienia wysyła dokument do ERP i odbiera numer faktury. Gotowiec tego nie zrobi, bo ERP w firmie jest zwykle jeden i nietypowy.

Zanim cokolwiek zamówisz, przeczytaj materiał o porządku pracy wokół niestandardowych modułów i wtyczek – bez repozytorium, środowiska testowego i dokumentacji custom kod staje się czarną skrzynką. Strukturę modułów i hooki opisuje dokumentacja dla deweloperów PrestaShop.

Kiedy firmie ze Zwierzyńca i okolic opłaca się własny moduł, a kiedy wystarczy gotowa wtyczka?

Pięć sygnałów, że gotowa wtyczka nie dowiezie:

• Unikalny proces. Zamówienia B2B z indywidualnymi progami rabatowymi na klienta, akceptacja zamówienia przez opiekuna, oferty PDF z własnym szablonem – tego w standardzie nie ma.
• Integracja z ERP. Subiekt, Comarch Optima, Wapro, Fakturownia. Każda integracja to mapowanie pól, statusów i jednostek miary. Wtyczki „uniwersalne” kończą się eksportem CSV do ręcznego wczytania.
• Limity licencji. Wtyczka za 400 zł rocznie wygląda tanio, dopóki nie trzeba dokupić wersji Pro za 1 500–4 000 zł/rok i jeszcze add-onu do niej.
• Wydajność przy dużej skali. Katalog 20 tys. SKU i zapytania odpalane przy każdym wejściu to typowa przyczyna spadku LCP, o którym pisze dokumentacja Core Web Vitals. Kod z własnymi indeksami w bazie bywa szybszy od gotowca.
• Wymagania B2B. Ceny ukryte dla gości, cenniki per klient, limity kredytowe, blokada zamówienia przy przekroczeniu salda.

Test trzech obejść. Policz, ile dodatkowych wtyczek i hacków trzeba dołożyć, żeby gotowiec zrobił to, czego potrzebujesz. Jeśli wychodzą trzy i więcej, kolejna aktualizacja jednej zepsuje drugą. Wtedy custom jest tańszy w utrzymaniu, nawet jeśli sam projekt kosztuje dwa–trzy razy więcej niż licencje.

Kiedy zostać przy gotowcu: standardowa wysyłka kurierem z płaską stawką, prosty newsletter, galeria zdjęć, podstawowe płatności online, formularz kontaktowy z zapisem zgód. Tu nie ma czego pisać – wtyczka za 200–500 zł rocznie zrobi to szybciej i taniej niż zespół.

Jak ułożyć odpowiedzialność, repozytorium i przekazanie kodu, opisujemy w sekcji o organizacji wdrożenia modułów i wtyczek dla firmy.

Ile kosztują niestandardowe moduły i wtyczki? Widełki godzinowe i przykłady

Stawka godzinowa doświadczonego dewelopera w Polsce to 120–220 zł netto. 120–150 zł to poziom kogoś z krótszym stażem integracyjnym, 160–190 zł to standard dla osoby, która robi moduły od kilku lat, 200–220 zł płacisz przy nietypowych integracjach (ERP, magazyn, drukarki fiskalne) albo za konsultację architektoniczną. Wycena agencji zaczyna się wyżej, ale w cenie masz testy, wdrożenie na produkcji i wsparcie po odbiorze.

Jak wygląda proces wdrożenia niestandardowego modułu krok po kroku?

Wdrożenie własnego modułu da się rozłożyć na siedem etapów, a każdy kończy się decyzją albo dokumentem. Dzięki temu w każdej chwili wiadomo, co jest zrobione, co czeka na klienta i ile zostało do końca.

• 1. Analiza potrzeb – 1–2 rozmowy po 60–90 minut. Ustalamy, jaki proces ma się zmienić i co dziś robicie ręcznie. Wynik: notatka z opisem procesu i listą wyjątków, np. zamówienie bez e-maila albo faktura na dwóch nabywców. To na wyjątkach moduły najczęściej się wykładają.
• 2. Specyfikacja – dokument z ekranami, polami, regułami i przypadkami brzegowymi. Bez niego kod powstaje na wyczucie i wraca do poprawek.
• 3. Wycena godzinowa – rozbicie na pozycje z liczbą godzin i stawką. Nie wyceniamy ryczałtem od modułu, bo każda zmiana zakresu musi mieć swoją cenę.
• 4. Development na kopii – praca na środowisku staging, nigdy na produkcji. Klient dostaje adres testowy z hasłem.
• 5. Testy – scenariusze pozytywne, negatywne, obciążenie oraz zgodność z wersją PHP i wersją platformy.
• 6. Wdrożenie na produkcję – okno poza godzinami szczytu, kopia bazy przed startem, plan wycofania.
• 7. Opieka i monitoring – logi błędów, alerty, czas reakcji zapisany w umowie.

Po stronie klienta zostają cztery rzeczy: dostępy (hosting, SFTP, baza, panel płatności i kuriera), dane testowe, opis procesu tak, jak wygląda dziś, oraz decyzje biznesowe — np. czy stan magazynowy schodzi w momencie złożenia zamówienia czy zaksięgowania płatności. Realny czas klienta to zwykle 2–5 godzin na etap, głównie na konsultacje i testy.

Przed wdrożeniem przechodzimy listę kontrolną: czy moduł działa na kopii z danymi produkcyjnymi, czy zdarzenia trafiają do logów, czy nie zapisuje niczego poza własnymi tabelami. Dopiero potem odbiór — lista kontrolna podpisana przez obie strony, dokumentacja instalacji i konfiguracji oraz przekazanie praw do kodu i repozytorium. Bez przekazania praw przy zmianie wykonawcy zostajecie z kodem, którego nikt nie może legalnie rozwijać. Warto też od razu ustalić, gdzie leży kod i kto ma do niego dostęp — dobrze opisuje to tekst o porządku pracy przy modułach i wtyczkach Zwierzyniec, a sposób rozbicia prac na pozycje znajdziesz w materiale o cenniku i organizacji wyceny modułów.

Integracje, które najczęściej wymagają custom modułu: ERP, płatności, kurierzy

Custom moduł najczęściej zamawia się przy trzech typach integracji. Każda ma inny zestaw pułapek, ale efekt jest ten sam: albo dane się zgadzają, albo dział obsługi pracuje ręcznie.

ERP. Subiekt GT/ne, Comarch Optima i WF-Mag to najczęstsze systemy w polskich firmach. Zakres mapowania: stany magazynowe, ceny (w tym promocje i grupy klientów), zamówienia i statusy. Pierwsza decyzja przed kodowaniem: kto jest źródłem prawdy. Jeśli stany trzyma Subiekt, a sklep sprzedaje równolegle, potrzebna jest synchronizacja co 5–15 minut i blokada sprzedaży przy stanie zero. Uwaga na jednostki miary, stawki VAT i kody EAN — bez uzgodnienia mapowania moduł pomiesza połowę asortymentu.

Płatności. Przelewy24, PayU, Stripe. Kluczowe są webhooki: to zwykłe żądania HTTP POST wysyłane przez operatora, na które moduł musi odpowiedzieć kodem 200. Status zamówienia zmieniamy wyłącznie po potwierdzeniu z API, nigdy po samym powrocie klienta na stronę. Do tego idempotencja — ten sam callback może przyjść dwa razy i nie może zdublować zamówienia — oraz obsługa płatności nieudanych i zwrotów.

Kurierzy. InPost, DPD, DHL: generowanie etykiet, statusy przesyłek, punkty odbioru (Paczkomaty przez API) oraz gabaryty i waga, które decydują o cenie. Etykieta wygenerowana bez wagi bywa odrzucana przy nadaniu.

Największa pułapka nie leży w samym API, tylko w braku kolejki i logów. Każde wywołanie powinno trafić do kolejki, zapisać request i odpowiedź, a przy błędzie ponowić próbę z odstępem. Przed odbiorem robimy test na 100 i więcej zamówieniach i włączamy monitoring błędów API, żeby dowiedzieć się o awarii szybciej niż klient. Ogólne zasady komunikacji po HTTP opisuje dokumentacja MDN Web Docs – HTTP. Sposób ułożenia takich integracji w większym wdrożeniu pokazuje materiał o organizacji pracy przy niestandardowych modułach i wtyczkach.

Bezpieczeństwo, wydajność i utrzymanie modułu – o czym zapominają firmy

Custom moduł to zobowiązanie na lata. O tym, czy po dwóch latach nadal da się go utrzymać, decydują trzy obszary.

Aktualizacje. PHP wychodzi z fazy wsparcia co roku, WordPress kilka razy w roku, PrestaShop rzadziej, ale też regularnie. Moduł napisany na PHP 7.4 przestaje działać po podniesieniu do 8.2 — najczęściej przez dynamiczne właściwości i przestarzałe funkcje. Zakładamy więc przegląd kompatybilności przy każdej większej aktualizacji platformy, a nie dopiero wtedy, gdy sklep przestanie działać. Wymagania dotyczące struktury modułu znajdziesz w dokumentacji dla deweloperów PrestaShop.

Bezpieczeństwo. Walidacja i sanityzacja danych wejściowych, escaping na wyjściu, tokeny (nonce w WordPressie) w formularzach i żądaniach administracyjnych, sprawdzanie uprawnień użytkownika. Żadnych zapytań SQL sklejanych ze zmiennych — wyłącznie zapytania parametryzowane. Lista OWASP Top 10 to dobry punkt wyjścia do przeglądu przed odbiorem; w praktyce najczęstsze dziury to brak sprawdzenia uprawnień w endpointach AJAX i wyciek danych przez zbyt szczegółowe logi.

Wydajność. Cache dla powtarzalnych zapytań, kolejki dla zadań w tle, indeksy na własnych tabelach, świadomość limitów API (np. liczby zapytań na minutę u kuriera). Test obciążeniowy robimy na kopii: 50 równoległych użytkowników potrafi pokazać problem, którego nie widać przy jednym testerze.

Opieka. SLA z zapisanym czasem reakcji, automatyczne kopie zapasowe bazy i plików, monitoring dostępności i błędów oraz procedura rollback: poprzednia wersja kodu w repozytorium, kopia bazy sprzed wdrożenia, opisany krok po kroku powrót. Bez tego każda awaria to gaszenie pożaru na produkcji. Zakres i stawkę takiej opieki najlepiej ustalić przed startem prac — pomaga w tym zestawienie kosztu utrzymania modułu na zamówienie.

Jak wybrać wykonawcę niestandardowych modułów w Zwierzyńcu i okolicach?

Zanim podpiszesz umowę na moduł do PrestaShop albo wtyczkę do WordPressa, zadaj pięć pytań. Pierwsze: czy pracuję bezpośrednio z deweloperem, czy przez pośrednika? W praktyce różnica to 20–40% wyższa stawka i dłuższa droga komunikatu, gdy coś nie działa. Drugie: czy w cenie dostanę pełny kod źródłowy i dokumentację? Zapis w umowie powinien mówić o repozytorium Git (GitHub, GitLab, Bitbucket) przekazanym na Twoje konto firmowe, a nie o „dostępie do plików na serwerze wykonawcy”. Trzecie: czy jest opieka po wdrożeniu — minimum 30 dni gwarancji na błędy i płatny pakiet utrzymaniowy z określoną liczbą godzin miesięcznie. Czwarte: jakie SLA? Konkretnie: reakcja do 4 godzin w dni robocze przy awarii blokującej zamówienia, do 2 dni roboczych przy błędach kosmetycznych. Piąte: kto aktualizuje moduł, gdy wyjdzie PrestaShop 8.x albo WordPress 6.x i czy testy kompatybilności są w pakiecie.

Drugi krok to przegląd dowodów, nie deklaracji. Poproś o dwie realizacje z podobnego zakresu i o numery wersji systemu, na których pracują. Zapytaj, jak wyglądał ich ostatni rollback i ile trwał. Sprawdź, czy podają cenę za etap, czy jedną kwotę „za całość” — ta druga prawie zawsze kończy się dopłatami.

Pytanie do wykonawcy	Dobra odpowiedź	Czerwona flaga
Praca bezpośrednia czy podwykonawstwo	Rozmawiasz z osobą, która pisze kod	„To już szczegóły naszego zespołu”
Kod i dokumentacja	Repo Git na Twoim koncie + instrukcja instalacji	„Kod zostaje u nas, dostajesz działającą stronę”
Opieka po wdrożeniu	30 dni gwarancji + pakiet godzinowy	Temat nie pojawia się w ofercie
SLA	Reakcja 4 h, naprawa 24–48 h	„Zajmiemy się, gdy będzie czas”
Aktualizacje	Plan testów przy nowych wersjach	„Na razie nie ma takiej potrzeby”

Lokalność nie jest sentymentem, tylko rachunkiem. Wykonawca z Zamościa lub Zwierzyńca dojeżdża na miejsce w 30–60 minut, co przy pilnym wdrożeniu na produkcji ma wymierną wartość. Rozumie też realia lubelskiego rynku: sezonowość, lokalnych dostawców, sposoby rozliczeń. Jeśli porównujesz oferty z innych miast, zobacz, jak wygląda organizacja pracy przy niestandardowych modułach i wtyczkach dla firm ze Szczebrzeszyna oraz jak kształtują się ceny niestandardowych modułów w Zamościu.

Checklista przed zamówieniem modułu – odklikaj i sprawdź

Wydrukuj tę listę i przejdź po niej z wykonawcą punkt po punkcie. Czternaście pozycji, każda zamknięta na „tak” albo „nie”.

• 1. Specyfikacja na piśmie – lista ekranów, pól, integracji i przypadków brzegowych (brak stanu magazynowego, błędny NIP na fakturze, zamówienie z dwóch magazynów).
• 2. Kryteria akceptacji – co dokładnie znaczy „działa”: np. 20 testowych zamówień przechodzi bez ręcznej korekty.
• 3. Wycena etapowa – typowo 30% zaliczki, 40% po stagingu, 30% po odbiorze. Nie 100% z góry.
• 4. Limit poprawek w cenie – minimum dwie rundy uwag do wyglądu i jedna do logiki działania.
• 5. Terminarz z datami – nie „2 tygodnie od startu”, tylko konkretne dni kamieni milowych.
• 6. Dostępy na Twoje konta – repozytorium Git, staging, panel hostingu, baza danych, konto administratora sklepu.
• 7. Środowisko testowe osobno – staging odseparowany od produkcji, dane zanonimizowane.
• 8. Backup przed wdrożeniem – kopia bazy i plików z potwierdzoną datą i godziną.
• 9. Testy – desktop, mobile, płatności w sandboxie, wydajność (LCP poniżej 2,5 s wg wytycznych Core Web Vitals).
• 10. Dokumentacja – instalacja, konfiguracja, lista hooków i endpointów API.
• 11. Własność kodu – przeniesienie praw majątkowych, kod w Twoim repozytorium.
• 12. Opieka – 30 dni gwarancji na błędy, potem pakiet np. 5 godzin miesięcznie.
• 13. Plan aktualizacji – co się dzieje przy nowej wersji PrestaShop lub WordPressa.
• 14. Kontakt awaryjny i SLA – numer telefonu i czas reakcji zapisane w umowie.

Obszar	Minimalny standard	Gdzie to zapisać
Proces	Specyfikacja + protokół odbioru	Umowa, załącznik 1
Budżet	Podział na etapy, limit poprawek	Umowa, harmonogram płatności
Czas	Konkretne daty kamieni milowych	Harmonogram
Dostępy	Repozytorium i konta po Twojej stronie	Załącznik techniczny
Testy	Staging, mobile, płatności, wydajność	Protokół odbioru
Dokumentacja	Instrukcja instalacji i konfiguracji	Przekazanie końcowe
Opieka	Gwarancja i pakiet godzin	SLA w umowie

Jeśli trzy lub więcej punktów wypada na „nie”, wstrzymaj wdrożenie i doprecyzuj zakres. Podpisanie umowy z takim zestawem luk kosztuje później więcej niż dwa tygodnie zwłoki. Zasady porządkowe opisujemy szerzej w materiałach o tym, jak wygląda porządek pracy przy niestandardowych modułach i wtyczkach w Zwierzyńcu.

FAQ: niestandardowe moduły i wtyczki Zwierzyniec dla firmy

Ile kosztuje niestandardowy moduł do PrestaShop albo wtyczka do WordPressa?

Prosty moduł liczący nietypową regułę dostawy to zwykle kilka dni pracy. Integracja z zewnętrznym API, magazynem albo systemem księgowym to 40–120 godzin. Rozstrzał wynika z liczby integracji i przypadków brzegowych, dlatego wycenę wartą rozmowy dostaniesz dopiero po specyfikacji. Sposób kalkulacji i podział na etapy opisujemy w materiale o koszcie i organizacji modułów w Zamościu.

Ile trwa wdrożenie?

Mały moduł: 3–5 dni roboczych od zatwierdzenia specyfikacji. Średnia integracja: 2–4 tygodnie. Duży moduł z panelem administracyjnym i wieloma integracjami: 6–10 tygodni. Do tego doliczyć trzeba 2–5 dni na testy na kopii sklepu i tyle samo na wdrożenie na produkcję.

Czy własny moduł jest bezpieczny?

Tak, pod trzema warunkami: kod przechodzi przegląd pod kątem typowych luk (SQL injection, XSS, brak walidacji uprawnień), nie zapisuje danych wrażliwych w logach, a cała komunikacja idzie po HTTPS. Poproś o raport z testów i o informację, gdzie moduł trzyma dane — czy w osobnej tabeli, czy dopisuje kolumny do tabel systemowych.

PrestaShop czy WordPress z WooCommerce?

Wybór zależy od tego, co już masz i jak skomplikowany jest katalog. PrestaShop lepiej znosi tysiące SKU, kombinacje produktów i zaawansowane ceny. WooCommerce wygrywa, gdy liczy się prostota edycji treści i integracje z wtyczkami marketingowymi. Moduł piszemy pod strukturę, w której ma pracować — nie przenosimy jeden do jednego.

Czym różni się moduł od wtyczki?

To ta sama idea, inna nazwa i inna struktura kodu. W PrestaShop mówimy o module (katalog, klasa główna, plik konfiguracyjny XML), w WordPressie o wtyczce (plik główny z nagłówkiem, hooki, akcje i filtry). Skutek dla firmy jest identyczny: jedna funkcja, jedno miejsce do aktualizacji i jeden właściciel odpowiedzialny za kod.

Co z opieką po wdrożeniu?

Minimum to 30 dni gwarancji na błędy popełnione przy tworzeniu modułu. Sensowny standard to pakiet utrzymaniowy: aktualizacje kompatybilności, monitoring błędów w logach i reakcja w ciągu 4 godzin przy awarii blokującej sprzedaż. Bez tego każda aktualizacja sklepu staje się ryzykiem.

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

Lista kontrolna do odklikania

• Specyfikacja na piśmie — Przed startem prac. Sprawdź, czy opisuje proces, integracje i kryteria odbioru.
• Lista integracji — Przed wyceną. ERP, płatności, kurierzy, mailing to osobne zakresy i osobne testy.
• Środowisko testowe — Przed pierwszym wdrożeniem. Kopia bazy i plików, inne klucze API niż na produkcji.
• Repozytorium i dostępy — W pierwszym tygodniu. Kod w Git na firmowym koncie, nie na prywatnym FTP wykonawcy.
• Osoba decyzyjna po stronie firmy — Na starcie projektu. Bez niej każde pytanie wstrzymuje pracę o dni.
• Stawka i zakres godzinowy — Przed podpisaniem umowy. W Polsce doświadczony deweloper to zwykle 120–220 zł netto za godzinę.
• Scenariusze testowe — Przed odbiorem: ścieżka pozytywna, błędne dane, brak odpowiedzi API, duże obciążenie.
• Zgodność wersji — Przy każdej aktualizacji platformy. Sprawdź, na jakiej wersji PHP i PrestaShop lub WordPressa moduł był testowany.
• Powtarzalność operacji — Przy płatnościach i statusach przesyłek. Powtórzony webhook nie może dublować zamówienia. Podstawy protokołu: https://developer.mozilla.org/en-US/docs/Web/HTTP
• Dokumentacja i przekazanie praw — Przy odbiorze. README, lista hooków, informacja o licencji i prawach majątkowych.
• Kopie zapasowe — Przed każdym wdrożeniem i aktualizacją. Sprawdź, czy umiesz odtworzyć stan sprzed zmiany.
• Monitoring błędów — Po wdrożeniu. Logi błędów i alert przy nieudanej synchronizacji z ERP lub systemem płatności.
• Harmonogram przeglądów — Raz na kwartał. Aktualizacje, usuwanie nieużywanych wtyczek, kontrola licencji.
• Budżet na utrzymanie — Rocznie. Zaplanuj osobną pulę godzin na poprawki, aktualizacje i drobne zmiany w procesie.

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
• MDN Web Docs – HTTP
• PrestaShop – dokumentacja dla deweloperów