Czym są niestandardowe moduły i wtyczki w PrestaShop i WooCommerce?

Moduł w PrestaShop to katalog w /modules/ z głównym plikiem PHP (np. mojmodul.php), klasą dziedziczącą po Module i metodą install(), która zakłada tabele w bazie. Moduł rejestruje się na hookach — hookDisplayHeader, hookActionCartSave, hookDisplayProductExtraContent — i może dokładać własne kontrolery frontowe oraz szablony Smarty (.tpl). Wtyczka WooCommerce to plik PHP w /wp-content/plugins/ z nagłówkiem Plugin Name:, podpinający się do WordPressa przez add_action() i add_filter(), korzystający z REST API i własnych tabel przez $wpdb. W obu przypadkach to kod działający wewnątrz sklepu, a nie osobny serwis.

Funkcje, które najczęściej trafiają do customu:

• Konfigurator produktu — klient wybiera wymiary, kolor i materiał, a cena oraz termin realizacji liczą się na żywo. Bez tego każda konfiguracja idzie mailem.
• Indywidualny koszyk B2B — progi cenowe per klient, minimalna wartość zamówienia, zatwierdzanie przez opiekuna.
• Automatyczna wycena wysyłki — waga gabarytowa, strefy, cennik przewoźnika, darmowa dostawa od progu.
• Integracja z systemem magazynowym — stany, rezerwacje, zamówienia i faktury w obie strony (Subiekt, WMS, Comarch Optima).

Gotowa wtyczka przestaje wystarczać w czterech sytuacjach: proces jest nietypowy (np. dwa cenniki dla tego samego klienta zależnie od kanału), wtyczka uderza w limit API (np. 60 zapytań na minutę u przewoźnika, brak webhooków), brakuje wsparcia dla polskich integracji (krajowe systemy księgowe rzadko mają gotowe łączniki), brakuje hooka lub pola w bazie — a jedyne wyjście to nadpisanie plików wtyczki, które kasuje się przy pierwszej aktualizacji.

Na koniec rozróżnienie, które myli się najczęściej: moduł to nie szablon. Szablon (theme) odpowiada za wygląd i układ, moduł za logikę. To także nie to samo co integracja zewnętrzna — integracja to kontrakt z obcym systemem: mapowanie pól, obsługa błędów, limity. Można ją zrealizować w module, ale moduł może istnieć bez żadnej integracji. Strukturę modułów opisuje dokumentacja dla deweloperów PrestaShop.

Kiedy w Frampol i okolicach warto zamówić moduł na miarę?

Nie ma jednego progu, od którego trzeba pisać custom. W praktyce decyzję podejmuje się po pięciu sygnałach — jeśli widzisz u siebie trzy lub więcej, warto policzyć.

• Ręczna praca powtarzana codziennie. Przepisywanie zamówień z maila do ERP, wystawianie faktur ręcznie, kopiowanie numerów przesyłek. Policz: 20 zamówień × 4 minuty = 80 minut dziennie, czyli około 29 godzin miesięcznie.
• Brak dopasowania do procesu. Gotowa wtyczka narzuca swój scenariusz. Jeśli pracownicy obchodzą ją obejściami — notatkami w polu „uwagi”, arkuszem obok — proces jest inny niż zakładał autor wtyczki.
• Rosnące subskrypcje. Cztery wtyczki premium po 400 zł/rok plus dodatki to 2000–2500 zł rocznie i rośnie z każdą nową potrzebą.
• Limity gotowych wtyczek. Brak hooka, brak pola w bazie, brak eksportu w potrzebnym formacie. Część da się obejść przez override — do pierwszej aktualizacji.
• Potrzeba integracji z ERP. Subiekt, Comarch Optima, WF-Mag — gotowe łączniki są rzadkie i zwykle pokrywają tylko najprostszy scenariusz.

Przykład: hurtownia z okolic Frampola i Zamościa sprzedająca B2B. Ma 300 klientów, każdy z rabatem zależnym od grupy towarowej, a zamówienia powyżej 5000 zł netto wymagają zatwierdzenia przez opiekuna handlowego. Gotowy moduł B2B obsługuje jedną grupę rabatową i nie zna pojęcia zatwierdzania — handlowiec przelicza więc każdy koszyk ręcznie. Tu custom jest uzasadniony. Jak ułożyć taki projekt — kolejność prac, kto za co odpowiada, jak przekazać wymagania — opisujemy szerzej w materiale o niestandardowych modułach i wtyczkach Zamość: jak to zorganizować.

Zastrzeżenie: nie każdy problem wymaga customu. Czasem wystarczy konfiguracja — reguły cenowe katalogowe i koszyka w PrestaShop, grupy klientów, opcja w wtyczce premium, której nie zauważyłeś. Zanim zamówisz kod, sprawdź, czy problem jest w narzędziu, czy w procesie.

Gotowa wtyczka, moduł premium czy custom? Porównanie kosztów i ryzyk

Trzy warianty, trzy różne rachunki. Poniżej zestawienie oparte na projektach, które robimy na co dzień.

Widełki: prosta wtyczka premium to 200–600 zł/rok. Custom prosty (jedna funkcja, jeden ekran w panelu) to 2–4 tys. zł. Custom średni — kilka ekranów, logika ról, integracja — 5–10 tys. zł. Do customu dolicz utrzymanie: licz 10–20% wartości wdrożenia rocznie, jeśli chcesz mieć kogoś, kto reaguje na aktualizację PrestaShop czy WooCommerce.

TCO to nie tylko subskrypcje. Wliczasz cztery pozycje:

• czas programisty — wdrożenie, poprawki po aktualizacjach, drobne zmiany;
• koszt przestoju — godzina niedziałającego sklepu w szczycie sezonu to utracone zamówienia i telefony od klientów;
• koszt obejść — praca ręczna 2 h dziennie × 22 dni × 40 zł/h = 1760 zł miesięcznie;
• koszt konfliktów — wtyczka, która po aktualizacji wysypuje koszyk, kosztuje więcej niż jej licencja.

Rekomendacja jest prosta: custom ma sens, gdy oszczędza minimum kilka godzin pracy miesięcznie albo odblokowuje funkcję krytyczną dla sprzedaży — konfigurator, bez którego klient nie złoży zamówienia, albo integrację z ERP, która eliminuje ręczne przepisywanie. Jeśli oszczędność to 2 godziny miesięcznie, a wdrożenie kosztuje 6000 zł, zwrot liczysz w latach — wtedy lepiej zostać przy konfiguracji gotowych narzędzi. Przy wdrożeniu połączonym z migracją sklepu warto zaplanować jedno i drugie razem; kolejność prac opisujemy w materiale o wdrożeniach i migracjach PrestaShop Frampol.

Jak przebiega wdrożenie niestandardowego modułu – 7 kroków

Wdrożenie customu nie musi być czarną skrzynką. Proces jest przewidywalny, bo każdy krok kończy się plikiem, decyzją albo działającą funkcją.

1. Analiza i brief (2–5 dni). Zbieramy: kto używa modułu, jakie dane wchodzą i wychodzą, co ma się stać przy błędzie, jak dziś wygląda praca ręczna. Wynik to dokument na 2–4 strony z listą funkcji i przykładami realnych zamówień lub produktów.
2. Wycena godzinowa. Brief rozbijamy na zadania i podajemy liczbę godzin z widełkami. Widać osobno koszt panelu administracyjnego, osobno integracji.
3. Prototyp. Dla modułów z własnym interfejsem robimy klikalny szkic albo działający widok listy w panelu. Poprawienie makiety zajmuje godzinę, poprawienie gotowego kodu po trzech tygodniach — kilka dni.
4. Development. Kod w repozytorium Git, osobna gałąź, commity powiązane z zadaniami. PrestaShop: katalog /modules/, WordPress: /wp-content/plugins/.
5. Testy na staging. Środowisko testowe to warunek, nie opcja. Testujemy na kopii bazy produkcyjnej, nigdy na żywym sklepie.
6. Wdrożenie produkcyjne. Zawsze poprzedzone kopią plików i bazy. Okno wdrożeniowe poza szczytem zamówień, nie w poniedziałek rano.
7. Szkolenie i dokumentacja. Krótki opis: co robi moduł, gdzie się go konfiguruje, co zrobić przy błędzie. Dodatkowo nagranie 5–10 minut.

Prosty lub średni moduł to zwykle 2–6 tygodni. Integracje z ERP albo kilkoma kurierami wydłużają ten czas, bo dochodzą zależności po stronie systemów zewnętrznych, na które nie mamy wpływu. Jeśli pracujesz na PrestaShop, praktyczne tło znajdziesz w materiale o wdrożeniach i migracjach PrestaShop Frampol.

Wycena niestandardowych modułów i wtyczek: od czego zależą koszty?

Najczęstsze pytanie brzmi: ile to kosztuje? Uczciwa odpowiedź: tyle, ile godzin pracy. Stawka za pracę programisty nad modułem PrestaShop lub wtyczką WordPress w Polsce to 120–250 zł netto za godzinę. Dolna granica dotyczy prostych zadań, górna — integracji i architektury, którą trzeba najpierw przemyśleć.

Liczba godzin zależy przede wszystkim od zakresu:

• prosty moduł — 20–40 h: jedna funkcja, prosty widok w panelu, bez zewnętrznych API,
• średni moduł — 50–120 h: własna logika biznesowa, panel z filtrami, jedna lub dwie integracje,
• rozbudowany moduł — 120–250 h i więcej: wiele integracji, synchronizacja dwukierunkowa, import danych, wielojęzyczność.

Co konkretnie podnosi koszt: liczba integracji (każda ma własną dokumentację, limity i swoje błędy), logika biznesowa (rabaty warunkowe, ceny zależne od klienta, nietypowe stany magazynowe), panel administracyjny (eksporty, uprawnienia, filtry), import danych (CSV, XML, API) oraz wielojęzyczność z wielowalutowością.

Zasada: wycena na podstawie liczby godzin, z rozbiciem na pozycje. Bez cennika „moduł od 2000 zł” i bez kosztów dopisywanych po fakcie. Jeśli w trakcie wychodzi coś spoza zakresu, dostajesz informację i decyzję: rozszerzamy czy nie. Taki sposób wyceny wymusza porządek w briefie — więcej o tym w materiale o organizacji pracy przy niestandardowych modułach w Zamościu.

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

Trzy obszary generują najwięcej niestandardowych modułów: kurierzy, płatności i ERP.

Kurierzy: InPost, DPD, DHL. Zakres to generowanie etykiety z panelu zamówienia, zwrot numeru przesyłki, aktualizacja statusu z webhooków lub zapytań cyklicznych i mapowanie usług (paczkomat, kurier, przesyłka pobraniowa). Pułapka: mapowanie własnych metod dostawy na usługi kuriera. Jeśli w sklepie masz 12 metod, a kurier przyjmuje 6 kodów, ktoś musi ustalić mapę. Bez tego etykieta nie wyjdzie, dopiero przy konkretnym zamówieniu.

Płatności: Przelewy24, PayU, BLIK. Sama bramka to najczęściej wtyczka z rynku. Custom startuje przy nietypowej kolejności zdarzeń: rezerwacja stanu przed potwierdzeniem, częściowe zwroty, łączenie zamówień, własne statusy po webhooku. Webhook bez obsługi ponowień to gubione zamówienia. Jeśli ten sam webhook przyjdzie dwa razy, moduł musi być idempotentny — inaczej zdublujesz status albo wysyłkę.

ERP: Subiekt, Comarch Optima, ERPNext. Mapowanie pól to około 20% pracy. Reszta to synchronizacja stanów, kolejki i ponowienia, gdy ERP jest niedostępny, oraz obsługa konfliktów, gdy produkt zmienił się po obu stronach. Synchronizacja „na żądanie” przy 2000 zamówień miesięcznie przestaje działać — potrzebny harmonogram i log.

Wspólny wymóg: log każdego wywołania i alert przy błędzie. Bez tego nie wiadomo, ile zamówień nie dotarło. Przy PrestaShop punkty zaczepienia opisuje dokumentacja dla deweloperów PrestaShop — warto zajrzeć przed pisaniem briefu.

Bezpieczeństwo, wydajność i pułapki utrzymania modułów

Każdy niestandardowy moduł to kod, który ktoś musi utrzymywać także trzy lata po wdrożeniu. WordPress wypuszcza duże wersje kilka razy w roku, PrestaShop regularnie aktualizuje linie 1.7 i 8.x, a hostingi podnoszą wersje PHP automatycznie. PHP 8.1 traci wsparcie bezpieczeństwa z końcem 2025 r. Moduł korzystający z funkcji usuniętej z nowszego PHP nie padnie w dniu wdrożenia, tylko w dniu aktualizacji serwera — zwykle w środku sezonu.

Konflikty z innymi wtyczkami najczęściej wychodzą po dołożeniu kolejnej wtyczki, nie od razu. Dwie wtyczki podpinają się pod ten sam hook, nadpisują ten sam szablon albo ładują różne wersje tej samej biblioteki JS. Metoda jest jedna: pełna kopia na staging (pliki i baza), wyłączanie wtyczek po jednej i sprawdzenie, po której znika problem. W WordPressie włącz WP_DEBUG i WP_DEBUG_LOG, w PrestaShop _PS_MODE_DEV_ — komunikaty błędów PHP lądują w debug.log i katalogu /var/logs, nie na ekranie.

• Walidacja wejścia: każde pole formularza, parametr URL i dane z API sprawdzaj przed użyciem — typ, długość, dozwolone znaki.
• Baza: zapytania przez prepared statements (w PrestaShop Db::getInstance() z parametrami), nigdy przez sklejanie stringów — to najkrótsza droga do SQL injection.
• Wyjście: escapuj dane przed wyświetleniem (esc_html, esc_attr w WP, htmlspecialchars w PHP), inaczej wstrzyknięty skrypt wykona się w przeglądarce klienta (XSS).
• Uprawnienia: konto integracyjne do API ma dostęp tylko do potrzebnych zasobów; w WP sprawdzaj current_user_can i nonce, w PrestaShop tokeny CSRF.
• Backupy: pliki i baza przed każdą aktualizacją, plus test odtworzenia raz na kwartał. Backup, którego nie umiesz przywrócić, nie jest backupem.
• Monitoring: alerty na błędy 500, skoki 404, wolne zapytania (slow query log, Query Monitor w WP) i czasy odpowiedzi.

Budżet utrzymania policz od razu, przed podpisaniem umowy: przy prostym module to kilka godzin rocznie na aktualizacje i przegląd logów, przy integracji z zewnętrznym API więcej — dostawca potrafi zmienić format odpowiedzi bez ostrzeżenia. Część tych ryzyk pokrywa się z tym, co opisujemy przy okazji wdrożeń i migracji PrestaShop we Frampolu. Jeśli chcesz ocenić, czy wykonawca pracuje na natywnych mechanizmach, czy nadpisuje rdzeń, punktem startu jest dokumentacja deweloperska PrestaShop.

Lista kontrolna przed zamówieniem i po odbiorze modułu

Zamówienie modułu bez briefu kończy się zwykle modułem, który prawie robi to, o co chodziło. Brief nie musi mieć 20 stron: opis procesu krok po kroku, przykładowe dane wejściowe i kryteria akceptacji. Co konkretnie ma się stać, gdy stan magazynowy spadnie poniżej 5 sztuk? Kto dostaje maila? Co widzi pracownik, gdy integracja nie odpowiada? To zdania, które później rozstrzygają spór o odbiór.

Przed podpisaniem umowy ustal dwie rzeczy: kto jest właścicielem kodu i jak wygląda wyjście z współpracy. Kod bez szyfrowania (ionCube, Zend) w repozytorium Git, do którego masz dostęp, plus dokumentacja techniczna: struktura plików, hooki, tabele w bazie, wymagane wersje PHP i bibliotek.

• Testy na staging na kopii danych produkcyjnych, zanonimizowanych — nie na produkcji i nie tylko na scenariuszu szczęśliwej ścieżki.
• Plan wdrożenia i wycofania: kto wdraża, o której godzinie, jaki jest punkt przywrócenia i ile trwa rollback.
• SLA i czas reakcji w godzinach roboczych, z podziałem na błąd blokujący i drobną poprawkę.
• Szkolenie i przekazanie wiedzy: nagranie z instruktażu, krótki opis w panelu, kontakt do osoby, która zna kod.

Po odbiorze sprawdź, czy moduł działa po wyłączeniu innej wtyczki, czy logi są czytelne i czy dokumentacja zgadza się ze stanem repozytorium. Kolejność prac wokół takich wdrożeń, razem z podziałem na etapy, opisujemy w materiale o porządku pracy przy niestandardowych modułach i wtyczkach.

Ile trwa i jak wygląda opieka po wdrożeniu w DropDigital?

Na pytanie ile trwa wdrożenie nie ma jednej odpowiedzi bez liczby godzin. Dlatego wyceniamy w godzinach, a nie w dniach: termin to liczba godzin podzielona przez dostępność zespołu, plus czas po Twojej stronie — akceptacja zakresu, dane testowe, decyzje o tym, co ma się dziać przy błędzie. Jeśli brief jest gotowy, pierwszy działający prototyp niestandardowego modułu zwykle można obejrzeć przed zakończeniem całości, a nie dopiero na koniec.

Opieka po wdrożeniu działa w modelu pakietów godzinowych: kupujesz blok godzin i wykorzystujesz go na aktualizacje, poprawki i rozwój funkcji. Konkretny wariant — czy niewykorzystane godziny przechodzą na kolejny okres — ustalamy w umowie, razem z SLA i czasem reakcji liczonym w godzinach roboczych (poniedziałek–piątek). Zgłoszenie trafia bezpośrednio do dewelopera, który pisał moduł: bez pośredników i bez przepisywania zgłoszenia przez kolejne osoby.

Działamy z Zamościa i Lublina, obsługujemy też Frampol i okolice — praca zdalna działa tak samo dobrze jak dojazd, a przy projektach z integracjami chętnie spotykamy się na miejscu na etapie analizy. Niestandardowe moduły i wtyczki we Frampolu zamawia się zwykle wtedy, gdy proces jest nietypowy, a ludzie robią te same rzeczy ręcznie — dlatego zaczynamy od bezpłatnej wstępnej analizy potrzeb i wstępnej wyceny w godzinach. Napisz do nas, opisz proces i wskaż, co dziś robisz ręcznie; wycenę dostaniesz przed pierwszym commitem.

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

Lista kontrolna do odklikania

• Opisany proces krok po kroku — Sprawdź przed briefem: jeśli proces da się opisać w 10 krokach, wykonawca policzy godziny realnie, a nie zgadując.
• Policzony czas ręcznej pracy — Przez tydzień zapisuj, ile minut dziennie zajmuje powtarzalna czynność. Dopiero liczba godzin miesięcznie daje argument za customem.
• Lista integracji zewnętrznych — Wypisz systemy magazynowe, ERP, księgowość, kurierów i bramki płatnicze. Każda integracja to osobny zakres prac i osobne ryzyko.
• Limity API dostawców — Sprawdź w dokumentacji, ile zapytań na godzinę pozwala API. Limit potrafi wykluczyć część gotowych wtyczek jeszcze przed wyceną.
• Środowisko testowe gotowe — Przed startem prac: staging z aktualną kopią bazy, oddzielne klucze API i możliwość wycofania zmian.
• Kopia zapasowa i plan rollback — Weryfikuj przed każdym wdrożeniem produkcyjnym. Plan wycofania to nie formalność — skraca przestój z godzin do minut.
• Zakres wyceniony w godzinach — Wycena powinna rozbijać pracę na etapy z liczbą godzin. Brak rozbicia utrudnia późniejsze rozliczenie zmian zakresu.
• Kryteria akceptacji testów — Ustal przed developmentem, co dokładnie uznajesz za działający moduł: scenariusze zakupowe, progi cenowe, raporty.
• Panel administracyjny pod kontrolą klienta — Sprawdź, czy ustawienia modułu da się zmieniać bez programisty — to jedna z najczęstszych ukrytych oszczędności.
• Dokumentacja i szkolenie — Przy odbiorze: krótki opis instalacji, lista zależności i 30–60 minut szkolenia dla osób obsługujących sklep.
• Dostęp do repozytorium — Sprawdź, czy kod jest w repozytorium należącym do Ciebie, a nie tylko na serwerze wykonawcy.
• Roczny budżet na utrzymanie — Zaplanuj z wyprzedzeniem kwotę na aktualizacje po nowych wersjach platformy i na drobne zmiany w module.

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