Błąd 500 w PrestaShop oznacza, że serwer nie zdołał poprawnie obsłużyć żądania. Sam komunikat nie wskazuje przyczyny. Zanim zmienisz ustawienia, zapisz adres i godzinę wystąpienia problemu, zabezpiecz aktualny stan sklepu i sprawdź logi. Dopiero konkretny wpis w dzienniku pozwoli odróżnić awarię modułu od problemu z PHP, bazą lub konfiguracją serwera.
Zanim cokolwiek zmienisz
Ustal zakres awarii. Czy nie otwiera się żadna strona, tylko panel administracyjny, czy konkretny krok zamówienia? Sprawdź jeden przykład bez logowania i drugi na koncie testowym. Zanotuj użyty produkt, metodę dostawy oraz czynność poprzedzającą błąd. Jeśli problem dotyczy płatności, nie powtarzaj zakupów na ślepo: najpierw sprawdź, czy operator nie pobrał już pieniędzy.
Zapisz ostatnie zmiany. Aktualizacja modułu, przełączenie PHP, wdrożenie motywu, import produktów i zmiana ustawień hostingu tworzą różne tropy. Godzina zgłoszenia nie musi być godziną początku awarii. Porównaj ją z ostatnimi poprawnymi zamówieniami i logami, żeby nie przypisać problemu zmianie wykonanej już po jego wystąpieniu.
Przed ingerencją wykonaj kopię bazy i plików albo poproś hosting o zabezpieczenie bieżącego stanu. Nie nadpisuj ostatniej sprawnej kopii. Baza z czasu awarii może zawierać zamówienia i płatności, których nie ma we wczorajszym backupie. Jeśli brakuje miejsca na dysku, tworzenie dużego archiwum na tym samym serwerze może pogorszyć sytuację. Wtedy uzgodnij z administratorem inny sposób wykonania kopii.
Gdzie szukać logów
Potrzebne mogą być dzienniki serwera WWW, PHP i samej aplikacji. Na hostingu współdzielonym zacznij od sekcji logów w panelu. Jeśli nie masz do nich dostępu, przekaż obsłudze dokładny adres, godzinę wraz ze strefą czasową i opis czynności. Prośba „sklep nie działa” zostawia znacznie więcej miejsca na zgadywanie.
Na VPS lokalizacja zależy od konfiguracji Apache lub nginx, PHP-FPM i sposobu uruchomienia sklepu. W środowisku kontenerowym część logów może trafiać do wyjścia procesu zamiast do osobnego pliku. W instalacji PrestaShop sprawdź także katalog logów aplikacji, zwykle w obrębie var/logs, uwzględniając używaną wersję i konfigurację. Brak wpisu w jednym miejscu nie oznacza braku błędu.
Szukaj zdarzenia odpowiadającego czasowi próby. Odczytaj pierwszy istotny wyjątek oraz jego otoczenie, nie tylko ostatnią linię. Komunikat o braku klasy może być skutkiem niepełnego wdrożenia, a błąd połączenia z bazą skutkiem jej niedostępności. Zachowaj oryginalny fragment do analizy. Przed przekazaniem go poza uprawniony zespół usuń hasła, tokeny i dane klientów.
Tryb debugowania: jak go użyć
Jeżeli panel działa, tryb debugowania można włączyć w ustawieniach wydajności w parametrach zaawansowanych. Przy braku dostępu do panelu dokumentacja PrestaShop opisuje zmianę stałej _PS_MODE_DEV_ w pliku config/defines.inc.php. Zmień istniejącą definicję, zamiast dopisywać drugą. Sposób konfiguracji przedstawia oficjalna instrukcja debugowania.
Rób to na zabezpieczonej kopii albo w środowisku z ograniczonym dostępem. Szczegółowy komunikat może ujawnić ścieżki, zapytania i informacje o konfiguracji. Włączony debug nie jest sposobem naprawy: pomaga zobaczyć przyczynę. Po zapisaniu potrzebnych danych wyłącz go i sprawdź zachowanie sklepu w zwykłym trybie.
Jeżeli błąd powstaje przed uruchomieniem PHP lub aplikacji, tryb debugowania PrestaShop niczego nie pokaże. W takim przypadku trzeba wrócić do logów serwera i konfiguracji hostingu. Nie zwiększaj liczby zmian tylko dlatego, że na ekranie nadal widzisz ten sam ogólny komunikat.
Jak odróżnić typowe przyczyny
Brak pamięci PHP
Komunikat zawierający Allowed memory size exhausted wskazuje na przekroczenie limitu pamięci procesu. Ustal, jaka czynność do tego doprowadziła. Import dużego pliku i nieskończona pętla w module wymagają innych rozwiązań. Zwiększenie limitu może być uzasadnione, ale dopiero po sprawdzeniu zużycia oraz dostępnych zasobów serwera.
Niezgodność wersji PHP lub rozszerzenia
Jeśli awaria zaczęła się po zmianie środowiska, porównaj wersję PHP z wymaganiami dokładnego wydania sklepu i modułów. Błąd składni, brak funkcji albo niezgodna deklaracja metody to wskazówki do dalszej analizy. Przywrócenie poprzedniej konfiguracji może pomóc odizolować zmianę, ale docelowo potrzebna jest wspierana i zgodna kombinacja oprogramowania.
Moduł, override lub niepełne wdrożenie
Ścieżka do rozszerzenia w stosie wywołań wskazuje miejsce wystąpienia błędu, ale nie zawsze jego źródło. Sprawdź kompletność plików, zależności i ostatnią zmianę. Gdy komunikat dotyczy nadpisanej metody, przyjrzyj się override’om. Samo skopiowanie brakującego pliku z przypadkowej wersji może wprowadzić kolejną niezgodność.
Cache i uprawnienia
Błąd zapisu lub tworzenia pliku może wynikać z nieprawidłowego właściciela katalogu po wdrożeniu. Sprawdź użytkownika procesu PHP i wymagane uprawnienia. Nie ustawiaj masowo 777 na całym sklepie. Jeśli przyczyną są nieaktualne pliki cache, odtwórz je zgodnie z procedurą dla danej wersji, po zachowaniu logów potrzebnych do diagnozy.
Brak miejsca albo niedostępna baza
Sprawdź miejsce na dysku i limit liczby plików. Pełny dysk może uniemożliwić zapis sesji, cache i logów, więc brak nowego komunikatu również bywa objawem. Przy błędach połączenia z bazą zweryfikuj jej dostępność i limity połączeń. Nie uruchamiaj napraw tabel ani nie zmieniaj danych logowania bez potwierdzenia przyczyny.
Gdy błąd pojawił się po aktualizacji
Zatrzymaj kolejne wdrożenia i porównaj stan przed zmianą z aktualnym. Sprawdź wersję pakietu, kompletność plików i informację, czy aktualizacja zmieniła bazę. Cofnięcie wyłącznie kodu może być niewystarczające, jeśli nowa wersja przekształciła dane. Plan wycofania musi uwzględniać oba elementy.
Jeśli logi wskazują jeden moduł, wyłącz go w kontrolowany sposób i powtórz dokładnie tę samą próbę. W wersjach udostępniających odpowiednie polecenie można skorzystać z konsoli PrestaShop; składnię sprawdź w pomocy zainstalowanego wydania. Jeśli aplikacja nie potrafi się uruchomić, konsola też może nie działać. Wtedy potrzebna jest analiza plików, zależności i rejestracji modułu.
Przemianowanie katalogu modułu nie jest uniwersalnym odpowiednikiem jego wyłączenia. Może pozostawić odwołania do klas i konfiguracji. Nie usuwaj też tabel modułu: mogą przechowywać dane potrzebne do rozliczenia zamówień. Po poprawce sprawdź nie tylko stronę, która wcześniej zwracała błąd, ale również zakup, potwierdzenie płatności i przekazanie zamówienia do obsługi.
Kiedy przerwać samodzielne próby
Przekaż diagnozę osobie technicznej, gdy problem dotyczy danych zamówień, podejrzenia włamania, uszkodzenia bazy lub aktualizacji, której nie potrafisz bezpiecznie wycofać. Podobnie postąp, jeśli nie masz sprawnej kopii, a każda kolejna czynność zmienia stan produkcji. Kolejne losowe poprawki utrudniają późniejsze ustalenie przyczyny.
Przygotuj krótkie zgłoszenie: wersja sklepu i PHP, zakres awarii, czas wystąpienia, ostatnie zmiany, przykładowy adres i fragment logu. Dopisz, co już zostało zrobione, także jeśli próba nie pomogła. Dostępy przekaż bezpiecznym kanałem, przez oddzielne konto z zakresem potrzebnym do pracy.
Po usunięciu przyczyny zapisz krótką notatkę: co przestało działać, jaki komunikat potwierdził diagnozę, co zmieniono i jak sprawdzono naprawę. Dołącz informację, czy trzeba obsłużyć zamówienia z czasu awarii. Taki zapis pomoże przy kolejnym zgłoszeniu i pozwoli ustalić, czy problem wraca. Jeśli awaria ujawniła brak monitoringu konkretnej płatności lub integracji, dodaj odpowiednią kontrolę do procedury utrzymania.
Najczęstsze pytania
Czy błąd 500 oznacza utratę danych?
Nie. To informacja o nieudanej obsłudze żądania, a nie o stanie wszystkich danych. Operacja mogła jednak wykonać się częściowo, dlatego przed ponowieniem płatności lub importu trzeba sprawdzić wynik po obu stronach integracji.
Jak wyłączyć moduł bez dostępu do panelu?
Jeśli dana wersja udostępnia działającą komendę konsolową, skorzystaj z niej po sprawdzeniu pomocy. Gdy uruchomienie aplikacji kończy się błędem, sposób postępowania zależy od przyczyny. Nie stosuj przypadkowego zapytania SQL znalezionego dla innego wydania.
Dlaczego sklep działa, a panel administracyjny nie?
Panel i część dostępna klientom uruchamiają różne fragmenty kodu. Awaria może dotyczyć modułu administracyjnego, konkretnego widoku lub uprawnień. Sprawdź osobno logi próby wejścia do panelu.
Czy mogę sam przywrócić kopię zapasową?
Tak, jeśli znasz procedurę i zakres danych, które zostaną zastąpione. Najpierw zabezpiecz bieżący stan oraz zamówienia powstałe po dacie kopii. Pliki, baza i ewentualne zmiany środowiska muszą do siebie pasować.
Najbardziej użyteczny pierwszy krok to znalezienie konkretnego błędu w logu i powiązanie go z czynnością w sklepie. Jeśli potrzebujesz wsparcia przy diagnozie, skorzystaj z pomocy w rozwiązywaniu problemów i dołącz przygotowane informacje.