Jak włączyć debug mode w PrestaShop i bezpiecznie znaleźć błąd

Debug mode włącz, gdy błąd uniemożliwia normalną pracę sklepu i potrzebujesz ustalić jego źródło. Tryb deweloperski może wyświetlać komunikaty PHP, dlatego uruchamiaj go na kopii testowej albo na produkcji tylko na czas kontrolowanej diagnozy. Dokumentacja PrestaShop 8 ostrzega, że tryb debugowania istotnie obciąża sklep; stan dokumentacji sprawdzono w październiku 2026.

Przed włączeniem trybu zapisz dokładny adres strony, czynność poprzedzającą błąd i czas jego wystąpienia. Dzięki temu odtworzysz problem i porównasz komunikat z logiem serwera.

Objaw sam w sobie nie wskazuje winnego komponentu. Tabela pomaga wybrać pierwszy obszar do sprawdzenia.

Zestaw objaw z czasem wdrożenia i odpowiednim logiem, a debug mode wykorzystaj do zawężenia przyczyny.

Przed zmianą ustawień przygotuj aktualną kopię plików i bazy, dostęp do właściwej instalacji oraz możliwość odtworzenia problemu. Kopia pozwala cofnąć zmianę w pliku, a kopia bazy chroni dane sklepu przy testach wymagających zmian w konfiguracji.

Zapisz następujące informacje:

• wersję PrestaShop i PHP widoczną w panelu lub konfiguracji hostingu;
• adres strony i dokładną czynność wywołującą błąd;
• przybliżony czas pierwszego wystąpienia problemu;
• ostatnie zmiany, w tym aktualizacje, moduły, motyw i modyfikacje kodu;
• dostęp FTP lub SSH do plików oraz dostęp do panelu hostingu.

Nie udostępniaj publicznie kopii bazy, zrzutu ekranu z danymi klientów ani pełnego logu. Komunikaty mogą zawierać adresy e-mail, ścieżki serwera, parametry żądań i dane przekazane do formularzy. Jeśli sklep ma środowisko testowe, odtwórz tam błąd przed zmianą konfiguracji produkcyjnej.

W PrestaShop 8 ustaw `_PS_MODE_DEV_` na `true` w `config/defines.inc.php`, jeśli możesz bezpiecznie edytować pliki sklepu. Oficjalna dokumentacja wskazuje również przełącznik panelu Zaawansowane parametry > Wydajność > Debug mode; stan dokumentacji sprawdzono w październiku 2026.

W panelu zmień Debug mode na Tak, zapisz ustawienie i odśwież stronę, na której występuje problem. Jeśli panel się nie otwiera, pracuj przez FTP lub SSH:

1. Otwórz katalog główny właściwej instalacji PrestaShop.
2. Pobierz kopię `config/defines.inc.php` na komputer.
3. Znajdź definicję `_PS_MODE_DEV_` i zmień wartość `false` na `true`.
4. Zapisz plik, zachowując jego nazwę i kodowanie.
5. Otwórz ponownie adres powodujący błąd i zapisz pełny komunikat.

Nie dodawaj drugiej definicji stałej, jeśli istniejąca linia już ją ustawia. W przypadku błędu składni przywróć kopię pliku. Po zmianie sprawdź także stronę główną i koszyk, ponieważ tryb deweloperski może ujawnić błędy w innych elementach sklepu.

Jeśli rozważasz przebudowę sklepu zamiast naprawy pojedynczego błędu, zobacz, jak KC Mobile projektuje sklepy internetowe na WooCommerce.

W PrestaShop 1.7 włącz tryb deweloperski przez panel lub ustawienie `_PS_MODE_DEV_` w `config/defines.inc.php`. Dokumentacja PrestaShop opisuje dla tej generacji ustawienie trybu produkcyjnego w tym pliku; dokładne nazwy opcji panelu mogą zależeć od wersji i tłumaczenia. Stan dokumentacji sprawdzono w październiku 2026.

Ustal numer wersji przed zmianą i nie kopiuj instrukcji dla innej generacji PrestaShop bez sprawdzenia istniejących definicji. W panelu szukaj opcji debugowania w Zaawansowane parametry > Wydajność.

Tabela pokazuje podstawową różnicę w sposobie dostępu do debugowania. Po diagnozie w obu wersjach przywróć tryb produkcyjny.

Nazwa stałej i położenie pliku są wspólne dla tych wersji, ale szczegóły panelu mogą się różnić.

Komunikat błędu zwykle wskazuje typ wyjątku, plik, numer linii i ścieżkę wykonania, które pomagają zawęzić diagnozę. Zapisz cały komunikat wraz z czasem, ale przed przekazaniem go dalej usuń dane klientów, tokeny i inne poufne wartości.

W ścieżce pliku zwróć uwagę na katalog `modules`, `themes`, `classes` lub `src`. Nazwa modułu albo motywu może wskazać komponent, który zgłosił błąd, lecz sama obecność pliku w ścieżce nie dowodzi, że jego kod jest przyczyną. Błąd może wynikać z niezgodnej wersji PHP, brakującej zależności lub danych przekazanych przez inny komponent.

Fragment komunikatu wskazuje następny obszar diagnozy, ale nie stanowi samodzielnego potwierdzenia przyczyny.

W PrestaShop 8 logi aplikacji korzystającej z Symfony mogą znajdować się w `var/logs`; dokumentacja środowiska Docker pokazuje plik `var/logs/dev.log`. Stan dokumentacji sprawdzono w październiku 2026. Log PHP serwera może znajdować się w innym miejscu zależnie od konfiguracji hostingu. Jeśli tryb debugowania nie pokazuje przyczyny, pobierz log błędów PHP z panelu hostingu i skoreluj wpis z czasem awarii.

Winny moduł ustalaj przez odtworzenie błędu na kopii sklepu i wyłączanie jednego podejrzanego elementu naraz. Taki test ogranicza ryzyko jednoczesnej zmiany kilku warunków i utraty informacji o przyczynie.

Porównaj czas wystąpienia błędu z historią aktualizacji PrestaShop, PHP, modułu i motywu. Następnie odtwórz na kopii tę samą czynność, która wywołuje problem, i sprawdź, czy błąd znika po wyłączeniu jednego elementu. Przed testem zapisz jego pierwotne ustawienie, a po teście przywróć konfigurację kopii.

Z naszych wdrożeń wynika, że komunikat błędu jest najbardziej użyteczny, gdy zestawimy go z chronologią zmian i powtarzalnym scenariuszem. Zalecamy konsultację z programistą, gdy błąd dotyczy płatności, zamówień, danych klientów albo nie znika po odtworzeniu na kopii.

Wyłącz debug mode, przywracając `_PS_MODE_DEV_` do `false` albo ustawiając Debug mode na Nie w panelu PrestaShop. Dokumentacja PrestaShop zaleca wyłączenie trybu po zakończeniu diagnozy ze względu na obciążenie; stan sprawdzono w październiku 2026.

Po zapisaniu zmiany wykonaj krótką kontrolę:

• otwórz stronę główną, produkt, koszyk i panel logowania;
• sprawdź, czy klient nie widzi komunikatu PHP ani ścieżki serwera;
• porównaj ustawienie debugowania w panelu z wartością w pliku;
• usuń lokalne kopie logów z miejsc współdzielonych i ogranicz dostęp do zachowanych plików.

Jeżeli po wyłączeniu nadal widać szczegóły błędu, sprawdź konfigurację PHP i pamięć podręczną hostingu. Sama zmiana stałej nie zawsze nadpisuje ustawienia serwera. Po naprawie skontroluj zamówienie testowe, formularz kontaktowy i najważniejsze integracje.

Największym ryzykiem debugowania na produkcji jest pozostawienie widocznych szczegółów błędu, które mogą ujawnić informacje o serwerze lub danych żądania. Pracuj na kopii sklepu, kiedy to możliwe, a tryb produkcyjny przywróć od razu po zebraniu potrzebnych danych.

Tabela pokazuje ryzyko i zabezpieczenie dla typowych pomyłek związanych ze zmianą pliku i przechowywaniem wyników diagnozy.

Jeśli problem wymaga stałej diagnostyki, aktualizacji lub zmian w działającym sklepie, opieka nad sklepem internetowym może objąć kontrolę wdrożeń i diagnozę błędów. Gdy analiza wskazuje na potrzebę stworzenia nowego sklepu, realizacja sklepu internetowego na WooCommerce jest zakresem, z którym można porównać dalszą rozbudowę PrestaShop.

• PrestaShop i PHP 8.0: jak sprawdzić zgodność oraz bezpiecznie zmienić wersję
• Jak wyłączyć sklep PrestaShop i bezpiecznie włączyć tryb konserwacji
• PrestaShop themes: jak wybrać motyw, który nie utrudni rozwoju sklepu
• PrestaShop API: jak skonfigurować dostęp i bezpiecznie zintegrować sklep