Jak skonfigurować PrestaShop w trybie developerskim

Tryb developerski w PrestaShop pozwala precyzyjnie diagnozować problemy i przyspiesza pracę nad motywami oraz modułami. Jeśli chcesz zobaczyć szczegółowe błędy, włączyć narzędzia analityczne i usprawnić przepływ pracy, potrzebujesz poprawnej konfiguracji i kilku dobrych praktyk. W tej instrukcji pokazuję, jak bezpiecznie aktywować tryb deweloperski, jakie ustawienia zmienić, gdzie szukać błędów, jak zarządzać pamięcią podręczną oraz jak wrócić do trybu produkcyjnego bez przestojów.

Na czym polega tryb developerski i kiedy go włączać

Co faktycznie zmienia tryb deweloperski

Aktywacja trybu deweloperskiego powoduje, że sklep przestaje ukrywać błędy i ostrzeżenia – zamiast ogólnego komunikatu zobaczysz dokładne informacje o wyjątkach, niewłaściwych wywołaniach i brakach w konfiguracji. Oprócz tego, w wielu wersjach PrestaShop pojawia się pasek narzędzi (symfonowy toolbar) i możliwość podglądu czasu generowania strony, zapytań SQL czy struktury żądań. W praktyce oznacza to szybsze znajdowanie przyczyn awarii oraz krótsze cykle poprawek.

Korzyści a ryzyka

• Przyspieszona diagnostyka – natychmiastowy wgląd w błędy oraz szczegóły stosu wywołań.
• Łatwiejsza praca z motywami i modułami – natychmiastowe odświeżanie zmian i kontrola zależności.
• Ryzyko ujawnienia wrażliwych informacji – ścieżki plików, wersje bibliotek, a czasem dane konfiguracyjne. Z tego powodu włączaj tryb deweloperski tylko tymczasowo i najlepiej w środowisku testowym.
• Potencjalnie wolniejsze działanie sklepu – wyłączone mechanizmy buforowania i dodatkowe analizy obciążają serwer.

Różnice między wersjami 1.6, 1.7 i 8

PrestaShop 1.6 i wcześniejsze wersje opierają się głównie na stałej w pliku konfiguracyjnym, która przełącza sklep w tryb deweloperski. W PrestaShop 1.7 pojawia się integracja z Symfony oraz narzędzia konsolowe, natomiast PrestaShop 8 rozszerza te mechanizmy i chętniej korzysta z rozdzielenia środowisk. W praktyce: panel administracyjny oferuje przełącznik Debug Mode, ale gdy nie działa Back Office, nadal możesz wymusić konfigurację w plikach. W nowszych wydaniach dostępne są też dodatkowe logi i tryby środowiskowe.

Kiedy i gdzie włączać

• Środowisko lokalne lub staging – preferowane. Tu testujesz nowe funkcje, motywy i aktualizacje.
• Środowisko produkcyjne – tylko krótkotrwale, gdy musisz zdiagnozować błąd niedostępny na stagingu. Po zakończeniu natychmiast wyłączaj tryb deweloperski.
• Granulacja – jeśli to możliwe, ogranicz dostęp do sklepu hasłem HTTP lub IP, aby przypadkowi użytkownicy nie widzieli szczegółów błędów.

Włączanie trybu developerskiego: panel i pliki

Przełącznik w panelu administracyjnym

Najwygodniejsza metoda dostępna w PrestaShop 1.7 i 8:

• Wejdź do panelu administracyjnego: Zaawansowane parametry → Wydajność → sekcja Tryb debugowania.
• Ustaw przełącznik Tryb deweloperski na Tak (Debug Mode: On).
• Rozważ również tymczasowe wyłączenie opcji “Włącz pamięć podręczną” i “Kompilacja szablonów” tak, by zmiany były widoczne natychmiast.
• Na czas diagnozy możesz zaznaczyć “Wyłącz wszystkie moduły innych autorów” oraz “Wyłącz nadpisania”. Dzięki temu szybko ustalisz, czy problem wynika z konfliktu rozszerzenia lub nadpisania klas.

Ta metoda jest bezpieczna i nie wymaga edycji plików. Gdy panel jest niedostępny (np. z powodu błędu), użyj jednej z metod poniżej.

Edycja pliku config/defines.inc.php (1.6, 1.7, 8)

W większości instalacji PrestaShop możesz wymusić tryb deweloperski ustawiając stałą w pliku konfiguracyjnym:

• Otwórz plik: /config/defines.inc.php.
• Znajdź linię z definicją trybu i ustaw ją na true (jeśli nie istnieje – dodaj ją):

  define(’_PS_MODE_DEV_’, true);

• Zapisz plik i odśwież stronę sklepu.

Ta opcja zwykle skutkuje wyświetlaniem komunikatów o błędach na froncie i w panelu. Jeśli chcesz rozszerzyć diagnostykę o czas generowania i statystyki zapytań, możesz dodatkowo włączyć profiler (szczegóły w dalszej części).

Zmienne środowiskowe i integracja z Symfony

W nowszych wydaniach, zwłaszcza z rozbudowaną warstwą Symfony, możesz sterować zachowaniem aplikacji zmiennymi środowiskowymi. W konfiguracji serwera (Apache/Nginx) lub menedżerze procesów PHP ustaw, gdy to wspierane:

• APP_ENV=dev
• APP_DEBUG=1

Pozwala to uzyskać dodatkowe narzędzia diagnostyczne (np. pasek debugowania Symfony) bez trwałej modyfikacji plików projektu. Pamiętaj jednak, że konkretna obsługa zmiennych zależy od wersji Twojego sklepu i sposobu instalacji.

Uprawnienia i bezpieczeństwo

• Uprawnienia do plików – zachowaj standard (pliki 644, katalogi 755), aby uniknąć ryzyka nadpisania przez inny proces.
• Cofanie zmian – po zdiagnozowaniu problemu przywróć ustawienie produkcyjne (wyłącz Debug Mode, włącz buforowanie), aby zminimalizować ryzyko ujawnienia informacji.
• Ogranicz widoczność – jeżeli musisz włączyć tryb deweloperski na produkcji, zabezpiecz sklep hasłem HTTP lub ograniczeniem IP w serwerze WWW.

Konfiguracja diagnostyki: błędy, logi i profiler

Wyświetlanie błędów PHP i PrestaShop

W trybie deweloperskim komunikaty o błędach powinny pojawiać się na stronie. Jeżeli tak się nie dzieje, upewnij się, że konfiguracja PHP pozwala na ich wyświetlanie (display_errors) oraz że poziom raportowania obejmuje ostrzeżenia i błędy krytyczne. W środowiskach zarządzanych przez panele hostingowe można to ustawić w konfiguracji PHP lub .user.ini.

Jeśli zauważysz białą stronę (“white screen”), włączanie trybu deweloperskiego bezpośrednio w pliku konfiguracyjnym zazwyczaj pokaże konkretny błąd (np. brakująca klasa, kolizja nazw, błąd składni). Precyzyjna lokalizacja błędu skraca czas naprawy.

Gdzie znaleźć szczegółowe logi

• PrestaShop 1.7 (starsze rewizje): /app/logs/ (pliki prod.log, dev.log).
• PrestaShop 1.7 nowsze i 8: /var/logs/ lub /var/log/ (zależnie od wydania i konfiguracji).
• Panel administracyjny: Zaawansowane parametry → Dziennik – lista zarejestrowanych zdarzeń w obrębie PrestaShop.
• Serwer WWW: logi Apache/Nginx (error.log, access.log) – niekiedy tam widać błędy, które PHP ukrywa.

Utrzymuj porządek: rotacja logów, ograniczenie rozmiaru oraz regularne czyszczenie starych plików. Rozwiązania hostingowe dostarczają często mechanizmy automatycznej rotacji – korzystaj z nich, aby nie zapchać miejsca na dysku.

Włączenie i użycie profilu wydajności

Profilowanie pomaga zrozumieć, które fragmenty kodu i zapytania do bazy zużywają najwięcej czasu. Jeżeli Twoja wersja wspiera wbudowany mechanizm:

• W pliku /config/defines.inc.php dodaj lub ustaw:

  define(’_PS_DEBUG_PROFILING_’, true);

• Odśwież stronę – zobaczysz panel ze statystykami czasu, zapytań SQL i użycia pamięci.

Profilowanie jest szczególnie cenne przy pracy nad problemami “strona wolno się ładuje”, konfliktami w wtyczkach lub nadmiernym renderowaniem komponentów. Pamiętaj, aby wyłączyć je po zakończeniu analizy – to narzędzie jest zasobożerne.

Pasek narzędzi Symfony

W środowiskach z aktywnym APP_ENV=dev i APP_DEBUG=1 pojawi się pasek diagnostyczny Symfony, który umożliwia przegląd zapytań, logów, czasu odpowiedzi i przebiegu żądań. To świetne uzupełnienie profilera PrestaShop, zwłaszcza podczas pracy nad warstwą kontrolerów i integracjami zewnętrznymi.

Cache, kompilacja i praca nad plikami w trybie dev

Ustawienia Smarty i kompilacja szablonów

Podczas wytwarzania frontu ważne jest, aby zmiany w plikach .tpl były widoczne natychmiast. W panelu przejdź do Zaawansowane parametry → Wydajność → Smarty i wybierz:

• Kompilacja szablonów: “Wymuszaj rekompilację przy każdym żądaniu” podczas prac.
• Cache: wyłączony w trakcie developmentu.
• Wyczyść pamięć podręczną: po każdej większej zmianie.

Po zakończeniu pracy wróć do ustawień produkcyjnych: kompiluj szablony “tylko gdy zmienione” oraz włącz buforowanie. Dzięki temu sklep będzie działał szybciej i stabilniej.

Czyszczenie cache: panel, CLI i ręcznie

• Panel administracyjny: Zaawansowane parametry → Wydajność → przycisk Czyszczenie pamięci podręcznej.
• Konsola (1.7/8): w katalogu sklepu wykonaj:

  php bin/console cache:clear –env=dev –no-warmup

  php bin/console cache:clear –env=prod –no-warmup

• Ręcznie: usuń zawartość katalogów cache, zależnie od wersji:
  • /var/cache/dev i /var/cache/prod (nowsze wydania),
  • /app/cache/dev i /app/cache/prod (starsze rewizje 1.7).

Regularne czyszczenie pozwala uniknąć sytuacji, w której przestarzałe pliki szablonów lub konfiguracji blokują wdrożenie poprawek.

Optymalizacje CCC i zasoby statyczne

W trybie deweloperskim wyłącz scalanie i minifikację zasobów (Combine, Compress, Cache), aby łatwiej śledzić zmiany w plikach CSS i JS. W panelu Wydajności ustaw:

• Kompresja i łączenie CSS: wyłączone na czas prac.
• Kompresja i łączenie JavaScript: wyłączone na czas prac.
• Odtwarzanie map źródłowych: włącz po stronie narzędzia bundlującego (np. webpack) dla wygodnego debugowania w przeglądarce.

Na produkcji przywróć pełne łączenie i minifikację, a także włącz przetrzymywanie zasobów w pamięci, CDN lub nagłówki cache-control, aby skrócić czas ładowania.

Baza danych i diagnostyka zapytań

Gdy profilowanie wskazuje na wolne operacje w bazie, przeanalizuj zapytania SQL wyświetlane w narzędziach diagnostycznych. Zwróć uwagę na brakujące indeksy, nieefektywne filtry oraz nadmierne złączenia. W praktyce często pomaga dodanie indeksu do kolumny wielokrotnie używanej w klauzulach WHERE lub ORDER BY. W środowisku testowym możesz włączyć rejestrowanie powolnych zapytań (slow query log) po stronie serwera bazy, aby precyzyjnie wskazać wąskie gardła.

Praca z modułami, motywami i nadpisaniami w trybie dev

Diagnozowanie problemów z modułami

Konflikty rozszerzeń to częsta przyczyna błędów. Włącz tryb deweloperski i kolejno:

• Tymczasowo wyłącz moduły innych autorów w panelu (opcja w sekcji Tryb debugowania).
• Przełączaj moduły pojedynczo, obserwując, kiedy błąd powraca.
• Sprawdź zależności i wersje – część rozszerzeń wymaga konkretnej wersji Core.
• Przejrzyj dzienniki i błędy w przeglądarce – często znajdziesz nazwę klasy lub funkcji powodującej problem.

Własne moduły warto wyposażyć w dodatkowe sprawdzenia wejścia, walidacje i testy integracyjne. Zadbaj też o zgodność z hookami i wersją PHP wykorzystywaną na serwerze.

Motywy: praca nad frontem i podgląd zmian

W trybie deweloperskim motyw powinien natychmiast odzwierciedlać modyfikacje. Włącz wymuszoną rekompilację szablonów i wyłącz buforowanie. Organizuj zasoby CSS/JS tak, by możliwa była szybka podmiana bez restartu całej aplikacji. Jeśli korzystasz z bundlerów, konfiguruj mapy źródeł oraz tryb watch, dzięki czemu przeglądarka pokaże dokładnie, w którym pliku powstał błąd.

Pamiętaj, że poprawki wizualne mogą wpływać na strukturę DOM i inicjalizację skryptów. W razie problemów sprawdź konsolę przeglądarki, eventy i kolejność ładowania plików. Testuj również na kilku przeglądarkach i w trybie prywatnym, aby wykluczyć wpływ rozszerzeń.

Overrides, hooki i kolejność ładowania

PrestaShop pozwala nadpisywać klasy i kontrolery. To potężny mechanizm, ale źle użyty bywa przyczyną trudnych do wykrycia konfliktów. Jeżeli podejrzewasz kolizję, tymczasowo wyłącz nadpisania (opcja w sekcji Tryb debugowania). Sprawdź, czy błąd znika – jeśli tak, przeanalizuj kolejno wprowadzane nadpisania i ich kompatybilność z wersją sklepu.

Własne override planuj ostrożnie: dokumentuj różnice względem oryginału, stosuj najmniejszy możliwy zakres zmian, rozważ alternatywy w postaci rozszerzalnych metod, dziedziczenia lub usarcie kompozycji zamiast nadpisywać całe klasy. Testy regresji pomogą wykryć, czy aktualizacja PrestaShop nie złamała Twoich modyfikacji.

System hooki umożliwia bezinwazyjne wpinanie logiki w ustalone miejsca aplikacji. Przed dodaniem własnej logiki sprawdź, czy odpowiedni hook już istnieje; jeśli nie, oceń, czy Twoje rozszerzenie może działać w innej fazie cyklu żądania. Ustal także priorytety i zależności między modułami korzystającymi z tych samych punktów zaczepienia.

Testy automatyczne i praca zespołowa

W projektach z większą liczbą osób wdrożenie testów jednostkowych i integracyjnych znacząco redukuje liczbę regresji. Rozważ:

• Testy jednostkowe dla kluczowej logiki (np. obliczenia koszyka, reguły promocji).
• Testy e2e (np. z Playwright/Cypress) dla ścieżek krytycznych: rejestracja, logowanie, checkout.
• CI/CD z automatycznym czyszczeniem i odtwarzaniem środowiska testowego, aby wykrywać błędy jeszcze przed merge.

Włączony tryb deweloperski w środowisku CI pomaga szybciej zidentyfikować przyczynę błędów i uzupełnić raporty o szczegółowe informacje diagnostyczne.

Praktyki bezpiecznego wdrażania zmian

• Feature toggles – ukrywaj nowe funkcje za przełącznikami, aby bezpiecznie aktywować je po deploymencie.
• Blue/green lub canary – wdrażaj stopniowo, obserwując metryki działania sklepu i wskaźniki konwersji.
• Natychmiastowa możliwość rollbacku – kopie zapasowe plików i bazy danych, procedury przywracania.

Po udanym wdrożeniu wyłącz tryb deweloperski, włącz buforowanie i ustaw scalanie zasobów. To najlepsza droga, by odzyskać pełną wydajność sklepu.

Kontrola jakości i przegląd logów po wdrożeniu

Po każdej publikacji monitoruj integracje (płatności, wysyłki, ERP), sprawdzaj błędy w dziennikach oraz w narzędziach APM. Gwałtowny wzrost czasu odpowiedzi lub liczby błędów 5xx zwykle sugeruje problem z kompatybilnością rozszerzeń, konfiguracją serwera albo brakującymi indeksami w bazie danych.

Checklisty i szybkie procedury: od włączenia do wyłączenia trybu dev

Szybki start: włącz tryb dev i zacznij diagnozę

• Spróbuj włączyć Debug Mode w panelu: Zaawansowane parametry → Wydajność.
• Gdy panel nie działa, ustaw w /config/defines.inc.php: define(’_PS_MODE_DEV_’, true);
• Wyłącz łączenie CSS/JS, włącz wymuszoną kompilacja szablonów.
• Wyczyść cache i odśwież stronę.
• Obserwuj błędy na froncie; jeśli biała strona – sprawdź dzienniki oraz serwerowe logi.

Diagnoza: zawęź problem

• Wyłącz kolejno rozszerzenia osób trzecich i nadpisania.
• Porównaj zachowanie na domyślnym motywie.
• Włącz profiling, przeanalizuj najwolniejsze zapytania i pętle renderowania.
• Sprawdź zgodność wersji PHP, bibliotek i rozszerzeń serwerowych (np. intl, zip, gd).

Naprawa: wdrażaj poprawki minimalnie inwazyjne

• Wprowadzaj zmiany iteracyjnie i testuj po każdej aktualizacji pliku.
• Jeśli to możliwe, unikaj rozległych nadpisań – postaw na hooki i rozszerzalność.
• Dodaj test reprodukujący błąd, aby zapobiec regresji.

Powrót do produkcji: odwróć zmiany

• Wyłącz Debug Mode i profiler.
• Włącz ponownie buforowanie i CCC, ustaw rozsądne TTL dla zasobów.
• Wyczyść cache i przebuduj mapy zasobów, jeśli ich używasz.
• Przeglądnij logi przez najbliższe godziny/dni i monitoruj obciążenie.

Takie podejście minimalizuje ryzyko długiego przestoju i pozwala zachować pełną kontrolę nad zmianami.

Dodatkowe narzędzia, które ułatwiają życie

• Xdebug – krokowe śledzenie kodu, profilowanie i szybkie znajdowanie źródła błędu.
• Inspector sieci w przeglądarce – analiza timingów, błędów CORS, nagłówków cache-control.
• APM (np. New Relic) – wgląd w opóźnienia na poziomie transakcji i usług zewnętrznych.
• Linters i formatery – spójność kodu, mniej błędów składni i stylu.

Warto zintegrować te narzędzia z procesem CI, by wcześniej wykrywać problemy i skracać pętlę feedbacku. W rezultacie praca nad motywem, modułem czy aktualizacją przebiega sprawniej, a sklep wraca do trybu produkcyjnego w przewidywalnym czasie.

Na zakończenie pamiętaj o kilku złotych zasadach: włączaj tryb deweloperski na możliwie krótką chwilę, ograniczaj jego zasięg do środowisk testowych, zabezpieczaj dostęp, wykonuj kopie zapasowe przed każdą poważną zmianą i dokumentuj konfigurację. Dzięki temu tryb debug pozostaje sprzymierzeńcem, a nie źródłem ryzyka. Gdy opanujesz cykl włącz/diagnozuj/napraw/wyłącz, praca z PrestaShop stanie się przewidywalna i efektywna, a Twoje szablony Smarty i mechanizmy frontu będą zachowywać się zgodnie z oczekiwaniami.

Na co dzień korzystaj z rozsądnych ustawień buforowania i dbaj o ciągłe porządki w projekcie: aktualizuj zależności, weryfikuj kompatybilność z nowymi wersjami PHP, testuj wdrożenia na stagingu. Nawet drobne problemy wykryte wcześnie są tańsze do usunięcia niż rozległe awarie. A kiedy już coś się wydarzy, przełącz tryb, przeczytaj logi, wykonaj poprawkę i wróć do stabilnych ustawień – bez pośpiechu, ale konsekwentnie.