Błąd 500 Internal Server Error w PrestaShop zatrzymuje sklep — klienci nie mogą robić zakupów, właściciel traci przychód z każdą minutą przestoju. Na podstawie zgłoszeń do HelpGuru.eu w 2024 roku: błędy 500 w PrestaShop to 18% wszystkich krytycznych awarii sklepów e-commerce — druga najczęstsza kategoria po problemach z płatnościami.

TL;DR: Błąd 500 w PrestaShop najczęściej powoduje: przepełniony limit pamięci PHP, błąd w pliku .htaccess, uszkodzony override klasy lub niekompatybilny moduł. Diagnoza zajmuje 10 minut z dostępem do logów. Naprawa standardowych przypadków: 30–60 minut. Źródło: HelpGuru.eu, 2024.

Czym różni się błąd 500 w PrestaShop od innych problemów?

HTTP 500 to odpowiedź serwera mówiąca: „coś poszło nie tak po mojej stronie, ale nie powiem ci co”. W PrestaShop błąd 500 może dotyczyć frontendu, panelu administracyjnego lub tylko konkretnego kontrolera — lokalizacja błędu to pierwsza wskazówka diagnostyczna.

Jeśli 500 pojawia się tylko na stronie produktu — szukaj problemu w module lub override ProductController. Tylko w panelu — sprawdź moduły administracyjne i hooków backoffice. Na całej domenie — to zwykle .htaccess, PHP lub baza danych.

Jak włączyć logi błędów PHP w PrestaShop — krok pierwszy diagnostyki

Bez logów naprawiasz w ciemno. PrestaShop w trybie produkcyjnym ukrywa błędy PHP przed użytkownikiem — to dobra praktyka, ale utrudnia diagnozę. Włączenie trybu debug zajmuje 2 minuty i ujawnia 85% przyczyn błędu 500.

Przez FTP lub SSH otwórz config/defines.inc.php. Znajdź linię:

define('_PS_MODE_DEV_', false);

Zmień na:

define('_PS_MODE_DEV_', true);

Alternatywnie edytuj app/config/parameters.php — dodaj lub zmień:

'kernel.environment' => 'dev'

W trybie dev PrestaShop wyświetla pełny stack trace błędu. Logi znajdziesz też w var/logs/ — zarówno logi PrestaShop jak i Symfony.

Jak naprawić błąd 500 w PrestaShop — instrukcja krok po kroku

1. Krok 1: Sprawdź logi PHP i PrestaShop — Przez SSH: tail -f ~/logs/error.log lub sprawdź panel cPanel/DirectAdmin. Logi PrestaShop: var/logs/dev.log (tryb dev) lub var/logs/prod.log. Szukaj linii z Fatal error, Warning lub Class not found.
2. Krok 2: Zwiększ limit pamięci PHP — W pliku .htaccess dodaj: php_value memory_limit 256M. W php.ini: memory_limit = 256M. PrestaShop 8.x i 9.x wymaga minimum 256MB, z WooCommerce lub wieloma modułami — rozważ 512MB.
3. Krok 3: Sprawdź i napraw .htaccess — Pobierz backup pliku .htaccess. Usuń go z serwera. Wejdź do panelu PS → SEO i URL → Zapisz. PrestaShop wygeneruje nowy .htaccess. Jeśli błąd zniknął — oryginalny plik był uszkodzony (np. przez błędny moduł który do niego pisał).
4. Krok 4: Wyłącz moduły przez bazę danych — Jeśli nie możesz zalogować się do panelu PS, wyłącz wszystkie moduły przez SQL: UPDATE `ps_module` SET `active` = 0;. Spróbuj zalogować się do panelu. Aktywuj moduły jeden po jednym.
5. Krok 5: Sprawdź override’y — Przejdź do override/classes/ i override/controllers/. Plik PHP z błędem składni w override = błąd 500. Szybki test: zmień nazwę folderu override na override_backup. Jeśli błąd zniknął — masz uszkodzony override.
6. Krok 6: Wyczyść cache PrestaShop — Usuń zawartość katalogów var/cache/prod/ i var/cache/dev/ przez FTP lub SSH. Wyczyść też katalog smarty/cache/. Następnie przez panel: Parametry zaawansowane → Wydajność → Wyczyść cache.
7. Krok 7: Sprawdź wersję PHP i kompatybilność — PrestaShop 1.7.x wymaga PHP 7.x lub 8.0. PrestaShop 8.x wymaga PHP 8.1. PrestaShop 9.x wymaga PHP 8.2+. Zmiana PHP na wyższą lub niższą wersję bez weryfikacji kompatybilności modułów to najczęstsza przyczyna błędu 500 po migracji serwera.

[INTERNAL-LINK: kompatybilność modułów PrestaShop → lista testowanych modułów dla PS 8.x i 9.x]

Błąd 500 po aktualizacji PrestaShop — specyficzne przypadki

Aktualizacja PrestaShop to jeden z najczęstszych triggerów błędu 500. HelpGuru.eu odnotowuje, że 55% błędów 500 zgłaszanych po aktualizacji PS to konflikty między override’ami a nowym API PrestaShop — szczególnie przy przejściu między major versions (1.7 → 8.x). ([HelpGuru.eu, 2024])

Po aktualizacji sprawdź w pierwszej kolejności: (1) override klasy Cart i Order — one zmieniają się między wersjami, (2) hooków płatności — PayU, Przelewy24 i inne polskie bramki mają osobne wersje dla każdej głównej wersji PS, (3) moduł generowania PDF faktur — korzysta z wewnętrznego renderera który zmienia się przy każdej dużej aktualizacji.

Błąd 500 w trybie wielosklepowym PrestaShop Multistore

W konfiguracji wielosklepowej błąd 500 może pojawiać się tylko w jednym ze sklepów lub tylko w panelu głównym. Sprawdź konfigurację bazy danych — każdy sklep może mieć osobny prefiks tabel. Błąd „Table not found” ukryty jako 500 to klasyczny problem przy niepoprawnej konfiguracji Multistore.

Najczęstsze błędy przy diagnozowaniu błędu 500 w PrestaShop

Błąd 1: Kasowanie override’ów bez backupu. Override może zawierać krytyczną logikę biznesową (np. rabaty B2B, integrację z ERP). Zawsze archiwizuj przed usunięciem.

Błąd 2: Zmiana PHP na „najnowszą dostępną” bez sprawdzenia kompatybilności. PHP 8.3 + stare moduły = nowe błędy. Sprawdź changelog PrestaShop i changelogi modułów pod kątem obsługiwanej wersji PHP.

Błąd 3: Reset parametrów.php bez backupu bazy danych. Plik parameters.php zawiera credentiale do bazy danych. Utrata lub uszkodzenie tego pliku bez backupu = pełna nieoperacyjność sklepu.

Błąd 4: Ignorowanie logów Nginx/Apache. PrestaShop loguje błędy aplikacji, ale błędy na poziomie serwera (np. limit procesów PHP-FPM, przekroczony execution_time) znajdziesz tylko w logach serwera webowego — nie w logach PS.

Często zadawane pytania o błąd 500 w PrestaShop

Czy błąd 500 w PrestaShop może uszkodzić bazę danych?

Sam błąd 500 nie uszkadza bazy danych — to błąd warstwy aplikacji PHP. Ryzyko pojawia się, gdy błąd 500 wystąpi w trakcie zapisu transakcji (np. złożenie zamówienia). W takim przypadku zamówienie może być niekompletne w bazie. Dlatego zawsze sprawdź stan zamówień po każdym incydencie 500.

Błąd 500 pojawia się co jakiś czas, nie stale — co to oznacza?

Sporadyczny błąd 500 to zwykle problem z limitem zasobów serwera: memory_limit, max_execution_time lub max_input_vars. Serwer błęduje pod obciążeniem (duże zamówienia, import produktów, crawl bota). Rozwiązanie: zwiększ limity PHP lub przejdź na hosting z dedykowanymi PHP workers. ([PHP Configuration](https://www.php.net/manual/en/info.configuration.php), 2024)

Ile czasu zajmuje naprawa błędu 500 w PrestaShop?

Standardowe przypadki (moduł, .htaccess, pamięć): 30–60 minut. Złożone (override, Multistore, problem na poziomie serwera): 2–4 godziny. HelpGuru.eu naprawia błędy 500 w ramach usługi pomocy technicznej PrestaShop: 200–249 zł/h, z 26-letnią praktyką w PS (od wersji 1.4).

Czy mogę zapobiec błędom 500 w PrestaShop?

Tak. Trzy działania prewencyjne eliminują 80% incydentów: (1) staging z identyczną konfiguracją PHP przed każdą aktualizacją, (2) automatyczny backup całego sklepu codziennie, (3) monitoring uptime (np. UptimeRobot) z alertem SMS — wykryjesz 500 zanim zrobi to klient.

HelpGuru.eu naprawiło setki błędów 500 w PrestaShop od wersji 1.4 do 9.x. Działamy od 1998 roku, ocena 5.0/5 z 686 recenzji. Kontakt: +48 888 830 888 | [email protected]