ix
ix

informatix

EN version Porozmawiajmy o projekcie
Strona główna / Blog / Konflikt modułów w PrestaShop — jak zdiagnozować [2026]
• 7 min czytania •

Konflikt modułów w PrestaShop — jak zdiagnozować [2026]

Konflikt modułów to jedna z najczęstszych przyczyn awarii PrestaShop. Diagnoza przez izolację: metoda połowienia, wyłączanie przez ps_module, kontrola override'ów i kompatybilności wersji PHP i PrestaShop.

Konflikt modułów w PrestaShop to jedna z najczęstszych przyczyn awarii: sklep działał, po instalacji lub aktualizacji modułu pojawia się biała strona, błąd 500 albo „rozjechany" wygląd. Moduły nadpisują się nawzajem na hookach, kolidują z override'ami rdzenia albo wymagają różnych wersji PHP. Diagnoza polega na systematycznej izolacji — bez tego zostaje wymiana modułów na czuja. Poniżej pełna procedura: od kopii bezpieczeństwa po raport kompatybilności. Naprawa u specjalisty: 200–600 zł netto.

Najważniejsze: Konflikt modułów diagnozujesz przez izolację: 1) backup plików i bazy, 2) zapisz listę modułów przed zmianami, 3) wyłączaj moduły partiami (połowa, potem połowa z połowy) — najszybciej znajdziesz sprawcę, 4) gdy panel nie działa, wyłączaj przez bazę (UPDATE ps_module SET active = 0), 5) włączaj podejrzanych pojedynczo i testuj, 6) sprawdź override'y w override/ — duplikaty klas to klasyczny konflikt, 7) porównaj wymagania modułów (wersje PHP, PrestaShop) i changelogi.

Objawy konfliktu modułów

Konflikt nie zawsze wygląda jak awaria. Sygnały, że dwa moduły walczą o to samo miejsce

  • biała strona lub błąd 500 po instalacji/aktualizacji modułu,

  • elementy znikają albo dublują się na stronie (dwa koszyki, dwa banery),

  • checkout działa tylko z wyłączonym innym modułem dostawy,

  • dziwne zachowanie koszyka, rabatów albo kosztów dostawy,

  • wydajność spada po włączeniu konkretnego modułu,

  • błędy JavaScript w konsoli przeglądarki (mapa Paczkomatów, widgety płatności).

  • ## Krok 1: Backup i lista modułów

Zanim wyłączysz pierwszy moduł

  1. zrób kopię plików i bazy danych,
  2. zapisz aktualną listę modułów z wersjami (panel → Moduły → Menedżer modułów; zrzut ekranu wystarczy),
  3. zanotuj dokładny czas i okoliczność pojawienia się problemu — po jakiej zmianie zaczął się błąd.
  • Punkt 3 jest kluczowy: jeśli problem pojawił się po instalacji modułu X, podejrzany jest moduł X i jego sąsiedzi na hookach — nie cały sklep.

  • ## Krok 2: Wyłączaj partiami — metoda połowienia

Zamiast wyłączać moduły pojedynczo (przy 40 modułach to godziny), użyj metody połowienia

  1. wyłącz połowę modułów (np. wszystkie płatności i wysyłki),
  2. sprawdź, czy problem zniknął,
  3. jeśli tak — sprawca jest w wyłączonej połowie; jeśli nie — w drugiej,
  4. powtarzaj połowienie na podejrzanej grupie, aż zostanie 1–3 moduły,
  5. włączaj je pojedynczo, testując po każdym włączeniu.

Przy błędzie na konkretnej stronie (koszyk, produkt) zawęź najpierw do modułów podpiętych do hooków tej strony: panel → Moduły → Pozycje (Transplantacje) → wybierz hook.

  • ## Krok 3: Wyłączanie przez bazę, gdy panel nie działa

Gdy biała strona dotyczy także panelu, moduły wyłączysz przez bazę danych

UPDATE ps_module SET active = 0 WHERE name = 'nazwa_modulu';

  • Nazwy modułów znajdziesz: SELECT name, active FROM ps_module ORDER BY name;. Po wyłączeniu wyczyść cache (var/cache) i sprawdź sklep. Aby włączyć z powrotem: SET active = 1. Zanim dotkniesz bazy, zrób jej zrzut — literówka w UPDATE potrafi zaskoczyć.

Uwaga: Nie usuwaj modułów przez bazę — usunięcie wiersza bez odinstalowania modułu zostawia osierocone tabele, hooki i wpisy konfiguracji. Wyłączaj (active = 0), nie usuwaj.

  • ## Krok 4: Sprawdź override'y

Override'y to najczęstsze źródło konfliktów niewidocznych na liście modułów

  • każdy moduł może dodawać pliki do override/,

  • dwa moduły nadpisujące tę samą klasę (np. Cart.php, Order.php) nadpisują się wzajemnie,

  • po aktualizacji rdzenia override może odwoływać się do usuniętej metody — stąd błędy 500.

  • Jak sprawdzić: porównaj katalog override/ z czystą instalacją (override/ w oryginale zawiera tylko index.php). Każdy plik .php to modyfikacja jakiegoś modułu. Jeśli dwa moduły modyfikują tę samą klasę, wybierz jeden (albo przenieś logikę do hooków). Więcej o override'ach: moduły i modyfikacje PrestaShop.

  • ## Krok 5: Sprawdź kompatybilność wersji

Część „konfliktów" to zwykła niekompatybilność

Co sprawdzić Gdzie Typowy problem
Wersja PHP modułu composer.json / dokumentacja modułu Moduł wymaga PHP 7.4, serwer ma 8.3
Wersja PrestaShop zakładka modułu Moduł dla 1.7 na sklepie 9.x
Zależności modułu panel modułu Brak wymaganej biblioteki (np. intl)
Konflikt nazw klas logi błędów Cannot redeclare class
  • Logi wskażą wprost: Cannot redeclare = dwie definicje tej samej klasy, Call to undefined method = moduł wywołuje metodę, której nie ma w tej wersji rdzenia. Czytanie logów: logi PrestaShop.

  • ## Krok 6: Testuj na stagingu

Każdą zmianę modułów testuj na kopii sklepu

  • instalacja nowego modułu → test na stagingu → dopiero potem produkcja,
  • aktualizacja modułu → changelog + staging + pełna ścieżka zakupowa,
  • przed aktualizacją rdzenia → lista modułów kompatybilnych z nową wersją.

Jeśli sklep nie ma środowiska testowego, jego postawienie to najlepsza inwestycja w stabilność — szczegóły w problemy po aktualizacji.

Najczęściej zadawane pytania

Po instalacji modułu sklep pokazuje białą stronę — co robić?

Wyłącz ten moduł przez panel (a jeśli panel nie działa — przez bazę: UPDATE ps_module SET active = 0 WHERE name = 'nazwa'), wyczyść cache i sprawdź sklep. Potem włącz moduł na kopii środowiska z trybem debug i odczytaj błąd — najczęściej to brakująca zależność albo konflikt z innym modułem.

Jak szybko znaleźć moduł powodujący konflikt?

  • Metodą połowienia: wyłącz połowę modułów, sprawdź, czy problem zniknął, i zawężaj do połowy, w której jest sprawca. Przy błędzie na konkretnej stronie (np. koszyk) zacznij od modułów podpiętych do hooków tej strony.

Czy konflikt modułów może dotyczyć tylko checkoutu?

Tak — moduły płatności i dostawy nadpisują te same elementy checkoutu i najczęściej wchodzą w konflikty. Objawy: brak metod płatności, błąd przy składaniu zamówienia, nieładująca się mapa Paczkomatów. Procedura: checkout nie działa.

Jak uniknąć konfliktów modułów na przyszłość?

Instaluj moduły partiami na stagingu, sprawdzaj kompatybilność wersji przed aktualizacją, unikaj modułów porzuconych (bez aktualizacji od lat), trzymaj listę modułów z wersjami i czytaj changelogi. Więcej dobrych praktyk: moduły i modyfikacje PrestaShop.

Źródła i narzędzia


👉 Moduł położył sklep? Zdiagnozujemy konflikt i przywrócimy działanie — formularz kontaktowy lub kontakt@informatix.com.pl. Zobacz też pomoc techniczna PrestaShop.

📖 Zobacz też: biała strona w PrestaShop, błąd 500 i problemy po aktualizacji.

Darmowy PDF

Checklista wymagań do wyceny aplikacji

12 pytań kontrolnych, które warto przygotować przed rozmową z wykonawcą — szybsza wycena, mniej ukrytych kosztów.

Powiązane wpisy

13.10.2026

Pomoc PrestaShop — naprawa błędów i awarii [2026]

Biała strona, błąd 500, zepsuty checkout, brak maili — najczęstsze awarie PrestaShop mają znane procedury naprawy: backup, logi, tryb debug, izolacja modułu, testy. Doraźna naprawa 200–600 zł netto, diagnostyka z raportem 500–1 500 zł netto, pakiety godzin od 900 zł.

Czytaj dalej

21.10.2026

Biała strona w PrestaShop — naprawa krok po kroku [2026]

Biała strona w PrestaShop to wyłączone wyświetlanie błędów PHP — przyczyna jest w logach. Procedura naprawy w 6 krokach: backup, tryb debug, logi, najczęstsze przyczyny (pamięć, uprawnienia, cache), izolacja modułu, test ścieżki zakupowej.

Czytaj dalej