WordPress – błąd 500. Jak debugować stronę?

Wchodzisz na stronę WordPress, a zamiast treści pojawia się 500 Internal Server Error? Sam komunikat niewiele wyjaśnia. Informuje, że serwer nie był w stanie poprawnie obsłużyć żądania, ale nie wskazuje jeszcze, czy problem powoduje wtyczka, motyw, PHP, plik .htaccess, przekroczony limit czy inny element konfiguracji.

Dlatego przy błędzie 500 najważniejsze jest nie zgadywanie, ale debugowanie WordPressa i sprawdzenie logów. W tym poradniku pokażemy Ci, jak znaleźć źródło problemu, również korzystając z narzędzi dostępnych klientom cyber_Folks.

Jeśli korzystasz z cyber_Folks, zwróć uwagę, z którego panelu administracyjnego korzysta Twoja usługa. Poniżej znajdziesz instrukcję dla direct_Admin oraz aktualną ścieżkę dla cyber_Admin.

Co oznacza błąd 500 w WordPress?

Błąd 500 Internal Server Error jest kodem odpowiedzi HTTP z grupy błędów serwera. Oznacza, że żądanie użytkownika dotarło do serwera, ale podczas jego przetwarzania wystąpił problem uniemożliwiający wygenerowanie prawidłowej odpowiedzi.

W przeciwieństwie do błędu 404, który najczęściej oznacza brak konkretnego zasobu, sam kod 500 nie wskazuje przyczyny. To raczej sygnał, że trzeba zajrzeć głębiej – przede wszystkim do logów serwera oraz informacji generowanych przez WordPress i PHP.

W WordPressie do częstych źródeł HTTP 500 należą:

• błąd PHP we wtyczce, motywie lub własnym kodzie,
• konflikt po aktualizacji WordPressa lub rozszerzenia,
• niekompatybilność z używaną wersją PHP,
• nieprawidłowe reguły w pliku .htaccess,
• przekroczenie limitu pamięci albo czasu wykonywania skryptu,
• nieprawidłowe uprawnienia plików i katalogów,
• uszkodzone lub brakujące pliki,
• problem z konfiguracją serwera,
• infekcja lub niepożądana modyfikacja kodu strony.

Błąd nie musi obejmować całej strony. Może pojawić się tylko podczas logowania do wp-admin, zapisywania wpisu, realizacji zamówienia WooCommerce, importu danych czy wykonania zadania CRON. Zanotuj więc dokładnie, przy jakiej czynności występuje problem. To cenna wskazówka podczas analizy logów.

Zanim zaczniesz debugować WordPress – zabezpiecz stronę

Przed zmianą konfiguracji sprawdź, co wydarzyło się bezpośrednio przed awarią. Czy aktualizowałeś wtyczkę? Zmieniłeś wersję PHP? Edytowałeś functions.php lub .htaccess? Zainstalowałeś nowy motyw? Jeśli błąd pojawił się kilka minut po konkretnej zmianie, masz już pierwszy trop.

Przed edycją plików wykonaj również backup plików i bazy danych. Oficjalna dokumentacja WordPressa rekomenduje wykonanie kopii albo prowadzenie diagnostyki na środowisku testowym.

Jeśli korzystasz z hostingu WordPress cyber_Folks, masz dodatkowe zabezpieczenie w postaci automatycznych kopii. W aktualnej ofercie hostingu WordPress kopie treści wykonywane są co 6 godzin i mogą być dostępne do 28 dni wstecz. Szczegółowe informacje znajdziesz w poradniku Backup WordPress – jak i dlaczego go wykonywać?.

Ważne: nie przywracaj automatycznie całej strony do wcześniejszej wersji, jeśli możesz szybko znaleźć problem w logach. W sklepie internetowym cofnięcie backupu może oznaczać również cofnięcie nowych zamówień lub zmian wykonanych po utworzeniu kopii.

Jak zdebugować WordPress w direct_Admin?

Jeżeli Twoja usługa korzysta z panelu direct_Admin, możesz wykonać diagnostykę według poniższej procedury.

Sprawdź wersję PHP używaną przez domenę

Zaloguj się do panelu, wybierz domenę, na której działa WordPress, a następnie w sekcji Serwer WWW i domeny przejdź do pozycji Wersja PHP dla domen. Zanotuj wersję PHP przypisaną do witryny.

Następnie przejdź do sekcji Pozostałe ustawienia → PHP – ustawienia globalne.

Otwórz zakładkę Opcje.

Sprawdź, czy w tym miejscu wybrana jest ta sama wersja PHP, którą wcześniej odczytałeś dla domeny. W ustawieniach znajduje się także parametr display_errors.

Nie zostawiaj display_errors włączonego na publicznej stronie. Wyświetlane komunikaty mogą ujawniać ścieżki do plików i inne informacje techniczne. Jeżeli tylko masz taką możliwość, bezpieczniej jest zapisywać błędy do logu i nie pokazywać ich odwiedzającym. Do publicznego wyświetlenia komunikatu używaj tej opcji wyłącznie tymczasowo podczas diagnostyki.

Znajdź katalog, z którego działa WordPress

Wróć do ustawień domeny. W sekcji Serwer WWW i domeny wybierz Przypisz katalog domeny. Dzięki temu upewnisz się, z którego katalogu faktycznie serwowana jest witryna.

Następnie otwórz Menadżer plików i przejdź do wskazanego katalogu. W standardowym układzie direct_Admin może to być:

domains → twojadomena.pl → public_html

W katalogu instalacji WordPressa odszukaj plik wp-config.php i wybierz jego edycję.

Włącz WP_DEBUG i zapisuj błędy do debug.log

Instrukcja cyber_Folks pokazuje zmianę wartości WP_DEBUG z false na true. Warto pójść o krok dalej i włączyć również zapis komunikatów do pliku, bez pokazywania ich użytkownikom.

W wp-config.php ustaw:

define( 'WP_DEBUG', true ); 
define( 'WP_DEBUG_LOG', true ); 
define( 'WP_DEBUG_DISPLAY', false ); 
@ini_set( 'display_errors', 0 );

Wpis powinien znajdować się przed komentarzem kończącym część konfiguracyjną WordPressa. Szczegóły znajdziesz w oficjalnej dokumentacji Debugging in WordPress.

Teraz ponownie wykonaj operację powodującą HTTP 500. WordPress powinien zapisać komunikaty do pliku:

/wp-content/debug.log

Po zakończeniu diagnostyki ustaw ponownie WP_DEBUG na false. Nie trzymaj debugowania aktywnego bez potrzeby na działającej stronie.

Korzystasz z cyber_Admin? Tutaj znajdziesz logi i ustawienia PHP

Jeżeli korzystasz z nowszego panelu cyber_Admin, nie szukaj dokładnie tych samych ekranów, które pokazuje starsza instrukcja direct_Admin. Najważniejsze narzędzia są dostępne bezpośrednio w ustawieniach witryny.

Najpierw otwórz ERROR log

W menu cyber_Admin przejdź do Serwer WWW → Strony WWW. Kliknij nazwę strony lub wybierz jej edycję. Następnie w menu ustawień wybierz Logi bieżące.

Przy domenie zobaczysz przyciski ACCESS oraz ERROR. Do diagnozowania błędu 500 najbardziej interesuje Cię ERROR, czyli bieżący error.log.

Logi są zbierane na bieżąco. Otwórz error.log, następnie w drugiej karcie wywołaj ponownie błąd 500 i odśwież log. Dzięki temu łatwiej powiążesz konkretny komunikat z problemem, który właśnie wystąpił.

Pełną instrukcję znajdziesz na stronie Jak sprawdzić logi?. W cyber_Admin dostępne są również archiwalne logi w katalogu logs w Menedżerze plików.

Sprawdź PHP w cyber_Admin

Jeżeli log sugeruje problem z PHP albo błąd pojawił się po zmianie jego wersji, otwórz Serwer WWW → Strony WWW, wybierz stronę i przejdź do zakładki Ustawienia PHP.

Możesz tam sprawdzić wersję PHP oraz najważniejsze parametry, m.in. log_errors, display_errors, memory_limit, max_execution_time czy open_basedir.

Nie zmieniaj jednak kilku parametrów jednocześnie bez konkretnego powodu. Jeśli log wskazuje np. Allowed memory size exhausted, wtedy warto sprawdzić memory_limit. Jeśli problem pojawił się po zmianie wersji PHP, zacznij od sprawdzenia kompatybilności WordPressa, motywu i wtyczek.

Dokładny opis znajdziesz w pomocy Jak zmienić ustawienia PHP w panelu cyber_Admin.

Co znajdziesz w error.log i debug.log?

Po włączeniu debugowania masz dwa główne źródła informacji. error.log pokazuje błędy występujące podczas obsługi żądań przez serwer i PHP, natomiast wp-content/debug.log zbiera komunikaty rejestrowane przez mechanizm debugowania WordPressa.

Szukaj przede wszystkim wpisu odpowiadającego godzinie, w której ponownie wywołałeś problem. Szczególną uwagę zwróć na komunikaty zawierające:

• PHP Fatal error – krytyczny błąd PHP, który zatrzymał wykonywanie skryptu,
• Uncaught Error lub Uncaught TypeError – nieobsłużony błąd w kodzie,
• Allowed memory size exhausted – przekroczenie limitu pamięci PHP,
• Maximum execution time exceeded – przekroczony czas wykonywania skryptu,
• Parse error lub syntax error – problem ze składnią kodu,
• ścieżkę prowadzącą do katalogu /plugins/ albo /themes/ – możliwy trop prowadzący do wtyczki lub motywu.

Przykładowo, jeżeli wpis kończy się ścieżką:

/wp-content/plugins/nazwa-wtyczki/plik.php

nie oznacza to jeszcze ze stuprocentową pewnością, że sama wtyczka jest wadliwa, ale właśnie od niej warto rozpocząć dalsze sprawdzanie. Mogła wejść w konflikt z innym rozszerzeniem, wersją PHP albo kodem motywu.

Porada: nie analizuj tylko ostatniej linijki logu. Błąd krytyczny może być poprzedzony innym komunikatem, który lepiej wyjaśnia, co doprowadziło do awarii.

Log wskazuje problem. Jak naprawić najczęstsze przyczyny błędu 500?

Wtyczka powoduje błąd 500

Jeśli błąd pojawił się po aktualizacji lub instalacji wtyczki i log wskazuje jej katalog, wyłącz właśnie to rozszerzenie. Gdy masz dostęp do kokpitu, zrobisz to standardowo w WordPressie.

Jeżeli wp-admin również zwraca 500, przejdź do /wp-content/plugins/ przez Menadżer plików lub SFTP i tymczasowo zmień nazwę folderu problematycznej wtyczki, np. z:

nazwa-wtyczki na nazwa-wtyczki-off

WordPress nie będzie mógł jej załadować. Jeżeli strona zacznie działać, sprawdź następnie aktualizacje, wymagania PHP i dokumentację rozszerzenia.

Problem znajduje się w .htaccess

Nieprawidłowa dyrektywa w .htaccess może spowodować błąd serwera. Jeżeli problem wystąpił po zmianie tego pliku, zrób jego kopię i testowo zmień nazwę np. na .htaccess-backup.

Jeśli WordPress zacznie działać, możesz odtworzyć podstawowe reguły bezpośrednich odnośników w Ustawienia → Bezpośrednie odnośniki, zapisując ustawienia ponownie. Nie usuwaj jednak bez analizy dodatkowych reguł, które mogły odpowiadać za przekierowania, zabezpieczenia lub konfigurację aplikacji.

Błąd zaczął się po zmianie PHP

Starszy motyw, wtyczka lub własny fragment kodu może korzystać z konstrukcji nieobsługiwanej przez nowszą wersję PHP. Może też wystąpić odwrotna sytuacja – nowe rozszerzenie wymaga PHP nowszego niż obecnie ustawione.

Sprawdź w logu nazwę pliku powodującego błąd i wymagania używanego oprogramowania. Jeśli awaria rozpoczęła się dokładnie po zmianie wersji PHP, możesz testowo wrócić do wcześniej używanej wersji, a następnie zaktualizować element, który nie jest z nią zgodny.

Przekroczony został limit pamięci

Komunikat Allowed memory size exhausted wskazuje na przekroczenie dostępnej pamięci PHP. W takim przypadku sprawdź ustawiony memory_limit. Klienci cyber_Folks mogą zarządzać tym parametrem z poziomu ustawień PHP właściwego panelu.

Samo zwiększenie limitu nie zawsze rozwiązuje źródło problemu. Duże zużycie pamięci może wynikać z nieprawidłowo działającej wtyczki, rozbudowanego importu, przetwarzania obrazów, kosztownego zapytania lub błędu w kodzie. Jeśli zapotrzebowanie na pamięć nagle znacząco wzrosło, sprawdź dlaczego.

Nieprawidłowe uprawnienia plików

Problem mogą powodować również prawa dostępu do plików i katalogów. W typowych konfiguracjach często spotkasz wartości 644 dla plików i 755 dla katalogów, ale nie traktuj ich jako ustawień, które należy bezwarunkowo wymuszać na każdym serwerze.

Jeżeli uprawnienia zmieniły się bez Twojej wiedzy, sprawdź również, czy na stronie nie doszło do infekcji lub nieautoryzowanej ingerencji.

Błąd 500 nadal występuje. Co zrobić?

Jeżeli nie udało Ci się znaleźć problemu, wróć do logów i sprawdź, czy błąd występuje przy każdej próbie otwarcia strony, czy tylko przy konkretnej operacji. Warto również porównać moment rozpoczęcia awarii z historią ostatnich aktualizacji i zmian.

Kontaktując się ze wsparciem cyber_Folks albo programistą, przygotuj:

• adres strony lub podstrony zwracającej 500,
• przybliżoną godzinę wystąpienia błędu,
• opis czynności, przy której pojawia się problem,
• informację o ostatnich aktualizacjach i zmianach,
• fragment error.log lub debug.log,
• informację, jakie działania diagnostyczne zostały już wykonane.

Dzięki temu osoba analizująca awarię może szybciej przejść do konkretnego problemu zamiast rozpoczynać diagnostykę od podstaw.

Stabilne środowisko hostingowe nie wyeliminuje błędów w kodzie wtyczek czy motywów, ale daje Ci dostęp do narzędzi potrzebnych do diagnostyki oraz właściwej konfiguracji PHP. Jeśli rozwijasz stronę opartą na WordPressie, sprawdź hosting WordPress w cyber_Folks.