Błąd 500 w PrestaShop albo biała strona prawie zawsze oznacza błąd krytyczny PHP, którego sklep nie pokazuje odwiedzającym. Żeby znaleźć przyczynę, włącz tryb debugowania (w panelu albo w pliku config/defines.inc.php), przeczytaj ostatnie wpisy w logach PHP i w katalogu var/logs, a potem kolejno: wyczyść var/cache, wyłącz override'y i podejrzany moduł, sprawdź wersję PHP i limit pamięci. Zwykle już komunikat błędu wskazuje winny plik. Poniżej znajdziesz całą procedurę w formie checklisty.
- Co oznacza błąd 500 lub biała strona w PrestaShop?
- Zanim zaczniesz: co zmieniło się ostatnio?
- Jak włączyć tryb debugowania w PrestaShop?
- Gdzie szukać logów błędów PrestaShop?
- Najczęstsze przyczyny błędu 500 i jak je naprawić
- Kiedy przywrócić sklep z kopii zapasowej?
- Checklista: błąd 500 w PrestaShop w 10 minut
- Najczęściej zadawane pytania
Co oznacza błąd 500 lub biała strona w PrestaShop?
Kod 500 (Internal Server Error) to ogólna informacja serwera: „coś poszło nie tak, ale nie powiem co”. W PrestaShop najczęściej stoi za nim błąd krytyczny PHP (Fatal error), który zatrzymuje generowanie strony. Na sklepie produkcyjnym wyświetlanie błędów jest wyłączone, więc zamiast komunikatu widzisz pustą stronę albo ogólny ekran błędu serwera.
Typowe wyzwalacze:
- instalacja lub aktualizacja modułu albo motywu,
- aktualizacja PrestaShop lub zmiana wersji PHP przez hosting,
- ręczna edycja plików (override, szablon,
.htaccess), - przepełniony dysk, skończony limit pamięci lub limit czasu wykonania,
- rzadziej: zmodyfikowane pliki po włamaniu.
Ważna wskazówka: zwróć uwagę, gdzie pojawia się błąd. Jeśli pada tylko jedna strona (np. karta produktu albo koszyk), winny jest zwykle moduł podpięty do tej strony. Jeśli nie działa ani sklep, ani panel, problem leży głębiej: w override, w konfiguracji PHP albo w uszkodzonym cache.
Zanim zaczniesz: co zmieniło się ostatnio?
Najszybsza diagnoza to pytanie: co zmieniło się tuż przed awarią? Nowy moduł, aktualizacja, zmiana PHP w panelu hostingu, edycja pliku przez agencję? Jeśli znasz odpowiedź, często wystarczy cofnąć tę jedną zmianę.
Zanim cokolwiek usuniesz lub zmienisz nazwę: skopiuj plik lub katalog, którego dotykasz. Nie usuwaj modułów ani tabel w bazie w ramach diagnozy. Kopia całego sklepu przed eksperymentami to najlepsza polisa.
Jak włączyć tryb debugowania w PrestaShop?
Tryb debugowania sprawia, że zamiast białej strony zobaczysz treść błędu: komunikat, plik i numer linii. To pierwszy i najważniejszy krok.
Z panelu administracyjnego
Jeśli panel działa, przejdź do Zaawansowane → Wydajność i w sekcji Tryb debugowania ustaw Tryb debugowania: Tak, a potem zapisz. Opcja działa tak samo w PrestaShop 1.7, 8 i 9 i w rzeczywistości zapisuje ustawienie do pliku config/defines.inc.php.
W PrestaShop 9 w tej samej sekcji są pola Nazwa ciasteczka debugowania i Wartość ciasteczka debugowania. Pozwalają włączyć debugowanie tylko dla przeglądarki, która ma ustawione to ciasteczko, a nie dla wszystkich klientów.
Z pliku config/defines.inc.php
Gdy panel też pokazuje błąd 500, zaloguj się przez FTP, SSH lub menedżer plików hostingu i otwórz config/defines.inc.php. Na początku pliku znajdziesz linię define('_PS_MODE_DEV_', false);. Zmień false na true, zapisz i odśwież stronę. Ścieżka i nazwa stałej są takie same w PrestaShop 1.7, 8 i 9.
Jeśli zmiana nic nie daje, sprawdź, czy w katalogu config/ istnieje plik defines_custom.inc.php. PrestaShop wczytuje go wcześniej, więc zdefiniowane w nim _PS_MODE_DEV_ ma pierwszeństwo.
Pamiętaj: tryb debugowania pokazuje szczegóły błędów (ścieżki plików, fragmenty zapytań) każdemu odwiedzającemu i spowalnia sklep. Po znalezieniu przyczyny od razu go wyłącz.
Gdzie szukać logów błędów PrestaShop?
Gdy nie chcesz włączać debugowania na żywym sklepie albo komunikat jest niejasny, przeczytaj logi. Szukaj wpisów z godziny, o której wystąpił błąd, i linii zawierających PHP Fatal error, Uncaught lub CRITICAL.
| Log | Gdzie go znaleźć | Co w nim jest |
|---|---|---|
| Logi PrestaShop (1.7) | var/logs/prod.log (przy debugowaniu dev.log) |
błędy Symfony, głównie panelu i nowych stron |
| Logi PrestaShop (8 i 9) | var/logs/prod-RRRR-MM-DD.log, osobny plik na każdy dzień |
jak wyżej |
| Log błędów PHP | ścieżka z ustawienia error_log, zwykle w panelu hostingu |
błędy krytyczne PHP, w tym limit pamięci |
| Log serwera WWW | np. /var/log/apache2/error.log, /var/log/nginx/error.log |
błędy .htaccess, PHP-FPM, przekroczone czasy |
| Logi w panelu | Zaawansowane → Logi | zdarzenia zapisane przez sklep i moduły, gdy panel działa |
Na serwerze z dostępem SSH bezpiecznie podejrzysz koniec logu poleceniem tail -n 50 /var/log/nginx/error.log (podmień ścieżkę na swoją). Na hostingu współdzielonym logi zwykle są w panelu, w zakładce typu „Logi” lub „Statystyki”. W bardzo starych wydaniach 1.7 (sprzed 1.7.4) logi i cache były w app/logs i app/cache zamiast w var/.
Gdy w komunikacie widzisz ścieżkę zaczynającą się od modules/nazwa_modulu/, override/ albo themes/nazwa_motywu/, masz już winowajcę. Dalsze kroki zależą od tego, co to za plik.
Najczęstsze przyczyny błędu 500 i jak je naprawić
Uszkodzony lub nieaktualny cache
Po aktualizacji, przeniesieniu sklepu albo ręcznej zmianie plików cache potrafi wskazywać na nieistniejące klasy. Jeśli panel działa, użyj przycisku Wyczyść pamięć podręczną w Zaawansowane → Wydajność. Jeśli nie, usuń zawartość katalogów var/cache/prod i var/cache/dev (same katalogi zostaw). PrestaShop odbuduje cache przy następnym wejściu, więc pierwsze ładowanie potrwa dłużej. Nie usuwaj niczego poza var/cache.
Override, który nie pasuje do wersji PrestaShop
Override'y (katalog override/) nadpisują klasy jądra. Po aktualizacji PrestaShop stary override często wywołuje metodę, która już nie istnieje albo ma inną sygnaturę.
- Z panelu: Zaawansowane → Wydajność → Tryb debugowania → Wyłącz wszystkie nadpisywania: Tak.
- W PrestaShop 1.7 w tej samej sekcji jest też opcja Wyłącz moduły nie od PrestaShop, która tymczasowo wyłącza wszystkie moduły spoza dystrybucji. W PrestaShop 8 i 9 tej opcji już nie ma.
- Bez panelu: zmień nazwę konkretnego pliku wskazanego w błędzie (np.
override/classes/Cart.phpnaCart.php.off), a potem usuń plikclass_index.phpzvar/cache/prod(orazvar/cache/dev), żeby PrestaShop przebudował mapę klas.
Moduł, który się wysypał
Jeśli błąd wskazuje moduł, a panel działa, wyłącz go w Moduły → Menedżer modułów. Gdy panel nie działa, zmień nazwę katalogu modułu, np. modules/jakis_modul na modules/jakis_modul_off. PrestaShop nie znajdzie wtedy jego plików i pominie go przy ładowaniu strony. Po naprawie przywróć oryginalną nazwę.
Nie usuwaj katalogu i nie odinstalowuj modułu w panicy: deinstalacja może skasować jego dane i ustawienia. Jeżeli moduł ma też własne override'y, wyłącz je jak w punkcie wyżej.
Wersja PHP nie pasuje do PrestaShop
Hosting zmienił wersję PHP albo sklep przeniesiono na nowy serwer? To bardzo częsta przyczyna. PrestaShop 1.7 oficjalnie obsługuje PHP najwyżej w wersji 7.4, a PrestaShop 9 wymaga co najmniej PHP 8.1. Sprawdź wymagania swojej wersji w oficjalnej dokumentacji i porównaj z wersją ustawioną w panelu hostingu. Bieżącą wersję PHP i limit pamięci zobaczysz w Zaawansowane → Informacja, o ile panel działa.
Jeśli sklep jest na wersji, która nie obsługuje aktualnego PHP, przywróć poprzednie PHP i zaplanuj aktualizację sklepu. Jak przejść ją bez utraty danych, opisujemy w poradniku aktualizacja PrestaShop krok po kroku. Moduły też mają swoje wymagania: stary moduł potrafi wywrócić sklep na nowym PHP mimo poprawnej wersji jądra.
Brak pamięci lub przekroczony czas
Komunikat Allowed memory size of ... bytes exhausted oznacza, że skończył się limit memory_limit. Dla PrestaShop zwykle zaleca się co najmniej 256M; zmienisz go w panelu hostingu lub w konfiguracji PHP. Gdy błąd pojawia się tylko przy imporcie, generowaniu miniatur czy dużych eksportach, może chodzić też o max_execution_time. Podnoszenie limitu leczy jednak tylko objaw, jeśli zwykła strona kategorii zjada kilkaset megabajtów, coś w kodzie robi za dużo.
Plik .htaccess, uprawnienia i dysk
Na Apache błędna dyrektywa w .htaccess daje błąd 500 jeszcze przed uruchomieniem PHP, a przyczynę zobaczysz tylko w logu serwera. Wygeneruj plik ponownie w Preferencje → Ruch → SEO & URL, zapisując ustawienia (najpierw zachowaj kopię starego pliku). Sprawdź też, czy dysk nie jest pełny i czy katalogi var/ mają prawa zapisu dla użytkownika serwera.
Jeżeli w logach widzisz pliki, których nikt nie dodawał, albo kod w miejscach, których nikt nie edytował, potraktuj to jako możliwe włamanie. Co wtedy robić, opisujemy we wpisie o bezpieczeństwie PrestaShop.
Kiedy przywrócić sklep z kopii zapasowej?
Przywracanie kopii ma sens, gdy:
- sklep przestał działać po aktualizacji, a nie masz czasu na naprawę w trakcie sprzedaży,
- zmian było wiele i nie wiadomo, która jest winna,
- pliki lub baza zostały uszkodzone albo zmodyfikowane przez osoby trzecie.
Przywracaj zawsze pliki i bazę danych z tego samego momentu, bo kopia samych plików z nowszą bazą (lub odwrotnie) potrafi wywołać kolejne błędy. Pamiętaj, że zamówienia złożone po wykonaniu kopii trzeba będzie odtworzyć. Rób kopię przed każdą aktualizacją i sprawdź, jakie kopie robi hosting i jak je przywrócić.
Checklista: błąd 500 w PrestaShop w 10 minut
- Ustal, co zmieniło się tuż przed awarią, i czy nie działa cały sklep, czy jedna strona.
- Włącz tryb debugowania (panel albo
_PS_MODE_DEV_wconfig/defines.inc.php) i odśwież stronę. - Przeczytaj ostatnie wpisy w
var/logs, logu PHP i logu serwera WWW. - Wyczyść cache: przycisk w panelu albo zawartość
var/cache/prodivar/cache/dev. - Wyłącz override'y; bez panelu zmień nazwę pliku i usuń
class_index.php. - Wyłącz moduł wskazany w błędzie; bez panelu zmień nazwę jego katalogu.
- Sprawdź wersję PHP i
memory_limitw panelu hostingu. - Przejrzyj
.htaccess, wolne miejsce na dysku i prawa zapisu dovar/. - Gdy nic nie pomaga, przywróć pliki i bazę z jednej kopii.
- Wyłącz tryb debugowania i przetestuj zakup od koszyka do płatności.
Jeśli nie czujesz się pewnie w plikach na serwerze albo sklep musi wrócić jak najszybciej, możesz zlecić diagnozę w ramach prac programistycznych.
Najczęściej zadawane pytania
Dlaczego sklep PrestaShop pokazuje białą stronę bez żadnego błędu?
Bo na produkcji wyświetlanie błędów jest wyłączone. PHP zatrzymuje się na błędzie krytycznym, a przeglądarka dostaje pustą odpowiedź lub kod 500. Treść błędu zobaczysz po włączeniu trybu debugowania albo w logu PHP.
Czy mogę zostawić włączony tryb debugowania?
Nie. Tryb debugowania spowalnia sklep i pokazuje odwiedzającym szczegóły techniczne, które ułatwiają atak. Włącz go tylko na czas diagnozy, a w PrestaShop 9 rozważ ograniczenie go ciasteczkiem debugowania.
Czy usunięcie var/cache jest bezpieczne?
Usunięcie zawartości var/cache/prod i var/cache/dev jest bezpieczne: PrestaShop odbuduje cache sam. Pierwsze wejście na stronę potrwa dłużej. Nie usuwaj innych katalogów z var/ ani plików poza cache.
Błąd 500 pojawia się tylko w panelu administracyjnym. Co robić?
Sprawdź log w var/logs, bo panel w dużej części działa na Symfony i tam zapisuje błędy. Częste przyczyny to nieaktualny cache po aktualizacji, moduł dodający własną zakładkę w panelu oraz zbyt niski limit pamięci.
Ile trwa naprawa błędu 500?
Jeśli winny jest cache, override albo jeden moduł, często wystarczy kilkanaście minut. Gdy błąd wynika z niezgodności wersji PHP lub nieudanej aktualizacji, naprawa może zająć kilka godzin i wymaga pracy na kopii sklepu.
Sklep nadal pokazuje błąd 500? Napisz do nas i dołącz treść błędu z logu.
Produkty z tego wpisu
