Czym jest override w PrestaShop i jak działa mechanizm nadpisywania

Override to kopia klasy rdzenia PrestaShop umieszczona w katalogu /override/, którą sklep ładuje zamiast oryginału. Nazwa pliku musi być identyczna z nazwą klasy z rdzenia: Product.php nadpisuje classes/Product.php. Nie tworzysz pliku ProductCore.php — klasa Core zostaje nietknięta i służy jako klasa bazowa.

PrestaShop szuka override'ów w trzech miejscach:

• /override/classes/ — klasy modeli i helperów: Product.php, Cart.php, Tools.php. Podkatalogi muszą odwzorować strukturę rdzenia, np. /override/classes/pdf/ przy zmianie generowania faktury.
• /override/controllers/ — kontrolery frontowe i administracyjne, np. /override/controllers/front/ProductController.php.
• /override/modules/ — klasy modułów. Tu pliki trafiają automatycznie, gdy instalujesz moduł, który sam używa override'ów.

Skąd PrestaShop wie, który plik wczytać? Z indeksu klas w cache/class_index.php. To mapa: nazwa klasy → ścieżka pliku. Jeśli dodasz override i nie wyczyścisz tego indeksu, sklep nadal będzie używał wersji rdzeniowej — a Ty będziesz szukać błędu w kodzie, który w ogóle się nie wykonuje. Po każdej zmianie: Panel → Zaawansowane parametry → Wydajność → Wyczyść cache albo usunięcie pliku cache/class_index.php (odtworzy się przy pierwszym żądaniu). Szybka kontrola z terminala: ls -R override pokaże, co faktycznie leży na serwerze.

Kolejność ma znaczenie, bo PrestaShop nie scala dwóch override'ów tej samej klasy. Jeśli dwa moduły nadpiszą Product, zostanie jeden plik — ten wgrany później. Funkcja z pierwszego modułu po cichu przestaje działać. Dlatego przy wdrożeniach PrestaShop przed instalacją kolejnego modułu z override'ami sprawdzamy, co już leży w /override/. Mechanizm opisuje dokumentacja dla deweloperów PrestaShop.

Override klasy, kontrolera i szablonu – trzy różne rzeczy, które myli się najczęściej

Większość konfliktów w projektach bierze się z jednego nieporozumienia: „override” to potocznie trzy różne mechanizmy o różnych konsekwencjach.

Override klasy. Plik /override/classes/Product.php z klasą class Product extends ProductCore. Dziedziczysz po klasie rdzenia, więc masz dostęp do wszystkich metod, ale musisz zachować sygnatury — ta sama nazwa, te same argumenty, ten sam typ zwracany. Jeśli kopiujesz metodę z rdzenia, kopiuj całą. Skrócona wersja bez obsługi przypadku brzegowego (np. brak wpisu w tabeli stanów magazynowych) to typowa przyczyna błędów przy składaniu zamówienia, które ujawniają się tylko u części klientów.

Override kontrolera. Plik w /override/controllers/front/, np. OrderConfirmationController.php. Nazwy metod i ich argumenty muszą zostać zachowane, inaczej moduły wołające parent:: przestaną działać. Bezpieczny wzorzec: nadpisz initContent() i wywołaj parent::initContent() przed własną logiką.

Nadpisanie szablonu. Kopiujesz plik z rdzenia lub modułu do katalogu motywu — w PrestaShop 1.7 i 8.x: themes/twoj-motyw/templates/ dla plików rdzenia i themes/twoj-motyw/modules/nazwa-modulu/ dla szablonów modułów. W 1.6 odpowiednio themes/twoj-motyw/ i themes/twoj-motyw/modules/. Nie dotykasz PHP, nie kolidujesz z innymi modułami, a zmiana jest widoczna po wyczyszczeniu cache. Minus: po dużej aktualizacji Twój plik nie dostanie nowych pól z rdzenia — trzeba go porównać z nową wersją. To jeden z powodów, dla których migrację sklepu PrestaShop planuje się razem z audytem override'ów, a nie po fakcie.

Prosta reguła: układ, komunikaty i wygląd → szablon. Sposób liczenia (cena, rabat, koszt dostawy) → klasa. Parametry URL, przekierowania, uprawnienia → kontroler.

Override, hook czy własny moduł – jak wybrać bez żalu

Zacznij od pytania: czy zmieniasz wynik istniejącej metody, czy dokładasz coś obok? To rozstrzyga wybór szybciej niż preferencje zespołu.

Konsekwencje są praktyczne. Override modyfikuje logikę rdzenia. Znika razem z Twoim repozytorium, ale zostaje na serwerze nawet po odinstalowaniu modułu, który go dodał — jeśli wgrywałeś plik ręcznie, nie usunie go żaden automat. Hook działa obok: rdzeń wykonuje swój kod, a Twój moduł dopina się w punkcie zaczepienia. Odinstalowanie modułu zwykle usuwa cały jego kod, a aktualizacja PrestaShop rzadziej psuje hook niż nadpisaną metodę.

Kiedy hook nie wystarcza. Sprawdź najpierw, czy hook istnieje w miejscu, którego potrzebujesz. Lista jest długa — displayHeader, actionCartSave, actionValidateOrder albo displayProductAdditionalInfo pokrywają większość typowych potrzeb. Podglądasz je w Panelu: Design → Pozycje, albo szukając Hook::exec w kodzie. Jeżeli hook istnieje, ale nie zawiera danych, których potrzebujesz (bo liczą się w połowie metody), albo nie ma go tam wcale, zostaje override metody lub kontrolera. Wtedy bierzesz na siebie utrzymanie tego fragmentu: każda aktualizacja rdzenia wymaga porównania z nową wersją. Zanim to zrobisz, zapisz w repozytorium, po co powstał override — bez notatki po roku nikt nie wie, czy można go bezpiecznie usunąć.

Jak krok po kroku utworzyć poprawny override

Krok 1 – znajdź oryginał i skopiuj sygnaturę. Klasy modeli leżą w /classes/ (np. /classes/Product.php zawiera klasę ProductCore), kontrolery w /controllers/front/ i /controllers/admin/ (np. CartController.php → CartControllerCore). Otwórz plik i skopiuj dokładnie sygnaturę metody: nazwę, kolejność i typy parametrów oraz wartości domyślne. Zmieniona sygnatura to najczęstszy powód, dla którego override działa na Twoim serwerze, a wywala się u klienta na innej wersji PHP.

Krok 2 – plik w /override/ z lustrzaną strukturą katalogów. /classes/Product.php → /override/classes/Product.php, /controllers/front/CartController.php → /override/controllers/front/CartController.php. Klasa dziedziczy po wersji Core i gubi sufiks Core z nazwy:

class Product extends ProductCore
{
    public function getPrice($id_product, $id_product_attribute = null, ...)
    {
        // Twoja logika
        return parent::getPrice($id_product, $id_product_attribute, ...);
    }
}

W klasach legacy (katalogi /classes/, /controllers/) nie dodawaj namespace. Jeśli nadpisujesz coś z /src/ (nowe API Symfony w 1.7+), namespace jest obowiązkowy i musi być identyczny jak w oryginale.

Krok 3 – wyczyść cache i sprawdź, czy metoda faktycznie się wykonuje. Usuń zawartość /var/cache/dev i /var/cache/prod albo użyj czyszczenia cache w panelu. Wstaw tymczasowo PrestaShopLogger::addLog('override getPrice', 1); lub error_log() i wykonaj realne zamówienie testowe. Brak błędu nic nie znaczy – sprawdzasz, czy kod w ogóle wchodzi.

Zasada: nadpisuj tylko metody, które faktycznie zmieniasz. Skopiowanie całej klasy (w Product.php to kilkaset metod i tysiące linii) oznacza, że każdą aktualizację PrestaShop porównujesz ręcznie, a przy nowej wersji PHP debugujesz kod, którego nikt nie potrzebował.

Jak wykryć istniejące override'y i konflikty między modułami

Zacznij od inwentaryzacji. Struktura /override/ jest lustrem rdzenia, więc jedno polecenie daje pełny obraz: find override -name "*.php" albo grep -rl "extends .*Core" override/. Każdy plik porównaj z listą zainstalowanych modułów (Moduły → Moduły i usługi). Moduły do płatności, kurierów i integracji ERP bardzo często dostarczają własne override'y – i to one wchodzą w konflikt najczęściej.

Sprawdź, skąd naprawdę pochodzi metoda. Najszybszy test to refleksja: (new ReflectionMethod('Product', 'getPrice'))->getFileName() zwróci Ci konkretną ścieżkę pliku – rdzeń, override modułu czy Twój własny. get_class($product) pokaże Product, a nie ProductCore, co potwierdza, że override jest aktywny. W trybie debug w 1.7+ masz jeszcze profiler Symfony z listą wywołań, a z Xdebug pełny stack trace – widać, czy metoda idzie z modułu, czy z rdzenia.

Objawy konfliktu i jak je czytać. Dwa moduły nadpisujące tę samą klasę to jedna klasa PHP, więc wygrywa ten, który został zainstalowany później – pierwszy przestaje działać bez żadnego komunikatu. Typowe sygnały: biały ekran (przy display_errors = 0), metoda, która ewidentnie się nie wykonuje, albo błąd Cannot redeclare class i Call to undefined method po włączeniu trybu debug w Zaawansowane → Wydajność. Czytaj komunikat do końca: ścieżka pliku w treści błędu wskazuje, który override wygrał.

Jeżeli konflikt dotyczy modułu, którego nie da się przepisać, rozwiązaniem jest jeden override łączący obie logiki z wywołaniem parent:: w środku, a nie dwa pliki walczące o tę samą metodę. Zanim postawisz własną warstwę nadpisań, warto wiedzieć, co i tak robimy w ramach wdrożeń PrestaShop – część rzeczy da się załatwić hookiem, bez wchodzenia w rdzeń.

Override a aktualizacja PrestaShop – co się stanie z Twoim kodem

Jedno jest pewne: aktualizacja – przez moduł 1-Click Upgrade albo ręcznie – nie kasuje katalogu /override/. Twoje pliki zostaną na miejscu. Ryzyko polega na czymś innym: rdzeń pod nimi się zmienia i override może przestać pasować.

Możliwe są trzy scenariusze. Pierwszy: metoda nadal istnieje z tą samą sygnaturą – override działa bez zmian. Drugi: metoda zmieniła sygnaturę lub logikę – Twój kod nadpisuje nową wersję starą logiką i cicho psuje funkcję, np. przeliczenia cen czy podatków. Trzeci, najgorszy: metoda została usunięta z rdzenia – wtedy albo dostajesz błąd, albo override przestaje być wywoływany, bo nikt go już nie woła, a Ty nie zauważasz tego przez kilka tygodni.

Jak wyłapać to przed produkcją. Trzymaj własne override'y w repozytorium git i przed każdą aktualizacją zrób diff plików rdzenia między wersjami. Źródła PrestaShop są publiczne – porównanie classes/Product.php z tagu 1.7.x i 8.x zajmuje kilka minut i od razu pokazuje, które metody zniknęły albo zmieniły parametry. To samo dotyczy migracji 1.7 → 8: część klas legacy została przepisana na Symfony, a przy przejściu 8 → 9 dochodzi kwestia usuniętych metod. Nie zakładaj z góry, że Twoja metoda przetrwała – sprawdź to w kodzie.

Test na kopii sklepu, nie na produkcji. Postaw staging z kopią bazy (dane klientów zanonimizuj), wgraj override'y i przejdź pełną ścieżkę: dodanie do koszyka, zamówienie, płatność, mail potwierdzający, faktura, panel administracyjny. Jeśli metoda zniknęła z rdzenia, override trzeba usunąć albo przepisać na hook lub nowe API – nie „naprawiać” na ślepo. Szerszy plan takich prac opisujemy w materiale o migracji sklepu PrestaShop.

Pułapki, które psują sklep – i jak je rozpoznać zanim będzie za późno

Trzy awarie wracają najczęściej i wszystkie mają wspólną cechę: nie krzyczą od razu. Poniżej objawy i sposoby sprawdzenia, zanim klient zgłosi brak zamówienia.

1. Metoda nadpisana bez zgodnej sygnatury i bez parent::. Objaw: w koszyku widać 3 produkty, a w zamówieniu zapisują się 2; rabat nalicza się tylko części klientów. Wykrycie: otwórz override/classes/Cart.php i porównaj z classes/Cart.php. Jeśli w Twojej metodzie nie ma wywołania parent::nazwaMetody(), cała oryginalna logika znika. Sygnatura musi się zgadzać co do liczby i typów argumentów. Rozjazd kończy się fatal error, a przy wyłączonym display_errors – białą stroną, którą trudno zdiagnozować.

2. Skopiowana cała klasa zamiast jednej metody. Objaw: po aktualizacji rdzenia (np. z 8.1 na 9) zaczynają dziać się rzeczy, których nikt nie zamawiał – bo w override siedzi kod sprzed trzech lat. Wykrycie: porównaj liczbę linii pliku z /override/ z oryginałem w /classes/. Jeśli są zbliżone, prawdopodobnie skopiowano klasę w całości. Nadpisuj jedną metodę, resztę zostaw rdzeniowi.

3. Twarda edycja szablonu zamiast override w motywie. Objaw: po aktualizacji motywu ginie dodatkowe pole w koszyku albo komunikat o darmowej dostawie. Wykrycie: zestaw pliki .tpl z katalogu motywu z wersją z themes/classic. Poprawna droga to kopia szablonu do własnego motywu.

Po każdej zmianie w /override/ usuń zawartość katalogu cache (w 1.7+ var/cache/, w starszych cache/class_index.php) – inaczej sklep dalej użyje starej klasy. Kolejność takich prac opisujemy w sekcji o wdrożeniach PrestaShop, a szczegóły techniczne override znajdziesz w dokumentacji dla deweloperów PrestaShop.

Kiedy zlecić override zamiast robić go samemu

Samodzielny override ma sens, dopóki nie dotyka pieniędzy i da się go szybko cofnąć. Granica przebiega w trzech miejscach.

Brak repozytorium. Jeśli zmiany w /override/ leżą tylko na produkcji, nie cofniesz błędu i nie sprawdzisz, co zmieniono pół roku temu. Git to punkt wyjścia, nie dodatek.

Brak środowiska testowego. Testy na żywym sklepie to zgadywanie, ile zamówień przepadło. Potrzebna kopia plików i bazy, na której przejdziesz scenariusze: dodanie do koszyka, kupon, zmiana statusu zamówienia, płatność.

Override dotyka płatności, zamówień albo podatków. Klasy Cart, Order, OrderDetail, PaymentModule – jeden błąd to niezaksięgowane wpłaty albo złe kwoty na fakturze.

Praca z deweloperem bez pośredników rozlicza się godzinowo, nie „pakietem”. Realistyczne widełki: 2–4 h na audyt istniejących override i plan, 3–6 h na pojedynczą metodę poza logiką zamówień (z testami), 10–25 h na override w klasach zamówień i płatności ze scenariuszami testowymi, 20–40 h, jeśli dochodzi moduł, hooki i staging. Stawki godzinowe bywają różne – potwierdź je u wykonawcy. Cena to godziny razy stawka, a nie liczba z sufitu. Jeśli wykonawca nie umie podać liczby godzin, to sygnał ostrzegawczy.

Opieka po wdrożeniu: SLA określa czas reakcji (np. jeden dzień roboczy) i zakres. Utrzymanie override przy aktualizacjach rdzenia to przegląd metod przed wdrożeniem nowej wersji, testy po aktualizacji i dopisanie zmian wynikających z rdzenia. Ustal z góry, kto płaci za dostosowanie do nowej wersji. Zasady przygotowania takiej zmiany opisaliśmy przy migracji sklepu PrestaShop.

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

Lista kontrolna do odklikania

• Sprawdź, czy hook nie wystarczy — Przejrzyj listę hooków dostępnych w miejscu, które chcesz zmienić. Jeśli jest zaczepienie w odpowiednim punkcie, użyj go zamiast override.
• Znajdź metodę w rdzeniu — Otwórz plik w /classes/ lub /controllers/ i zlokalizuj dokładnie tę metodę, której logikę chcesz zmienić.
• Zapisz sygnaturę metody — Skopiuj nazwę, parametry, typy i wartość zwracaną. Sygnatura w override musi być identyczna.
• Utwórz plik w /override/ — Zachowaj strukturę katalogów zgodną z rdzeniem i nazwę klasy z sufiksem Core w dziedziczeniu, np. class Product extends ProductCore.
• Nie kopiuj całej klasy — W pliku zostaw tylko nadpisywane metody. Reszta ma pochodzić z rdzenia.
• Wyczyść cache — Po dodaniu lub zmianie pliku override zawsze wyczyść cache, żeby mapa klas została przebudowana.
• Sprawdź class_index.php — Upewnij się, że plik cache wskazuje na Twój override, a nie na oryginalną klasę.
• Włącz tryb debug na kopii — Testuj na środowisku staging z włączonym trybem debug, nigdy bezpośrednio na produkcji.
• Sprawdź istniejące override — Przejrzyj katalog /override/ i porównaj go z listą zainstalowanych modułów przed dodaniem kolejnego pliku.
• Zrób kopię zapasową — Pliki i baza przed każdą zmianą w rdzeniu lub override. Bez tego nie ma jak wrócić.
• Przetestuj scenariusze brzegowe — Sprawdź nie tylko główną ścieżkę, ale też koszyk, zamówienie, stany magazynowe i panel administracyjny.
• Udokumentuj override — Zapisz w repozytorium, którą metodę i w jakim celu nadpisałeś. Ułatwi to weryfikację przy aktualizacji.
• Sprawdź zgodność przed aktualizacją — Porównaj nadpisywane metody z ich odpowiednikami w nowej wersji PrestaShop, zanim wdrożysz update na produkcję.
• Ustal właściciela zmiany — Zapisz, kto odpowiada za dany override i kiedy był ostatnio weryfikowany.

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
• Google Ads – dokumentacja API