Niestandardowe moduły i wtyczki Hrubieszów – co to właściwie jest?

Moduł w PrestaShop i wtyczka w WordPress to ten sam pomysł: paczka kodu, która dodaje funkcję do sklepu bez ruszania plików rdzenia. Różnice są techniczne i przekładają się na wycenę oraz na to, jak łatwo później zaktualizować sklep.

Moduł PrestaShop leży w katalogu /modules/nazwa_modulu/. Plik główny nazwa_modulu.php zawiera klasę dziedziczącą po Module. Funkcje podpina się hookami — displayHeader, actionCartSave, displayAdminOrder — a ustawienia zapisuje przez Configuration::updateValue(). Tabele tworzy się w metodzie install(). Dzięki temu moduł potrafi zmieniać logikę koszyka, cen i zamówień, nie tylko wygląd. Pełne API opisuje dokumentacja dla deweloperów PrestaShop.

Wtyczka WooCommerce to katalog /wp-content/plugins/, plik z nagłówkiem Plugin Name i funkcje podpinane przez add_action() oraz add_filter(). Zasięg jest podobny, ale WooCommerce opiera koszyk i ceny na meta danych i filtrach — nietypowa logika szybciej rozjeżdża się z kolejnymi wersjami WooCommerce.

Najczęstsze zastosowania w firmach z Hrubieszowa i okolic:

• indywidualne ceny B2B — cennik per klient, rabaty progowe, minimalna wartość zamówienia, limity kredytu;
• integracja z ERP (Subiekt, Comarch Optima, WF-Mag) — stany magazynowe, faktury, numeracja dokumentów;
• nietypowa wysyłka — kalkulacja palet, strefy, kilku kurierów w jednym koszyku.

Kiedy zostać przy gotowym? Gdy funkcja jest standardowa, wtyczka dostała aktualizację w ostatnich 3–6 miesiącach i kosztuje mniej niż 8 godzin pracy programisty. Custom ma sens, gdy gotowe rozwiązanie pokrywa mniej niż ~80% procesu, a resztę pracownik nadrabia ręcznie — na przykład przepisując zamówienia z maila do ERP. Więcej o układaniu pracy przed wyceną piszemy w tekście Niestandardowe moduły i wtyczki Lublin: organizacja pracy.

Gotowy moduł czy custom? Prosty test decyzyjny

Decyzję da się podjąć w kilkanaście minut, zanim zapłacisz za analizę. Policz trafienia po każdej stronie tabeli — nie musisz spełniać wszystkich warunków.

Ile kosztuje niestandardowy moduł lub wtyczka w 2025 roku?

Stawki rynkowe w Polsce w 2025 roku to 150–300 zł/h netto. Dolny przedział (150–200 zł/h) dotyczy prostszych zadań i mniej doświadczonych wykonawców, środek (200–250 zł/h) to standard dla sklepów na PrestaShop i WooCommerce, górna granica (250–300 zł/h) pojawia się, gdy potrzebna jest wąska specjalizacja: multistore w PrestaShop, integracja z Subiektem GT, rozliczenia księgowe albo praca na starym, nieudokumentowanym API.

PrestaShop vs WooCommerce – co inaczej się projektuje?

W PrestaShop moduł to katalog w /modules/ z plikiem głównym mojmodul.php, klasą dziedziczącą po Module, plikiem config.xml i szablonami .tpl. Zachowanie sklepu rozszerzasz przez hooki (hookDisplayHeader, actionValidateOrder, actionProductUpdate), a gdy hooka brakuje – przez override klasy w katalogu /override/. Override działa szybko, ale to dług techniczny: po aktualizacji sklepu nadpisana klasa może zniknąć albo zmienić sygnaturę metody. Panel konfiguracji piszesz ręcznie w getContent(), z walidacją i zapisem przez Configuration::updateValue().

W WooCommerce pracujesz na mechanizmie WordPressa: akcje (woocommerce_checkout_create_order) i filtry (woocommerce_get_price_html). Zamiast override nadpisujesz szablony w motywie potomnym w katalogu /woocommerce/ albo podpinasz się pod istniejące zdarzenie. Do wymiany danych z systemami zewnętrznymi służy REST API (/wp-json/wc/v3/) z kluczami consumer key i secret. Aktualizacje WooCommerce rzadziej łamią logikę, bo interfejs hooków jest stabilny, ale konflikty robią wtyczki nadpisujące te same szablony.

Wydajność projektuje się inaczej. PrestaShop generuje dużo zapytań przy listach kategorii – liczy się cache Smarty, indeksy w bazie i to, czy moduł nie odpytuje bazy w pętli. WooCommerce opiera się na WP_Query i transientach, a zadania w tle kieruj do Action Scheduler, nie do wp-cron.php, który odpala się tylko przy ruchu.

Wybór jest prosty. PrestaShop – gdy masz ceny B2B, wielosklep, kilka magazynów i chcesz rozszerzać logikę koszyka. WooCommerce – gdy sklep jest częścią serwisu na WordPressie, a integracje oprzesz na REST API. Zanim porównasz oferty, uporządkuj brief – pomoże materiał o niestandardowych modułach i wtyczkach w Lublinie, a realia mniejszych rynków opisuje tekst o niestandardowych modułach i wtyczkach w Biłgoraju. Szczegóły techniczne znajdziesz w dokumentacji deweloperskiej PrestaShop.

7 kroków wdrożenia niestandardowego modułu: od briefu do produkcji

Ten proces działa tak samo w PrestaShop i WooCommerce. Wykonawca, który go pomija, przenosi ryzyko na Ciebie.

1. Brief i kryteria akceptacji. Opisz jeden konkretny przypadek: klient B2B z rabatem 18% przy 200 sztukach, faktura odroczona 14 dni, wysyłka na dwa adresy. Kryterium musi być sprawdzalne – np. zamówienie 200 sztuk pokazuje cenę 82,00 zł netto za sztukę. Bez tego nie porównasz ofert.
2. Środowisko testowe i dane przykładowe. Kopia sklepu na subdomenie, wyłączona wysyłka maili, konto B2B z limitem kredytowym, produkty z różnymi stawkami VAT i jedną pozycją wycofaną z oferty.
3. Projekt techniczny i podział na etapy. Lista punktów styku z ERP i API, konkretne hooki, plan zmian w bazie. Etapy po 1–2 tygodnie, każdy z demem do obejrzenia.
4. Kod, code review i testy jednostkowe. Repozytorium Git, pull requesty, PHPUnit na logikę cen, rabatów i walidację NIP.
5. Testy integracyjne. Scenariusze z ERP, płatnościami i kurierami – także te błędne: brak towaru w magazynie, odrzucona płatność, timeout API kuriera w trakcie składania zamówienia.
6. Wdrożenie na produkcję. Backup bazy i plików, okno niskiego ruchu, przygotowany rollback i ustalone na piśmie, kto go uruchamia i kiedy.
7. Monitoring, dokumentacja i opieka. Log błędów z ID zamówienia, alert przy powtarzających się niepowodzeniach, instrukcja dla pracownika obsługi. Sprawdź też wpływ modułu na czas ładowania i Core Web Vitals – dokładanie zapytań w pętli potrafi zepsuć wyniki całego sklepu.

Kolejność jest ważniejsza niż narzędzia. Jeśli dopiero planujesz projekt, zobacz, jak wygląda organizacja pracy przy niestandardowych modułach i wtyczkach w Narolu oraz we wdrożeniach w Bełżcu.

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

Kurierzy (InPost, DPD, DHL). Gotowa wtyczka zwykle wystarcza do nadania paczki, ale nie do mapowania statusów. Problem pojawia się, gdy API zwraca 9 statusów, a w sklepie masz 4. Kolejna pułapka to etykiety: generowanie PDF dla przesyłki z pobraniem i niestandardowym gabarytem, a także zapis wybranego punktu odbioru jako osobnych pól zamówienia. Bez tego pracownik przepisuje dane ręcznie.

ERP (Subiekt, Comarch, SAP). Tu custom jest regułą. Zamówienia ze sklepu muszą trafić do ERP, a stany i ceny – wrócić. Najczęstsze błędy: brak identyfikatora korelacyjnego (nie wiadomo, które zamówienie już poszło), nadpisywanie ręcznie ustawionych cen przy każdej synchronizacji i blokada sklepu, gdy ERP nie odpowiada. Rozwiązanie to kolejka: zamówienie zapisuje się lokalnie, wysyłka idzie w tle, a nieudane pozycje wracają do ponowienia.

Płatności pod B2B. Standardowe bramki nie obsługują faktur odroczonych z limitem kredytowym, rat ani przelewu po walidacji NIP. Często trzeba dopisać własną metodę płatności, która sprawdza limit kontrahenta i blokuje zamówienie powyżej salda.

Obsługa awarii. Gdy API nie odpowiada, potrzebujesz ponowień z rosnącym opóźnieniem (np. 1, 5, 30 minut), logu z ID zamówienia i alertu po trzeciej nieudanej próbie. Klucze API trzymaj poza repozytorium – w zmiennych środowiskowych lub pliku poza katalogiem publicznym, z ograniczonymi uprawnieniami. Dokumentacja bramek i REST API jest w dokumentacji WooCommerce.

Zakres typowych prac zebrano w tabeli. Podobne zestawienia przygotowaliśmy dla niestandardowych modułów i wtyczek we Frampolu oraz dla firm z Józefowa.

Pułapki: vendor lock, brak aktualizacji, spadek wydajności i bezpieczeństwo

Najdroższe problemy nie pojawiają się w dniu wdrożenia, tylko 6–12 miesięcy później. Cztery scenariusze zdarzają się najczęściej.

Vendor lock. Kod trafia na serwer przez FTP, nie ma repozytorium ani dokumentacji. Skutek: żaden inny wykonawca nie podejmie się poprawki bez przepisania modułu od zera, a Ty nie możesz zmienić dostawcy. Prosty test: poproś o dostęp do repozytorium Git i sprawdź historię commitów. Jeśli słyszysz „kod jest na serwerze, tam pan zajrzy” — to lock. Schemat postępowania przy takich projektach opisaliśmy też przy okazji organizacji pracy przy niestandardowych modułach w Narolu.

Aktualizacja, po której moduł przestaje działać. Klasyka to override plików core w PrestaShop albo modyfikacja szablonu WooCommerce, która znika po aktualizacji motywu. Moduł chodził na PHP 7.4, po przejściu na PHP 8.2 leci błąd 500. Każdą aktualizację testuj na kopii (staging) z przywróconą bazą produkcyjną, nigdy bezpośrednio na produkcji.

Wydajność. Trzy najczęstsze grzechy: zapytania N+1 w pętli (lista 200 produktów = 200 zapytań do bazy), brak indeksów na kolumnach filtrowanych w tabelach modułu, brak cache dla powtarzalnych obliczeń. Efekt widać w Core Web Vitals — zamiast 1,2 s robi się 4 s.

Bezpieczeństwo. Nieparametryzowane zapytania SQL, dane z formularza wstawiane do HTML bez escapowania (XSS), brak walidacji pól w kontrolerze frontowym. Jeden zaniedbany formularz w module wystarczy, żeby wyciekła baza.

Jak to wykryć bez audytu za 10 tys. zł:

• logi serwera: error_log, slow query log — szukaj powtarzających się zapytań i błędów z tej samej ścieżki modułu,
• Query Monitor dla WooCommerce i Profiler w PrestaShop (tryb debug) — liczba zapytań i czas wykonania na podstronie,
• testy obciążeniowe na kopii bazy produkcyjnej — sprawdzasz katalog i koszyk, nie stronę główną,
• ręczny test formularzy: wpisz w pole kod znacznika skryptu i sprawdź, czy wraca niezescapowany.

Checklista przed zamówieniem modułu lub wtyczki

Ta lista działa jak brief. Odpowiedzi zapisz w jednym dokumencie, który obie strony akceptują przed startem prac — nie w mailach rozrzuconych po wątkach.

1. Zakres. Co moduł ma robić i czego nie robić. Przykład: „liczy cenę B2B od progu 500 zł netto, nie obsługuje rabatów łączonych, nie wysyła maili do klientów”. Lista „poza zakresem” chroni budżet lepiej niż klauzula o pracach dodatkowych.

2. Środowisko. Wersja PrestaShop lub WooCommerce, wersja PHP, MySQL/MariaDB, wersja motywu i lista aktywnych modułów. Bez tego wykonawca wycenia na oko, a po wdrożeniu wychodzą konflikty z trzema istniejącymi wtyczkami.

3. Własność kodu. Kto ma prawa autorskie i czy dostaniesz repozytorium Git z historią commitów. Wpisz wprost: przekazanie repozytorium i dostępów następuje przy odbiorze, po zapłacie faktury.

4. Aktualizacje. Co się dzieje przy nowej wersji platformy — jest okres wsparcia (np. 12 miesięcy od odbioru) czy każda aktualizacja to osobna wycena. Ustal, kto testuje zgodność i na jakim środowisku.

5. SLA i utrzymanie. Czas reakcji na zgłoszenie (np. 4 h w dni robocze, 24 h w weekend), czas naprawy, stawka godzinowa poza gwarancją, miesięczny abonament i jego zakres.

6. Backup, rollback, awaria. Kto robi kopię przed wdrożeniem, gdzie leży i w ile minut wracacie do poprzedniej wersji. Minimalny punkt rollback to kopia bazy plus kopia plików plus snapshot serwera.

Wersje i wymagania techniczne sprawdzaj w dokumentacji dla deweloperów PrestaShop, a nie w tym, co „kiedyś działało na innym sklepie”. Ten sam zestaw pytań stosujemy niezależnie od skali — zobacz, jak wygląda organizacja pracy przy modułach i wtyczkach w Biłgoraju.

Hrubieszów i okolice: jak wybrać wykonawcę i nie przepłacić

Praca zdalna czy lokalnie? Dla jakości kodu nie ma to znaczenia. Liczy się dostęp do repozytorium, środowisko testowe i kontakt z osobą, która faktycznie pisze moduł. Mit „musi być z miasta, bo wtedy przyjedzie” upada przy pierwszej pilnej aktualizacji: ktoś ma 3 dni na reakcję, dojazd zajmuje 2 godziny i nikt nie przyjeżdża.

Co ma realne znaczenie: rozmowa bezpośrednio z deweloperem, a nie przez handlowca. Każde przekazanie briefu przez pośrednika to kolejne miejsce, w którym ginie szczegół — „rabat od 500 zł” zamienia się w „rabat 500 zł”, a „wysyłka tylko kurierem” w „wysyłka według cennika”. Krótsza droga to jedna rozmowa techniczna, jeden dokument z zakresem i jedna osoba odpowiedzialna za wdrożenie.

Opieka po wdrożeniu: zamiast zapewnień „będziemy dzwonić i sprawdzać”, wpisz do umowy SLA z liczbami. Cztery pozycje wystarczą — czas reakcji, czas naprawy, kanał zgłoszeń (mail plus numer telefonu) oraz miesięczny abonament z listą tego, co jest w środku, a co płatne osobno.

Punkt odniesienia dla porównania ofert: zobacz, jak wygląda organizacja pracy przy niestandardowych modułach i wtyczkach w Lublinie, przy modułach i wtyczkach w Bełżcu oraz przy modułach i wtyczkach we Frampolu. Różnice dotyczą skali sklepu i długości listy integracji, nie samego procesu.

Praktyczna zasada na koniec: jeśli jedna oferta jest o 30–40% tańsza od pozostałych i nie zawiera repozytorium, środowiska staging ani SLA, tę różnicę dopłacisz przy pierwszej aktualizacji platformy.

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

Lista kontrolna do odklikania

• Jeden dokument z zakresem i kryteriami akceptacji — Sprawdź przed podpisaniem umowy: każda funkcja ma opisany efekt i sposób weryfikacji. Wzór porządkowania pracy opisaliśmy też dla Narola i okolic: https://dropdigital.pl/niestandardowe-moduly-i-wtyczki-narol-organizacja
• Lista integracji i ich API — Wypisz ERP, kurierów i płatności. Zweryfikuj, czy dostawca udostępnia dokumentację API oraz środowisko testowe — brak dokumentacji to główny powód dopłat.
• Wycena w godzinach, nie sztywna cena — Poproś o widełki min–max z listą założeń. Porównuj oferty na tej samej podstawie zakresu.
• Środowisko staging z przykładowymi danymi — Sprawdź, czy wykonawca ma staging i czy testy nie idą na produkcji. Zapytaj, jak wygląda kopiowanie danych z produkcji.
• Podział na etapy z terminami — Projekt techniczny i harmonogram powinny powstać przed pierwszym commitem, nie po nim.
• Repozytorium i prawa do kodu — Zapytaj o dostęp do Git i zapis o prawach w umowie. Sprawdź to przed startem prac, nie po odbiorze.
• Lista przypadków brzegowych — Zamówienie na 0 zł, z rabatem, wielowalutowe, z 30 pozycjami, z fakturą odroczoną — każdy przypadek przetestowany osobno.
• Plan wdrożenia z backupem i rollbackiem — Ustal datę i godzinę okna wdrożeniowego poza szczytem sprzedaży oraz osobę decyzyjną.
• Monitoring błędów i logi integracji — Sprawdź, czy błąd typu „brak odpowiedzi API kuriera” trafia do logów i alertu, a nie tylko do koszyka klienta.
• Sekrety poza repozytorium — Klucze API w zmiennych środowiskowych, ograniczone uprawnienia kont, rotacja. Zweryfikuj, co dokładnie jest w repo.
• Dokumentacja powdrożeniowa — Opis konfiguracji, hooków i miejsc w kodzie ma trafić w Twoje ręce, nie zostać w głowie wykonawcy.
• Opieka i czas reakcji na błędy — Ustal czas reakcji dla błędu krytycznego i zwykłego. Zapisz to w umowie lub osobnym dokumencie SLA.
• Test po każdej aktualizacji platformy — Po aktualizacji PrestaShop, WordPressa lub PHP przejdź ścieżkę: produkt, koszyk, płatność, etykieta, faktura.

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
• PrestaShop – dokumentacja dla deweloperów
• WooCommerce – dokumentacja