Moduły PrestaShop: darmowe, płatne czy pisane na zamówienie

Moduły to największa siła PrestaShop i jego największe źródło problemów. Siła, bo niemal każdą funkcję da się dodać bez pisania kodu. Źródło problemów, bo po trzech latach sklep ma pięćdziesiąt modułów od trzydziestu autorów, połowa nie ma aktualizacji, a kilka nadpisuje te same pliki rdzenia. Ten tekst pomaga podjąć decyzję przed zakupem: darmowy, płatny czy napisany pod Twój sklep.

W skrócie

Zanim kupisz moduł, sprawdź, czy tej funkcji nie ma w samym PrestaShop. Grupy klientów, reguły koszyka, cechy i warianty załatwiają więcej, niż się wydaje.
Gotowy moduł wystarcza, gdy robi jedną rzecz, ma aktywnego autora i nie nadpisuje rdzenia.
Moduł dedykowany ma sens przy integracjach z ERP, cennikach B2B i funkcjach, które są przewagą Twojego sklepu nad konkurencją.
Nadpisywanie plików rdzenia to nie jest moduł. To dług, który spłacasz przy każdej aktualizacji.

Najpierw sprawdź, co już masz

Zaskakująco dużo modułów kupuje się po to, żeby dostać funkcję, którą PrestaShop ma w standardzie. Grupy klientów z osobnymi cenami, progi ilościowe, reguły koszyka z warunkami, darmowa dostawa od kwoty, cechy produktów do filtrowania, multistore, wiele walut i języków. Zanim zapłacisz, poświęć godzinę na przejrzenie panelu albo zapytaj kogoś, kto pracuje z PrestaShop na co dzień. Każdy moduł, którego nie zainstalujesz, to jeden mniej do aktualizowania.

Trzy rodzaje modułów i kiedy który

Rodzaj	Zalety	Ryzyka	Kiedy ma sens
Darmowy	Brak kosztu, często od operatora usługi (płatności, kurier)	Różna jakość kodu, wsparcie zależne od dobrej woli, czasem porzucony	Bramki płatności i kurierzy od samych operatorów, proste narzędzia
Płatny gotowy	Sprawdzony na setkach sklepów, dokumentacja, wsparcie w cenie	Robi więcej, niż potrzebujesz, roczna opłata za aktualizacje, konflikty z innymi modułami	Funkcje typowe dla każdego sklepu: filtry, menu, importy, faktury, opinie
Dedykowany	Robi dokładnie to, co trzeba, jeden wykonawca zna cały kod, bez zbędnych funkcji	Wyższy koszt na start, zależność od wykonawcy	Integracje z ERP, cenniki B2B, nietypowe procesy, przewaga nad konkurencją

Kiedy gotowy moduł wystarcza

Gotowy moduł to dobry wybór, gdy problem jest typowy. Potrzebujesz filtrów w kategorii, rozwijanego menu, importu z pliku CSV, opinii o produktach. Setki sklepów mają ten sam problem, więc autor miał czas, żeby wygładzić moduł na cudzych błędach. Przed zakupem sprawdź pięć rzeczy.

Datę ostatniej aktualizacji i zgodność z Twoją wersją PrestaShop i PHP. Moduł bez aktualizacji od dwu lat jest porzucony, nawet jeśli nadal jest w sprzedaży.
Czy używa hooków, czy nadpisań. W opisie lub w dokumentacji autor zwykle to podaje. Jeśli nie, zapytaj. Moduł z nadpisaniami klas rdzenia będzie problemem przy aktualizacji.
Opinie o wsparciu, nie o funkcjach. Każdy moduł działa w dniu instalacji. Liczy się, co się dzieje, gdy nie działa.
Ile ładuje na stronie. Moduł do opinii nie powinien dokładać trzech bibliotek na stronę główną. Sprawdź na wersji demo w narzędziach przeglądarki.
Co się dzieje po roku. Czy moduł działa bez przedłużenia licencji, czy tylko traci aktualizacje, czy przestaje działać wcale.

Kiedy gotowy moduł psuje sklep

Widzimy to przy niemal każdym audycie. Trzy moduły nadpisują tę samą klasę koszyka, więc działa tylko ten zainstalowany ostatni, a dwa pozostałe „czasem nie liczą rabatu”. Moduł do SEO i moduł do przekierowań walczą o te same adresy. Moduł z marketplace ładuje własną wersję jQuery, która psuje slider z szablonu. Każdy z tych modułów z osobna działał.

Konflikty nadpisań. Dwa moduły zmieniają ten sam plik rdzenia. PrestaShop próbuje je połączyć, ale nie zawsze się udaje.
Nakładające się funkcje. Dwa moduły do opinii, trzy do banerów, dwa do cache. Każdy ładuje swoje skrypty.
Zbyt wiele funkcji. Moduł „wszystko do SEO” robi 40 rzeczy, z czego używasz trzech, ale wszystkie 40 działają na każdej stronie.
Zależność od zewnętrznych serwerów. Moduł sprawdza licencję u autora przy każdym wejściu. Gdy serwer autora pada, sklep zwalnia albo wyświetla błąd.
Brak odinstalowania. Moduł zostawia w bazie tabele, w szablonie hooki, a w rdzeniu nadpisania. Po usunięciu sklep działa inaczej niż przed instalacją.

Uwaga

Instalowanie modułu „na próbę” na sklepie produkcyjnym to częsta przyczyna awarii. Moduł przy instalacji zmienia bazę i pliki, a jego odinstalowanie nie zawsze przywraca stan poprzedni. Testuj na kopii, zawsze.

Czym jest moduł dedykowany

Moduł dedykowany to moduł napisany pod jeden sklep, dla jednego klienta, do jednego zadania. Technicznie wygląda jak każdy inny moduł PrestaShop: osobny katalog, własny plik główny, własne tabele w bazie z przedrostkiem, własna konfiguracja w panelu. Różnica jest w zakresie. Robi dokładnie to, czego potrzebujesz, i nic więcej.

Jak powstaje

Krok po kroku

Opis procesu. Spisujemy, co moduł ma robić, słowami z Twojej firmy: „pracownik magazynu skanuje kod, sklep zmienia status i wysyła mail”. Bez technicznego żargonu.
Projekt techniczny. Które hooki PrestaShop wykorzystamy, jakie tabele dodamy, jak moduł zachowa się przy aktualizacji sklepu. Zasada: zero zmian w plikach rdzenia.
Wersja robocza na kopii. Moduł działa na środowisku testowym, Ty klikasz i zgłaszasz uwagi.
Dziennik i powiadomienia. Każdy moduł integracyjny ma własny dziennik operacji w panelu i wysyła powiadomienie, gdy coś nie działa dłużej niż ustalony czas.
Dokumentacja i przekazanie. Opis konfiguracji, kod w repozytorium, do którego masz dostęp. Moduł jest Twój, nie nasz.

Kiedy się opłaca

Moduł dedykowany ma sens, gdy gotowe rozwiązania wymagają dopasowywania Twojej firmy do modułu zamiast odwrotnie. Typowe przypadki: integracja z Subiektem, Optimą czy enovą z nietypowym obiegiem dokumentów, cennik B2B z indywidualnymi warunkami i limitami kupieckimi, kalkulator produktu na wymiar, obsługa kompletów z liczeniem stanu składników, połączenie z systemem OMS lub WMS. Czyli wszystko, co jest specyficzne dla Ciebie i daje przewagę nad konkurencją. Więcej przykładów na stronie o modułach PrestaShop.

Z naszej praktyki

Hurtownia elektrotechniczna używała trzech gotowych modułów do cen B2B: jednego do progów ilościowych, drugiego do cen indywidualnych, trzeciego do ukrywania cen przed niezalogowanymi. Każdy nadpisywał klasę produktu. Po aktualizacji jednego z nich ceny indywidualne przestały działać dla części klientów, a nikt tego nie zauważył przez trzy tygodnie. Napisaliśmy jeden moduł, który robi te trzy rzeczy na hookach, bez nadpisań. Sklep stracił dwa pliki w katalogu override, a aktualizacja do 9 przeszła bez poprawek w tym obszarze.

Nadpisywanie plików rdzenia: dlaczego nie

PrestaShop ma mechanizm override: możesz skopiować klasę lub kontroler rdzenia do katalogu override i zmienić w nim, co chcesz. Działa od razu i kusi, bo jest szybkie. Problemy przychodzą później. Przy każdej aktualizacji oryginalny plik się zmienia, a Twoja kopia zostaje stara. Dwa moduły nadpisujące tę samą klasę wykluczają się. Po trzech latach nikt nie pamięta, po co nadpisanie powstało, a usunięcie go psuje coś, czego nikt nie przewidział.

Jeszcze gorsze jest edytowanie plików rdzenia bezpośrednio, bez katalogu override. Taki sklep nie da się zaktualizować bez ręcznego porównywania setek plików. Jeśli wykonawca proponuje „małą zmianę w rdzeniu, bo tak szybciej”, odpowiedź powinna brzmieć nie. Niemal wszystko da się zrobić hookiem, a jeśli naprawdę się nie da, nadpisanie powinno być w module, udokumentowane i jak najmniejsze.

Dobry moduł można odinstalować i sklep wraca do stanu sprzed instalacji. Jeśli nie można, to nie był moduł, tylko przeróbka sklepu.

Porządek w modułach: jak go utrzymać

Raz na kwartał przejrzyj listę modułów i odinstaluj te, których nikt nie używa.
Prowadź listę: moduł, po co jest, kto jest autorem, do kiedy licencja.
Nie instaluj nic na produkcji bez testu na kopii.
Pilnuj, żeby katalog override był pusty albo zawierał tylko to, co jest opisane i konieczne.
Przy każdym nowym module zapytaj: czy można to zrobić w PrestaShop bez modułu, czy można to dołożyć do modułu, który już mamy.

Pytania, które słyszymy najczęściej

Czy moduł dedykowany będzie działał po aktualizacji PrestaShop?

Tak, jeśli jest napisany na hookach, bez nadpisań, i jeśli wykonawca sprawdzi go przy każdej większej aktualizacji. Moduły, które piszemy, aktualizujemy w ramach opieki nad sklepem.

Czy mogę zlecić zmianę w cudzym module?

Technicznie tak, ale po następnej aktualizacji autora Twoje zmiany znikną. Lepiej napisać mały moduł, który zmienia zachowanie tamtego przez hooki, albo poprosić autora o funkcję.

Darmowy moduł płatności od operatora czy płatny od innego autora?

Zwykle moduł od operatora, bo on odpowiada za zgodność z własnym API i aktualizuje go przy każdej zmianie. Płatny moduł zewnętrzny ma sens, gdy łączy kilku operatorów w jednym panelu.

Kto jest właścicielem kodu modułu dedykowanego?

Ty. Kod trafia do repozytorium, do którego masz dostęp, razem z dokumentacją. Możesz go przekazać innemu wykonawcy w każdej chwili.

Masz w sklepie funkcję, której żaden gotowy moduł nie robi dobrze? Opisz, co ma się dziać, a powiemy, czy wystarczy konfiguracja, gotowy moduł czy warto napisać własny. Zobacz, jakie moduły piszemy.

Zapytaj o moduł do sklepu