Zamówienie niestandardowego modułu nie zaczyna się od wyceny, a od opisu procesu, który ma działać w sklepie. Większość problemów przy wdrożeniu bierze się nie z kodu, tylko z niedomkniętych ustaleń: kto dostarcza dane, kto testuje, kto płaci za poprawki po zmianie PHP. Poniżej zebraliśmy błędy, które widzimy najczęściej, checklistę do przejścia przed podpisaniem umowy oraz odpowiedzi na pytania wracające przy każdym projekcie – także wtedy, gdy szukasz niestandardowych modułów i wtyczek Toruń i okolice. Szerszy materiał o organizacji pracy znajdziesz w tekście niestandardowe moduły i wtyczki: organizacja pracy.
Niestandardowy moduł (PrestaShop) albo wtyczka (WooCommerce) to kod dopisany do konkretnego sklepu, a nie produkt z katalogu. Różnica jest praktyczna: gotową wtyczkę wgrywasz jako ZIP i konfigurujesz w panelu, a moduł na zamówienie pisze się pod Twój proces – z własnym panelem, własnymi tabelami w bazie i własnymi regułami.
Technicznie w PrestaShop moduł to katalog w /modules/, plik główny z klasą dziedziczącą po Module i metodą install(), która rejestruje hooki. W WooCommerce wtyczka to katalog w /wp-content/plugins/ z nagłówkiem opisu i funkcjami podpiętymi przez add_action oraz add_filter. W obu wypadkach to kod, który zostaje na serwerze i trzeba go utrzymywać – razem z PHP, sklepem i szablonem.
Trzy przykłady z wdrożeń:
Trzy rzeczy łatwo pomylić. Modyfikacja szablonu (pliki .tpl, child theme) zmienia wygląd i układ, nie logikę procesu. Integracja API to wymiana danych z zewnętrznym systemem – bez panelu i bez reguł biznesowych. Override klasy w PrestaShop to nadpisanie pliku sklepu, nie osobny moduł – i to najczęstsze źródło problemów przy aktualizacjach. Szerszy materiał o organizacji pracy, umowie i testach znajdziesz w tekście niestandardowe moduły i wtyczki: organizacja pracy.
Zanim zamówisz kod, przejdź te pięć pytań. Odpowiedź „tak” przy którymkolwiek oznacza, że warto policzyć koszt modułu na zamówienie, a nie tylko licencji.
| Pytanie | Jeśli TAK | Jeśli NIE |
|---|---|---|
| Gotowa wtyczka pokrywa ok. 80% procesu | Kup licencję, zamów tylko brakujące 20% | Pisz moduł od zera |
| Proces jest specyficzny (rabaty, wysyłka, cenniki) | Własny moduł – gotowiec wymusi kompromis | Sprawdź najpierw gotowe rozwiązania |
| Licencja roczna > koszt modułu w 2–3 lata | Policz koszt na 3 lata, potem decyduj | Licencja wychodzi taniej |
| Dane klientów muszą zostać u Ciebie | Własny moduł albo wtyczka działająca lokalnie | SaaS wchodzi w grę |
| Wtyczka konfliktuje lub spowalnia sklep | Test na kopii, potem decyzja o własnym kodzie | Zostaw obecne rozwiązanie |
Różnica nie wychodzi przy wdrożeniu, tylko przy pierwszej aktualizacji sklepu, szablonu albo PHP.
PrestaShop. Moduł leży w /modules/nazwa/ z plikiem głównym i klasą extends Module. Sklep rozszerzasz przez hooki rejestrowane w install() – np. displayAdminOrder, actionOrderStatusPostUpdate, displayHeader. Drugi mechanizm to override, czyli kopia pliku klasy w /override/classes/. Override działa do momentu aktualizacji: gdy PrestaShop zmieni sygnaturę metody albo doda argument, kopia przestaje być zgodna i potrafi wyłożyć sklep błędem 500. Po przejściu z 1.7 na 8.x trzeba sprawdzić każdy override osobno. Zasada: moduł z hookami jest bezpieczniejszy, override i edycja plików core to problem przy każdej aktualizacji. Więcej o tym, jak prowadzimy wdrożenia na tej platformie, jest na stronie PrestaShop – moduły, aktualizacje, integracje.
WooCommerce. Wtyczka korzysta z add_action i add_filter – na przykład woocommerce_package_rates przy modyfikacji kosztów wysyłki czy woocommerce_order_status_completed przy zdarzeniach po opłaceniu. Tu największe ryzyko to zależności: wersja PHP i wersja WooCommerce. Konkretny przykład: HPOS (High-Performance Order Storage) przenosi zamówienia z wp_posts i wp_postmeta do dedykowanych tabel. Wtyczka, która czyta dane przez get_post_meta($order_id, '_billing_email'), po włączeniu HPOS zwróci puste wartości. Poprawnie jest używać $order->get_billing_email() i zadeklarować zgodność z HPOS.
PHP 8.1 i 8.2 wyłapują ostrzeżenia, które na 7.4 przechodziły niezauważone – dynamiczne właściwości, brakujące typy. Zapisz w umowie, na jakich wersjach PHP i sklepu moduł ma działać i jak długo wykonawca poprawia go po ich aktualizacji. 12 miesięcy to sensowny standard; 30 dni to za mało, bo wydania wychodzą kilka razy w roku. Szerszy kontekst znajdziesz w materiale o aplikacjach dedykowanych.
| Aspekt | Moduł PrestaShop | Wtyczka WooCommerce |
|---|---|---|
| Miejsce kodu | /modules/nazwa/ | /wp-content/plugins/nazwa/ |
| Mechanizm rozszerzeń | Hooki (registerHook), override klas | add_action, add_filter |
| Największe ryzyko | Override i edycja plików core | Zależność od wersji PHP i WooCommerce |
| Co się psuje po aktualizacji | Override zgodny ze starą sygnaturą metody | Odczyt zamówień z wp_postmeta przy HPOS |
| Bezpieczna praktyka | Logika w hookach, zero zmian w core | Deklaracja zgodności z HPOS, testy na kopii |
Wycena „na oko” to najczęstszy powód sporów przy odbiorze. Dlatego każdą rozmowę zaczynamy od przypisania pomysłu do jednej z trzech klas pracochłonności. Widełki poniżej to czas pracy jednego programisty znającego PrestaShop lub WooCommerce – bez godzin na analizę, testy po stronie klienta, szkolenie pracowników i samo wdrożenie na produkcję. To osobne pozycje w ofercie, a nie ukryty koszt.
Godziny, a nie stała kwota, bo tylko godziny da się porównać między dwiema ofertami. Jeśli wykonawca podaje jedną cenę bez listy założeń, całe ryzyko bierze na siebie i wkalkuluje w nią bufor – zwykle kilkadziesiąt procent więcej, niż gdyby zakres był doprecyzowany. Rozliczenie godzinowe bez limitu chroni z kolei wykonawcę, ale nie zamawiającego. Dlatego w umowie powinien znaleźć się maksymalny budżet oraz punkt kontrolny po etapie analizy (często 10–15% budżetu), po którym obie strony mogą się wycofać za niewielką kwotę. Zanim zamówisz moduł, sprawdź, czy nie wystarczy gotowe rozwiązanie – więcej o tym pisaliśmy w materiale o organizacji pracy przy niestandardowych modułach.
Budżet nie kończy się na wdrożeniu. Trzeba przyjąć roczny koszt utrzymania: nowe wydanie PHP (np. przejście z 8.1 na 8.3) potrafi wyłączyć moduł korzystający z przestarzałych funkcji, kurierzy i operatorzy płatności zmieniają API bez pytania o zgodę, a aktualizacja PrestaShop lub WooCommerce czasem zmienia sygnatury hooków. W praktyce przyjmij 10–20% wartości wdrożenia rocznie i podpisz umowę serwisową z określonym czasem reakcji. Bez tego pierwsza awaria integracji z kurierem oznacza przestój w wysyłce i faktury zrobione ręcznie.
| Typ modułu | Przykład | Orientacyjny czas pracy | Główne ryzyko |
|---|---|---|---|
| Prosty | Dodatkowe pole w koszyku, walidacja NIP, dopisek do zamówienia | 8–20 godzin | Zmiany w motywie, brak testów przypadków brzegowych |
| Średni | Własna logika dostawy, integracja z InPost lub DPD | 30–60 godzin | Brak obsługi błędów i logów po stronie API |
| Złożony | Konfigurator produktu, integracja z ERP po stronie sklepu | 80–200 godzin | Nieuregulowany zakres i dane po stronie ERP |
Zamówienie modułu to proces, a nie jeden mejl z wyceną. Poniżej kolejność, którą stosujemy w projektach aplikacji dedykowanych i która minimalizuje liczbę poprawek po odbiorze.
actionValidateOrder, displayShoppingCart; WooCommerce: woocommerce_checkout_create_order), jakie tabele tworzymy w bazie z własnym prefiksem, co trafia do panelu konfiguracji w adminie, a co zostaje na sztywno.Te siedem punktów widać już na etapie wyceny. Każdy z nich oznacza realny koszt po wdrożeniu – nie w przyszłym roku, a przy pierwszej aktualizacji.
functions.php motywu potomnego albo w pliku szablonu, pierwsza aktualizacja motywu skasuje logikę. Dane powinny trafiać do własnych tabel w bazie lub do meta, logika – do modułu.Jeśli szukasz niestandardowych modułów i wtyczek Toruń i okolice, te punkty warto omówić jeszcze przed podpisaniem umowy – więcej o samych wdrożeniach znajdziesz w sekcji PrestaShop.
Niestandardowy moduł to nie jednorazowa faktura, a początek stałej pracy. Pierwsza zasada brzmi: każda własna funkcja ma wersję i changelog. W praktyce oznacza to repozytorium Git, tagi w formacie semver (1.0.0, 1.4.2) i plik CHANGELOG.md z datą, opisem zmiany oraz numerem zgłoszenia. Bez tego po dwóch latach nikt – łącznie z autorem kodu – nie odtworzy, dlaczego w module jest wyjątek dla jednego przewoźnika albo dlaczego jeden produkt pomija walidację adresu.
Ryzyko nie jest teoretyczne. Wracają te same zdarzenia:
wp_posts i wp_postmeta, a PrestaShop zmienia sygnatury hooków między wersjami 1.6, 1.7 i 8;allow_url_fopen.Dlatego w umowie rozdziel dwa poziomy wsparcia. Błąd krytyczny (sklep nie przyjmuje zamówień, płatność nie wraca, panel nie działa) ma inny SLA niż drobna zmiana funkcjonalna (dodatkowa kolumna w eksporcie, nowy przycisk w panelu). Bez tego rozdzielenia każdy telefon „na cito” ląduje w tej samej kolejce. Przy integracjach warto też odróżniać kody odpowiedzi: 5xx oznacza problem po stronie usługi, 4xx po stronie zapytania – semantykę HTTP opisuje RFC 9110.
Rekomendacja: minimalny przegląd i aktualizacja modułu raz na kwartał oraz testy na kopii staging po każdej aktualizacji platformy, PHP albo wtyczek zewnętrznych. To kilka godzin pracy, które zwracają się przy pierwszym nieudanym upgradzie. Zasady przekazywania kodu i dokumentacji opisujemy przy okazji aplikacji dedykowanych, a kolejność prac nad własnymi funkcjami – w tekście o organizacji pracy z niestandardowymi modułami i wtyczkami.
| Typ zgłoszenia | Czas reakcji | Termin naprawy | Kanał zgłoszenia |
|---|---|---|---|
| Błąd krytyczny: brak zamówień, brak powrotu z płatności | 2 h w godzinach pracy | 24 h | telefon + e-mail |
| Błąd blokujący: nie działa eksport do ERP lub do kuriera | 1 dzień roboczy | 3 dni robocze | zgłoszenie w panelu |
| Mała zmiana funkcjonalna | 2 dni robocze | 5–10 dni roboczych | kolejka zmian |
| Zmiana po stronie zewnętrznego API | wg komunikatu dostawcy | do 5 dni roboczych |
Najczęstszy powód spadku pozycji po wdrożeniu własnego modułu nie ma nic wspólnego z bezpieczeństwem, a z jednym zapytaniem SQL w pętli. Reguła: kod odpalany w hooku display (PrestaShop: hookDisplayProductList, hookDisplayTop; WordPress: pre_get_posts, filtr woocommerce_product_query) musi być tani. Jeśli dla każdego z 24 produktów na stronie kategorii leci osobne zapytanie do wp_postmeta bez indeksu, TTFB potrafi wzrosnąć o kilkaset milisekund, a LCP przekracza próg 2,5 s.
Co zrobić w praktyce:
Cache::store w PrestaShopie, Redis lub Memcached na serwerze; unieważnianie po zmianie produktu, nie po sztywnym czasie;LIMIT/OFFSET na liście, a przy dziesiątkach tysięcy rekordów paginacja kluczowa po ID;EXPLAIN – typ ALL w kolumnie type to pełny skan tabeli;Po wdrożeniu porównaj dane sprzed i z 7–14 dni po: TTFB oraz LCP z PageSpeed Insights (pomiar laboratoryjny) i raport Core Web Vitals w Search Console (dane rzeczywiste, okno 28 dni). Sposób interpretacji tych metryk opisuje web.dev – Web Vitals.
Własny moduł potrafi też SEO pomóc i to najmocniej: przepisanie starych adresów z parametrami na czyste URL-e z mapowaniem 301, generowanie danych strukturalnych produktów (Offer, AggregateRating, BreadcrumbList), obsługa kanałów sprzedaży i feedów. Wtedy jedna funkcja robi więcej niż trzy wtyczki z katalogu. Przykłady takich wdrożeń zbieramy w materiale o niestandardowych modułach i wtyczkach dla firm, a specyfikę platformy opisuje nasza strona o PrestaShop.
| Co mierzysz | Narzędzie | Wartość docelowa | Kiedy porównujesz |
|---|---|---|---|
| TTFB | PageSpeed Insights, <code>curl -w</code>, logi serwera | poniżej 600 ms | przed wdrożeniem i 7–14 dni po |
| LCP | PageSpeed Insights, Search Console → Core Web Vitals | poniżej 2,5 s dla 75. percentyla | 28 dni po (dane rzeczywiste) |
| Liczba zapytań SQL na liście kategorii | Query Monitor, profiler PrestaShop, slow query log | brak zapytań w pętli szablonu | po każdym większym wdrożeniu |
| INP i CLS | PageSpeed Insights, dane z web.dev | INP poniżej 200 ms, CLS poniżej 0,1 | raz w miesiącu |
Fraza „niestandardowe moduły i wtyczki Toruń” ma sens tylko wtedy, gdy odpowiesz sobie na jedno pytanie: czego potrzebujesz bardziej – kontaktu osobistego czy wąskiej specjalizacji. Firma z Torunia daje spotkanie w ciągu 24 godzin, możliwość pokazania sklepu i procesu na miejscu, jedną fakturę i krótszą drogę eskalacji, gdy coś nie działa. Tracisz dostęp do kompetencji, których w jednym zespole po prostu nie ma: osoba od Elasticsearch, integracji z konkretnym ERP czy migracji na HPOS bywa poza zasięgiem firmy zatrudniającej trzy osoby. Drugie ryzyko: uzależnienie od jednej osoby, która w sierpniu jest na urlopie.
Praca zdalna wygrywa w trzech sytuacjach: potrzebujesz szybkiego środowiska testowego (gotowy staging z kopią bazy w 24–48 h), pracujesz w modelu godzinowym i chcesz porównać koszt etapu, potrzebujesz opieki z SLA po wdrożeniu, a nie „zadzwonimy, jak coś padnie”. Przy module łączącym się z API płatności odległość wykonawcy nie ma znaczenia technicznego – liczy się dostęp do logów i czas reakcji.
Zanim podpiszesz cokolwiek, zadaj cztery pytania, niezależnie od tego, czy wykonawca jest z Torunia, Bydgoszczy czy pracuje zdalnie:
Porządek w takich projektach – od opisu procesu do testów odbiorczych – rozkładamy w materiałach o niestandardowych modułach i wtyczkach Szczecin oraz o niestandardowych modułach i wtyczkach Krasnobród. Różnica między miastami sprowadza się do logistyki spotkań, nie do jakości kodu.
| Punkt do sprawdzenia | Dobry sygnał | Czerwona flaga |
|---|---|---|
| Kto pisze kod | Konkretne nazwisko lub zespół z podziałem ról | „nasz zespół deweloperów” bez nazwisk |
| Repozytorium | Git, dostęp dla Ciebie od pierwszego commita | Kod przekazany archiwum ZIP na koniec |
| Środowisko testowe | Osobny staging z kopią bazy i danych | Testy bezpośrednio na produkcji |
| Zakres i wycena | Podział na etapy z liczbą godzin | Jedna kwota bez zakresu i bez limitu poprawek |
| Wsparcie po wdrożeniu | SLA z czasem reakcji i naprawy w umowie | „zdzwonimy się, jak coś się stanie” |
| Prawa do kodu | Zapis w umowie, że kod i dokumentacja są Twoje | Brak zapisu, kod zostaje u wykonawcy |
| Testy odbiorcze | Lista scenariuszy i dane testowe od Ciebie | „u nas działa, u was też zadziała” |
Brief jako lista funkcji, a nie opis procesu
Jak wykryć: Dokument zaczyna się od zdań typu „dodaj przycisk” i „dorobić eksport”, a nie ma w nim informacji, kto, kiedy i na jakiej podstawie wykonuje daną czynność w firmie.
Jak naprawić: Zamień listę funkcji na opis procesu krok po kroku: kto zaczyna, jakie dane wpisuje, co ma się stać, gdy czegoś brakuje, kto odbiera efekt. Warsztat 60–90 minut z osobą, która realnie obsługuje ten proces, zwykle wystarcza.
Testy bezpośrednio na produkcji, bez środowiska testowego
Jak wykryć: Pierwsze uruchomienie modułu odbywa się w sklepie, w którym trwają zamówienia, i nie istnieje kopia bazy do przywrócenia.
Jak naprawić: Postaw staging z kopią bazy i szablonu, ustal termin testów i przenieś wdrożenie na produkcję dopiero po odbiorze. Sprawdź też, czy kopia bazy faktycznie daje się przywrócić – nie zakładaj tego na słowo.
Modyfikacja plików core i override klas zamiast hooków
Jak wykryć: W katalogu /override/ pojawiają się pliki klas, a zmiany nie są zapisane w repozytorium. Drugi sygnał: po aktualizacji sklepu funkcja przestaje działać bez śladu w logach.
Jak naprawić: Przenieś logikę do modułu i podłącz ją przez hooki. Jeżeli override jest naprawdę konieczny, zapisz go w repozytorium, opisz powód i zaplanuj przegląd przy każdej aktualizacji PrestaShop.
Brak ustalenia, kto utrzymuje moduł po wdrożeniu
Jak wykryć: W umowie nie ma ani jednego zdania o aktualizacjach PHP, WooCommerce, WordPressa, API kuriera czy bramki płatniczej. Nie ma też czasu reakcji na awarię.
Jak naprawić: Dopisz zakres utrzymania, czas reakcji, stawkę za godziny po okresie gwarancyjnym i sposób zgłaszania błędów. To jedno zdanie w umowie, a różnica między spokojem a telefonem w piątek o 22:00.
Zakup wtyczki z marketplace bez sprawdzenia konfliktów
Jak wykryć: Po instalacji sklep zwalnia, w konsoli przeglądarki i logach PHP pojawiają się błędy, a część funkcji koszyka przestaje działać poprawnie.
Jak naprawić: Testuj na stagingu i zmierz wydajność przed instalacją oraz po niej – punkt odniesienia dla metryk znajdziesz w web.dev – Web Vitals. Konflikt z jedną wtyczką potrafi kosztować więcej godzin niż napisanie własnego modułu.
Pominięcie zgodności z PHP 8.1+ i HPOS w WooCommerce
Jak wykryć: Po przełączeniu sklepu na nowszą wersję PHP albo po włączeniu HPOS zamówienia przestają pojawiać się w widokach modułu i w eksportach.
Jak naprawić: Ustal wersje docelowe przed startem prac i wymagaj testu na nich w ramach odbioru. Wersje środowiska zapisz w dokumentacji projektu, razem z datą ostatniego testu.
Niestandardowy moduł to projekt, a nie zakup z katalogu – im dokładniej opiszesz proces przed wyceną, tym mniej niespodzianek na produkcji. Najczęstsze problemy dotyczą organizacji, nie kodu: brak środowiska testowego, brak ustaleń o utrzymaniu, brief w formie listy funkcji. Przejdź checklistę przed podpisaniem umowy i zapisz w niej odpowiedzialności obu stron. Wtedy widełki godzinowe z oferty przestają być zgadywaniem, a stają się punktem odniesienia.
Prosty moduł, np. dodatkowe pole w koszyku z walidacją i zapisem, to orientacyjnie 8–20 godzin pracy. Moduł ze średnią logiką, na przykład własna strefa dostawy albo integracja z InPost lub DPD, to zwykle 30–60 godzin. Konfigurator produktu czy integracja z ERP po stronie sklepu to przedział 80–200 godzin. Do tego dolicz czas po stronie zamawiającego: dostępy, dane, testy i akceptacje.
To kwestia zapisów w umowie, więc nie zakładaj domyślnego rozwiązania. Zapytaj wprost przed startem prac, czy po zakończeniu projektu dostajesz repozytorium z kodem i możliwość rozwijania go przez inny zespół. Ustal też, czy przekazanie obejmuje dokumentację i konfigurację środowiska. Nie zostawiaj tej rozmowy na etap odbioru, kiedy budżet jest już zamknięty.
Zadaj trzy pytania: czy wtyczka pokrywa około 80% potrzeby, czy proces nie jest specyficzny dla twojej firmy i czy koszt licencji rocznej w perspektywie 2–3 lat nie przewyższy jednorazowego modułu. Jeśli po odpowiedziach widzisz, że połowę logiki trzeba dorobić obejściami, własny moduł wychodzi zwykle taniej w utrzymaniu. Więcej o układaniu takiej decyzji w proces opisaliśmy w materiale niestandardowe moduły i wtyczki: organizacja pracy.
Moduł podłączony hookami przeżywa aktualizację znacznie częściej niż zmiany w plikach core. Największe ryzyko to override klas oraz modyfikacje szablonu, które nie są zapisane w repozytorium. Dlatego przy każdym wdrożeniu warto zapisać, które hooki i pliki zostały zmienione. Praktykę po stronie PrestaShop opisujemy na stronie PrestaShop.
Nie zawsze, ale w większości przypadków trzeba napisać warstwę pośrednią: moduł w sklepie, który zbiera dane i wysyła je w formacie zrozumiałym dla ERP. Jeśli system ERP ma własne API po HTTP, praca sprowadza się do poprawnego składania żądań, obsługi błędów i ponawiania nieudanych operacji. Warto wtedy oprzeć się na jasnych zasadach protokołu, np. opisanych w RFC 9110 – HTTP Semantics, żeby uniknąć duplikowania zamówień przy ponowieniach. Szerszy kontekst znajdziesz w aplikacjach dedykowanych.
Test akceptacyjny powinien bazować na przypadkach z życia: konkretne zamówienie, konkretna strefa dostawy, produkt z nietypowym wymiarem, zamówienie z rabatem. Osoba odbierająca moduł musi móc przejść te przypadki sama, bez pomocy programisty. Wynik zapisz w formie listy: co sprawdzone, kiedy, na jakiej wersji środowiska.
Utrzymanie to głównie poprawki po zmianach poza twoją kontrolą: nowsze wersje PHP, aktualizacje WooCommerce lub PrestaShop, zmiany w API kurierów i bramek płatniczych. Koszt zależy od tego, ile takich punktów styku ma moduł – jeden to zwykle kilka godzin w roku, pięć potrafi oznaczać kilkanaście. Dlatego w umowie warto zapisać nie tylko stawkę, ale i to, kto monitoruje te zmiany.
Jeśli chcesz przejść przez taki projekt po kolei – od warsztatu wymagań, przez analizę techniczną, do wdrożenia i utrzymania – napisz do DropDigital. Powiemy wprost, co ma sens w twoim sklepie, a co lepiej zostawić na później.