Prestashop - jak naprawić error 500 - błąd Prestashop diagnoza problemu

Spis treści

Gdy sklep milknie: co naprawdę oznacza błąd 500 w PrestaShop

Wyobrażasz sobie sytuację: klient właśnie dodał coś do koszyka, a zamiast finalizacji pojawia się biała strona albo komunikat „HTTP ERROR 500”. Sklep milknie. Żadnych szczegółów, żadnej wskazówki, po prostu cisza. W PrestaShop to nie przypadek, system celowo ukrywa błędy przed publicznie widoczną stroną, żeby nie pokazywać potencjalnie wrażliwych informacji o serwerze czy bazie danych.

Dlaczego 500 w PrestaShop pojawia się najczęściej

Błąd 500 to komunikat serwera: coś poszło nie tak po jego stronie, ale bez włączonego trybu deweloperskiego nie dowiesz się co. Najczęściej widzisz go po:

instalacji lub aktualizacji platformy (zwłaszcza skok między wersjami)
włączeniu nowego modułu albo zmianie motywu
ręcznym czyszczeniu cache lub operacjach importu (np. 10 000 produktów naraz)
próbie regeneracji miniatur obrazków

Od wersji 1.7 PrestaShop bazuje na Symfony, więc stos technologiczny jest głębszy, cache ląduje w/var/cache, a od 1.7.6 funkcja displayError() domyślnie zwraca właśnie 500 bez detali. Innymi słowy, musisz sam włączyć debugowanie, żeby zobaczyć prawdziwą przyczynę. Kolejne sekcje pokażą właśnie to: jak uruchomić tryb debug, gdzie szukać logów i jak szybko naprawić najczęstsze problemy z PHP czy uprawnieniami plików.

Diagnostyka: tryb debug, logi i wychwytywanie sedna błędu

Kiedy zobaczysz tylko „500”, masz praktycznie zero informacji. Żeby przejść od tego ogólnika do konkretnego komunikatu, musisz włączyć tryb debug i zajrzeć do logów. To pierwszy krok, bez którego strzelasz na ślepo. Zawsze możesz zadzwonić po wsparcie programisty Prestashop lub sam rozwiązać problem.

Włączenie trybu debug w PrestaShop

Otwórz plik/config/defines.inc.php w edytorze i zmień wartość na:

define('_PS_MODE_DEV_', true);

Zapisz, odśwież stronę. Zamiast białego ekranu dostaniesz teraz szczegółowy komunikat błędu z nazwą klasy, metodą i linią kodu, która padła. W PrestaShop 1.7+ działa stos Symfony, więc zobaczysz też całą trasę wywołań – super pomocne przy identyfikacji, który moduł czy kontroler nawalił.

Uwaga: jeśli nadal widzisz pustą stronę, usuń foldery/var/cache/prod i /var/cache/dev. Cache czasem maskuje błędy i musisz go wyrzucić, żeby system pokazał prawdziwy problem.

Gdzie szukać logów i co w nich znaleźć

PrestaShop pisze logi do/var/logs/ – sprawdź pliki dev.log i prod.log. Znajdziesz tam wyjątki PHP, błędy Symfony, problemy z bazą danych. Serwerowy error_log (lokalizacja zależy od hostingu) też warto sprawdzić, bo tam lądują fatalne błędy PHP, które PrestaShop może nie wyłapać.

W wersji 1.7.6 funkcjadisplayError() potrafi zwrócić 500 bez śladu w logu PrestaShop, wtedy ratuje Cię właśnie error_log serwera.

Mając konkretny komunikat, wiesz już co naprawiać. Bez tego to jak szukanie igły po omacku.

Zgodność środowiska: PHP, limity i rozszerzenia, które ratują przed 500

Zastanawiałeś się kiedyś, dlaczego PrestaShop nagle zaczyna wyrzucać 500 po aktualizacji hostingu? Najczęściej to kwestia środowiska. Twój hosting zmienił PHP z 7.4 na 8.0, a sklep oparty na PS 1.7.7 właśnie przestał działać. Albo moduł do importu przestał działać, bomemory_limit ma zaledwie 128M.

Wersja PHP a wersja PrestaShop

Zgodność PHP to podstawa. PS 1.7.x wymaga PHP 7.2-7.4, choć późniejsze wydania (od 1.7.8) tolerują PHP 8.0. PrestaShop 8.x oficjalnie wspiera PHP 8.0-8.3, ale rekomendowane są najczęściej 8.1 lub 8.2. Problem? Hosting często zmienia wersję PHP automatycznie, bez uprzedzenia. Logujesz się rano, widzisz 500, bo nocą serwer przeskoczył z 7.4 na 8.1. Znany przypadek to „GitHub issue #32400”, gdzie czyszczenie cache w PS 8.0.3 na PHP 8.1 powodowało 500. Sprawdź wersję wphpinfo() lub panelu hostingu, zanim pójdziesz dalej.

Limity i rozszerzenia, bez których pojawia się 500

Twojephp.ini powinno mieć:

memory_limit minimum 256M (512M dla dużych katalogów)
max_execution_time co najmniej 300 sekund (ważne przy importach CSV)
upload_max_filesize 20M+, jeśli dodajesz obrazy

Bez rozszerzeńintl, zip, openssl, curl, gd, pdo_mysql PrestaShop może odmówić posłuszeństwa. Brak intl często daje 500 w backoffice przy włączaniu nowego języka. Sprawdź w phpinfo, czy wszystkie są aktywne. Niektóre hostingi wyłączają zip dla „bezpieczeństwa”, co blokuje instalację modułów.

Uprawnienia, .htaccess i cache: szybkie ruchy, które przywracają sklep

Zanim zaczniesz grzebać w kodzie PHP czy plikach szablonów, warto najpierw sprawdzić rzeczy prozaiczne. Błędne uprawnienia do plików, zepsuty.htaccess albo zaśmiecony cache potrafią wywołać błąd 500 szybciej niż myślisz, a naprawa zajmuje dosłownie minuty.

Prawidłowe prawa dostępu (bez 777)

Widziałem już setki sklepów, gdzie w panice ktoś ustawiłchmod 777 na wszystko, bo „nie działało”. I faktycznie, czasem to pomaga, ale otwiera furtkę dla każdego, kto by chciał podmienić pliki. Bezpieczne wartości to 755 dla katalogów i 644 dla plików. Jeśli masz dostęp SSH, wykonaj:

find . -type d -exec chmod 755 {} \; && find . -type f -exec chmod 644 {} \;

Komenda przejdzie przez cały sklep i ustawi prawidłowe uprawnienia. Czasem wystarczy to, żeby 500 zniknął.

Regeneracja .htaccess i odświeżenie cache

Plik.htaccess potrafi się zepsuć przy zmianie ustawień wielojęzycznych albo po ręcznej edycji. Zrób kopię zapasową, potem zmień mu nazwę (np. na .htaccess_old). Wejdź do panelu administracyjnego, Parametry sklepu > SEO i adresy URL, wyłącz i włącz ponownie „Przyjazne adresy”, zapisz ustawienia. PrestaShop wygeneruje świeży .htaccess z poprawnymi regułami.

Cache to kolejny podejrzany. Usuń całe foldery/var/cache/prod i /var/cache/dev (tak, całe katalogi, nie tylko zawartość). System sam je odbuduje przy kolejnym wejściu na stronę. Często to wystarcza, żeby sklep znów ruszył.

Moduły i motywy: najczęstsze źródła konfliktów po aktualizacjach

Po aktualizacji PrestaShop, zwłaszcza w przeskoku 1.7 → 8.x, najczęściej psuje się właśnie moduł. Dlaczego? Bo nie każdy nadąża za zmianami w jądrze systemu i nowej wersji PHP. Moduły z Marketplace są zazwyczaj bezpieczniejsze, ale te z zewnętrznych repozytoriów albo stare płatne? Tutaj pojawia się problem.

Jak szybko wyłapać winny moduł

Kiedy nie możesz wejść do panelu administracyjnego, wyłączenie modułu wymaga ręcznej interwencji. Najprostszy sposób to zmiana nazwy katalogu modułu w/modules/nazwa na /modules/nazwa_old. PrestaShop go nie załaduje i jeśli był winowajcą, sklep wróci do życia.

Alternatywa to zmiana statusu w bazie danych, w tabelips_module (ustaw kolumnę active na 0 dla podejrzanego modułu). Ostrożnie tutaj, zawsze róbcie kopię zapasową bazy przed edycją.

Strategia zawężania:

Wyłączaj moduły partiami, np. ostatnio zaktualizowane lub te dodane przez zewnętrzne źródła.
Po każdej zmianie testuj front i backend.
Jeśli błąd zniknie, masz zakres winowajców i możesz zawęzić.

Nigdy nie edytuj bazy danych bez pełnego backupu. Jeden błąd w składni SQL i możesz pogorszyć sytuację.

Motyw vs. 500: kiedy wrócić do „classic”

Czasem to nie moduł, a motyw. Po aktualizacji szablony mogą wywoływać błędy, bo odwołują się do nieistniejących już hooków lub klas. Przełącz motyw na domyślny „classic” (przez FTP zmień wapp/config/parameters.php lub tabeli ps_configuration). Jak błąd znika, problem tkwi w szablonie.

Znane przypadki? Moduł „blockreassurance” po przejściu na 8.0 potrafił wywołać 500. Podobnie wtyczki przewoźników typu Omniva. W przypadku 8.0.3 pomocne było ręczne wyczyszczenie cache poprzez zmianę nazwy/var/cache na /var/cache_old.

Trudne przypadki: instalacje 8.x, timeouty, mod_security i inne pułapki

Niektóre błędy 500 w PrestaShop to właściwie osobna kategoria, bo standardowe debugowanie tu nie wystarcza. Mowa o specyficznych scenariuszach, które wymagają konkretnych obejść.

Instalacja i migracja 8.x: znane pułapki

Wersje 8.1.3 i nowsze mają swoje kaprysy. Przykład: upgrade może wywołać 500 przez błędne ścieżki do katalogów lock albo problemy w AppKernel.php. Rozwiązanie: często trzeba ręcznie poprawić ścieżki w tym pliku lub wyczyścić cache na poziomie serwera. To nie jest bug jako taki, raczej specyfika architektury Symfony w PrestaShop 8.x. Sprawdź dokumentację wydania, bo każda podwersja ma swoje niuanse.

Limity, reguły bezpieczeństwa i nietypowe środowiska

Timeouty to klasyk przy dużych operacjach:

Import/eksport 500+ produktów CSV → 500 przez przekroczenie max_execution_time.
Generowanie miniatur całego katalogu → podobnie.
Rozwiązanie: porcjuj dane (partie po 500 rekordów), podnieś limity do 300 sekund i 256M+, ewentualnie skrypt przez CRON.

mod_security potrafi być intruzywny. W 1.7.6.7 zakładka „Positions” wywoływała 500, bo POST przekraczał domyślny limit (często 32 kB). Trzeba zwiększyć do 512 kB lub wyłączyć konkretną regułę przez panel hostingu.

Lokalne środowiska (WAMP, XAMPP) mają swoje dziwactwa. Błąd OPENSSL_CONF blokuje instalację. Po migracji uszkodzone dane SMTP (np. stare konfiguracje Gmail) mogą dawać 500 przy finalizacji zamówienia.

Bazy danych: legacy instalacje czasem mają przestarzałe tabele jak ps_required_field, które powodują konflikty. DROP może pomóc, ale uwaga – backup przed każdą taką operacją. Naprawdę.

Przy tych przypadkach kluczowe jest sprawdzenie forów PrestaShop i changelog wydania. Często ktoś już napotkał identyczny problem i opisał obejście.

Gdy 500 przestaje straszyć: przewaga dzięki świadomej diagnostyce

Kiedy nauczysz się czytać logi tak, jak czytasz komunikaty błędów na co dzień, przestajesz wyciągać plugin po pluginie w nadziei, że któryś zadziała. Zaczynasz działać celnie. To nie brzmi może spektakularnie, ale właśnie ta różnica oddziela tych, którzy naprawiają błąd 500 w pięć minut, od tych, którzy spędzają na tym pół dnia.

Świadoma diagnostyka daje ci coś więcej niż szybsze rozwiązanie problemu. Daje pewność, że rozumiesz swój sklep. Że kiedy następnym razem coś się zepsuje (a zepsuje się, bo to technologia), nie będziesz panikować. Po prostu wejdziesz do logów, zobaczysz co się stało i naprawisz. Bez stresu, bez guglania losowych rozwiązań.

Właściwie to tyle. Błąd 500 przestaje być czarną magią, kiedy wiesz, gdzie szukać odpowiedzi.

PrestaShop – błąd 500: skuteczne metody diagnozy i naprawy