Sklep PrestaShop można dostosować na czterech poziomach: ustawieniami w panelu, motywem (najlepiej potomnym), własnym modułem z hookami albo nadpisaniem klas (override). Im niżej schodzisz, tym większa kontrola, ale też większe ryzyko, że zmiana przestanie działać po aktualizacji. Zasada jest prosta: wybieraj najwyższy poziom, który rozwiązuje problem, a override zostaw na koniec. Poniżej opisujemy każdy poziom, kiedy go użyć i na co uważać w PrestaShop 9.
Poziom 1: ustawienia i konfiguracja w panelu
Zanim zlecisz programowanie, sprawdź, czy potrzebna zmiana nie jest dostępna w panelu administracyjnym: grupy klientów i ceny, reguły koszyka, dostawa, podatki, struktura kategorii, atrybuty produktów. To najtańsze i najbezpieczniejsze dostosowanie, które nie wpływa na kod ani aktualizacje.
Poziom 2: motyw i motyw potomny
Wygląd sklepu zmieniasz w motywie. PrestaShop 9 działa na Symfony 6.4 i obsługuje PHP 8.1–8.4. Domyślnie nadal oferowany jest motyw Classic, a Hummingbird (oparty na Bootstrap 5) jest motywem referencyjnym, na którym można budować własne rozwiązania.
- Motyw potomny (child theme): przy drobnych zmianach to najłatwiejszy w utrzymaniu wybór. Zmieniasz tylko wybrane szablony, a resztę dziedziczysz z motywu bazowego, więc łatwiej przejąć jego aktualizacje.
- Własny motyw na bazie Hummingbird: sklonowany motyw budowany przez npm (
npm ci,npm run build). Szablony Smarty nadpisujesz przez dziedziczenie bloków, a nie kopiowanie całych plików. Dokumentacja zaleca też najpierw sprawdzić, czy cel da się osiągnąć zmianą zmiennych Bootstrap lub restylowaniem istniejących komponentów.
Motyw odpowiada za wygląd, a nie za logikę sklepu. Jeśli potrzebujesz nowej funkcji, przechodzisz na poziom 3.
Poziom 3: własny moduł
Moduł to właściwe miejsce dla nowej funkcjonalności: dodatkowych pól, integracji, własnych reguł cenowych, widżetów. Korzysta z hooków, czyli punktów zaczepienia w rdzeniu, dzięki czemu nie zmienia plików PrestaShop. Moduł zachowuje się przewidywalnie przy aktualizacjach, o ile zgadza się z wersją platformy.
W PrestaShop 9 części panelu opartej na Symfony nowe funkcje dokłada się przez usługi (services) i ich dekorowanie. Szczegóły techniczne opisujemy w artykule Jak napisać moduł PrestaShop 9: hooki i Symfony. Moduły trzeba też sprawdzać pod kątem bezpieczeństwa: Bezpieczeństwo modułów PrestaShop.
Poziom 4: override, czyli nadpisanie klasy
Override pozwala zmienić zachowanie klasy lub kontrolera rdzenia z poziomu modułu. Dokumentacja PrestaShop wprost ostrzega, że niesie on ograniczenia i ryzyka:
- jest wyłączny: jeśli jeden moduł nadpisuje daną klasę, inny nie może jej bezpiecznie nadpisać,
- nie zaleca się go w modułach dystrybuowanych, a w modułach partnerskich jest zabroniony,
- po instalacji trafia do katalogu
/override, a po dodaniu trzeba wyczyścić cache, - przy nowych polach w bazie lepszym rozwiązaniem jest własna tabela z własnym ObjectModel niż override.
Override ma sens tylko w lokalnym module Twojego sklepu i tylko wtedy, gdy hooki, rozszerzenie klas ani dekorowanie usług nie wystarczą.
Która droga do czego
| Potrzeba | Poziom | Ryzyko przy aktualizacji |
|---|---|---|
| Ceny, grupy, dostawa, podatki | Ustawienia w panelu | Brak |
| Zmiana wyglądu i układu stron | Motyw potomny | Niskie |
| Nowa funkcja, integracja z ERP, własna logika | Moduł z hookami | Niskie do średniego |
| Zmiana działania klasy rdzenia | Override (ostateczność) | Wysokie |
| Całkowicie własny frontend, duża skala | Headless | Zależne od API |
Dostosowanie a aktualizacje i migracja do PrestaShop 9
Przy przejściu na nową wersję główną część modułów i motywów wymaga aktualizacji, co potwierdza też zespół PrestaShop. Im więcej nadpisań i ręcznych zmian w plikach rdzenia, tym droższa i bardziej ryzykowna migracja. Dlatego dostosowania warto robić od początku w sposób bezpieczny dla aktualizacji. Plan migracji opisujemy w artykule Migracja PrestaShop 8 na 9.
Kiedy PrestaShop z dostosowaniami przestaje wystarczać
Jeśli potrzebujesz nietypowego frontendu, bardzo dużej wydajności lub wielu kanałów sprzedaży, PrestaShop może pozostać backendem, a sklep widzi klient w osobnej aplikacji Next.js. Opisujemy to w artykule PrestaShop jako backend headless. Ogólny przegląd platformy znajdziesz w przewodniku po PrestaShop.
W Pageart
PrestaShop to nasz główny stack, w którym jesteśmy certyfikowanym ekspertem. Dostosowujemy sklepy tak, żeby zmiany przetrwały aktualizacje: od motywów potomnych, przez moduły dedykowane i integracje z ERP, po frontendy headless. Sprawdź naszą ofertę sklepów internetowych.
FAQ
Jak dostosować sklep PrestaShop?
Na czterech poziomach: ustawieniami w panelu, motywem (najlepiej potomnym), własnym modułem z hookami lub nadpisaniem klas. Warto wybierać najwyższy poziom, który rozwiązuje problem.
Czy mogę edytować pliki rdzenia PrestaShop?
Nie jest to zalecane. Zmiany w rdzeniu znikną lub spowodują konflikty przy aktualizacji. Do zmian służą moduły, hooki i motywy.
Czym jest motyw potomny w PrestaShop?
To motyw dziedziczący po motywie bazowym, w którym nadpisujesz tylko wybrane szablony. Ułatwia to utrzymanie i przejmowanie aktualizacji motywu bazowego.
Co to jest override w PrestaShop i kiedy go używać?
To nadpisanie klasy lub kontrolera rdzenia z poziomu modułu. Dokumentacja zaleca go tylko w lokalnych modułach i tylko wtedy, gdy inne rozwiązania nie wystarczają, bo jest wyłączny i ryzykowny przy aktualizacjach.
Czy Hummingbird jest domyślnym motywem PrestaShop 9?
Nie. Według zespołu PrestaShop Hummingbird (Bootstrap 5) nie jest motywem domyślnym, a pobieranym motywem pozostaje Classic. Hummingbird jest motywem referencyjnym dla przyszłych rozwiązań.
Czy dostosowania przetrwają migrację na PrestaShop 9?
Zależy od sposobu wykonania. Moduły i motywy mogą wymagać aktualizacji, a nadpisania rdzenia i ręczne zmiany w plikach najczęściej trzeba przerobić od nowa.
Planujesz zmiany w sklepie PrestaShop i chcesz zrobić to bezpiecznie? Poproś o szybką wycenę albo napisz do nas.
