Błąd 500 w PrestaShop lub biała strona oznacza, że PHP przerwał wykonanie skryptu i nie zwrócił żadnej treści. Najczęstsze przyczyny to wadliwy moduł, wyczerpana pamięć PHP, uszkodzony plik konfiguracyjny, zepsuty cache w katalogu var/cache albo błąd w .htaccess. W IThandy podchodzę do tego metodycznie: zamiast zgadywać, włączam tryb debug, czytam logi i cofam ostatnią zmianę. Dzięki temu sklep MŚP wraca do działania zwykle w kilkadziesiąt minut.
- Najpierw zrób backup plików i bazy - dopiero potem cokolwiek zmieniaj.
- Włącz tryb debug (config/defines.inc.php, _PS_MODE_DEV_), żeby zobaczyć prawdziwy komunikat zamiast pustej strony.
- Logi PrestaShop są w var/logs (dev.log / prod.log), logi PHP i serwera u hostingodawcy.
- 90% awarii 500 wynika z ostatniej zmiany: instalacji modułu, aktualizacji lub edycji pliku.
- Wyczyszczenie var/cache, sprawdzenie pamięci PHP i .htaccess rozwiązuje większość przypadków.
- Jeśli sklep stoi i tracisz sprzedaż, pomagam awaryjnie - zdalnie, z Warszawy.
Zanim zaczniesz: zrób backup
To najważniejsza zasada przy każdej awarii. Zanim zmienisz jakikolwiek plik, edytujesz bazę lub odinstalujesz moduł, wykonaj kopię. Skopiuj pliki sklepu (przez FTP/SSH) oraz zrób eksport bazy danych (np. przez mysqldump albo phpMyAdmin). Bez backupu naprawa może pogłębić problem, a Ty nie masz punktu, do którego można wrócić.
Krok 1: włącz tryb debug
Tryb debug zamienia pustą białą stronę w konkretny komunikat: nazwa pliku, numer linii i treść błędu. To najszybsza droga do przyczyny. Włączam go na czas diagnostyki, a po naprawie zawsze wyłączam - na produkcji debug ujawnia ścieżki i fragmenty kodu, co jest luką bezpieczeństwa.
Alternatywnie, jeśli masz dostęp do panelu administracyjnego, debug włączysz w Parametry zaawansowane > Wydajność > Tryb debugowania. Przy błędzie 500 panel zwykle też nie działa, więc edycja pliku jest pewniejsza.
Krok 2: przeczytaj logi
Komunikat z debugu często wystarcza, ale logi pokazują pełen kontekst i błędy, które nie trafiają na ekran. Sprawdzam dwa źródła naraz: logi PrestaShop i logi serwera.
Logi PrestaShop
- Katalog var/logs w głównym folderze sklepu.
- Plik dev.log (tryb debug) lub prod.log (tryb produkcyjny).
- Pokazują wyjątki aplikacji i błędy modułów.
- Czytaj od końca - najnowszy wpis to zwykle Twoja awaria.
Logi serwera / PHP
- error_log PHP oraz logi serwera (Apache/Nginx) u hostingodawcy.
- Pokazują błędy fatalne PHP, brak pamięci, problemy uprawnień.
- Często widoczne w panelu hostingu lub przez SSH.
- Tu znajdziesz przyczynę, gdy aplikacja nie zdążyła nic zapisać.
Krok 3: co zmieniło się ostatnio
To pytanie rozwiązuje większość zgłoszeń. Sklep nie psuje się sam - coś go zmieniło. Ustal, co działo się tuż przed awarią:
- Instalacja lub aktualizacja modułu - najczęstszy sprawca błędu 500. Jeśli masz dostęp do bazy, możesz dezaktywować podejrzany moduł albo usunąć/zmienić nazwę jego folderu w katalogu modules.
- Aktualizacja PrestaShop - niedokończona migracja lub niezgodny moduł po podbiciu wersji.
- Edycja pliku - literówka w PHP, zła zmiana w szablonie child theme, niepoprawny .htaccess.
- Zmiana po stronie hostingu - nowa wersja PHP, niższy limit pamięci, zmiana ścieżek.
Krok 4: pamięć PHP i limity
Jeśli logi pokazują komunikat typu "Allowed memory size exhausted", problemem jest limit pamięci PHP. PrestaShop 9.1 przy większym katalogu i kilku modułach potrzebuje zapasu. Sprawdzam i podnoszę kluczowe parametry PHP.
Limity zmienia się w php.ini, pliku .user.ini albo w panelu hostingu. Po zmianie odśwież stronę i ponownie zajrzyj do logów - czasem jeden błąd zasłaniał kolejny.
Krok 5: cache i uprawnienia
Zepsuty lub niespójny cache potrafi blokować cały sklep, zwłaszcza po aktualizacji lub zmianie szablonu. Wyczyszczenie go jest bezpieczne i często wystarcza.
Krok 6: .htaccess i baza danych
Jeśli błąd 500 dotyczy całego sklepu, a nie pojedynczej strony, podejrzewam .htaccess. Tymczasowo zmień jego nazwę (np. na .htaccess_old) i odśwież sklep. Jeśli zaczyna działać, plik jest uszkodzony - wygeneruj go ponownie w panelu (Parametry zaawansowane > Ruch sieciowy i SEO > Wygeneruj plik .htaccess) po przywróceniu dostępu do panelu.
Gdy logi wskazują na połączenie z bazą (np. "Link to database cannot be established"), sprawdź dane dostępowe w pliku app/config/parameters.php: nazwę bazy, użytkownika, hasło i host. Po stronie hostingu mogła zmienić się nazwa hosta bazy lub hasło.
Checklista diagnostyczna błędu 500
| Krok | Co sprawdzam | Gdzie |
|---|---|---|
| 0 | Backup plików i bazy | FTP/SSH + eksport bazy |
| 1 | Tryb debug | config/defines.inc.php (_PS_MODE_DEV_) |
| 2 | Logi aplikacji i serwera | var/logs, error_log PHP, logi hostingu |
| 3 | Ostatnia zmiana: moduł / aktualizacja / plik | katalog modules, historia zmian |
| 4 | Pamięć PHP i limity | php.ini / panel hostingu |
| 5 | Cache i uprawnienia | var/cache, uprawnienia katalogów |
| 6 | .htaccess i połączenie z bazą | .htaccess, app/config/parameters.php |
Kiedy poprosić o pomoc
Jeśli przeszedłeś checklistę, a sklep dalej zwraca błąd 500, problem może leżeć głębiej: niezgodność modułu z wersją PrestaShop, uszkodzona tabela w bazie albo niedokończona aktualizacja. Wtedy lepiej nie eksperymentować na produkcji. Zajmuję się tym na co dzień - diagnozuję awarię, przywracam sklep i zabezpieczam go przed powtórką. Pracuję zdalnie, więc pomoc dociera szybko, bez dojazdu.
Stałą opiekę nad sklepem opisuję w usłudze opieka i utrzymanie sklepu - obejmuje monitoring, backupy i bezpieczne aktualizacje, dzięki którym błąd 500 zdarza się rzadziej. O bezpieczeństwie i zapobieganiu awariom piszę też w artykule bezpieczeństwo sklepu PrestaShop - checklista.
Twój sklep PrestaShop zwraca błąd 500 albo białą stronę i tracisz sprzedaż? Pomagam awaryjnie - diagnozuję i przywracam działanie zdalnie.
Zapytaj o wycenę
Administrator IT i wykonawca e-commerce. Warszawa i zdalnie.
FAQ
Czym różni się błąd 500 od białej strony w PrestaShop?
To zwykle ten sam problem widziany w dwóch trybach. Przy włączonym trybie debug zobaczysz komunikat błędu z nazwą pliku i linią, a przy wyłączonym - pustą, białą stronę lub komunikat "Internal Server Error". Dlatego diagnostykę zaczynam od włączenia debugu, żeby zamienić białą stronę na czytelny komunikat.
Jak włączyć tryb debug w PrestaShop 9.1?
Otwórz plik config/defines.inc.php przez FTP lub SSH, znajdź linię define('_PS_MODE_DEV_', false); i zmień false na true. Po naprawie ustaw z powrotem false, bo debug na produkcji ujawnia ścieżki i fragmenty kodu. Jeśli panel działa, debug włączysz też w Parametry zaawansowane > Wydajność.
Gdzie są logi PrestaShop?
Logi aplikacji znajdziesz w katalogu var/logs w głównym folderze sklepu - plik dev.log w trybie debug lub prod.log w trybie produkcyjnym. Oprócz nich warto sprawdzić logi PHP (error_log) i logi serwera Apache lub Nginx, dostępne w panelu hostingu albo przez SSH.
Czy mogę sam naprawić błąd 500, czy lepiej zlecić to specjaliście?
Proste przypadki - wadliwy moduł, brak pamięci PHP, zepsuty cache - da się rozwiązać samodzielnie, jeśli najpierw zrobisz backup i pójdziesz checklistą. Jeśli przyczyna leży w bazie, niedokończonej aktualizacji albo niezgodności modułów, lepiej nie eksperymentować na działającym sklepie i poprosić o pomoc. Wtedy działam awaryjnie i zdalnie.
Jak zapobiec błędom 500 w przyszłości?
Najważniejsze to: testować aktualizacje i nowe moduły poza produkcją, robić regularne backupy, trzymać zapas pamięci PHP i nie edytować plików core. To dokładnie elementy, które wpisuję w stałą opiekę nad sklepem - dzięki nim awarie zdarzają się rzadziej, a gdy wystąpią, szybciej wracam do działania z kopii.
Ile trwa naprawa błędu 500 w PrestaShop?
Typową awarię - moduł, cache, limit pamięci - diagnozuję i usuwam zwykle w kilkadziesiąt minut. Głębsze problemy z bazą czy niedokończoną aktualizacją mogą zająć dłużej, ale zawsze zaczynam od przywrócenia sklepu do działania, a dopiero potem zabezpieczam go przed powtórką.