Zdecydowana większość stron internetowych jest zbudowana w oparciu o język PHP. Wszelkie zmiany na tych stronach, wynikające z ich przebudowy lub dostosowywania do nowych wersji interpretera, mogą powodować powstawanie mniej lub bardziej poważnych błędów w składni skryptów. Takie nieprawidłowości nie zawsze będą widoczne w postaci komunikatów na samej stronie, co dodatkowo będzie utrudniać ich analizę. Jak zatem sprawdzić, czy nasza witryna działa poprawnie dla każdego użytkownika, który ją odwiedza? Między innymi o tym dowiesz się z naszego artykułu. Zapraszamy!
PHP jest językiem skryptowym, interpretowanym w całości przez serwer hostingowy. Ilekroć ktoś odwiedza stronę zbudowaną w oparciu o PHP, następuje wykonanie skryptu, którego końcowym efektem jest wygenerowanie kodu HTML i wyświetlenie go w przeglądarce. Duża liczba funkcji, dodatkowych rozszerzeń, możliwość integracji z wieloma źródłami danych oraz praca zaangażowanego środowiska sprawiły, że PHP jest obecnie najczęściej wykorzystywanym językiem do budowy stron internetowych.
Na ogół wraz z rozwojem każdej witryny powstaje potrzeba modyfikacji wcześniej działającego skryptu PHP tak, aby osiągnąć oczekiwany nowy rezultat. Rzadko kiedy kod PHP strony internetowej zawiera kilka linii poleceń. Z reguły jest on bardzo rozbudowany, korzysta z zewnętrznych zasobów, takich jak bazy danych czy pliki xml, lub wykonuje w trakcie swojej pracy jakieś dodatkowe czynności, np. komendy bezpośrednio z linii poleceń serwera. Z tego powodu nietrudno nawet o drobną pomyłkę przy takiej modyfikacji strony.
Zasady, reguły i jeszcze raz… zasady
Każdy język programowania posiada zbiór zasad, które muszą być spełnione, aby skrypt w nim napisany wykonał się poprawnie. Jakiekolwiek odstępstwa od poprawności składni mogą albo spowodować wyświetlenie błędu, albo nieprawidłowe zachowanie samej aplikacji. W przypadku stron opartych o PHP, dzięki CloudHosting Panel, mamy możliwość stałego podglądu błędów, które pojawiają w trakcie pracy strony internetowej. Aby w sposób ciągły wyświetlać je bezpośrednio na naszej stronie WWW, wystarczy skorzystać z opcji display_errors, która jest dostępna w ustawieniach WWW i FTP.
Włączenie na stałe funkcji display_errors w CloudHosting Panel ma jedną zasadniczą wadę. Jeżeli z niej skorzystamy, osoby odwiedzające stronę zobaczą informację o każdym błędzie, który nie jest krytyczny, czyli nie przerywa działania strony. Może być to dla nas wizerunkowo bardzo niekorzystne. Wyobraźmy sobie, że prowadzimy popularny sklep internetowy lub zapraszamy potencjalnych klientów naszego przedsiębiorstwa na firmową stronę WWW. W tym czasie programista zajmujący się naszą witryną modyfikuje ją i popełnia jakiś drobny błąd. Nie jest on krytyczny, więc strona dalej się wyświetla, natomiast z powodu włączonej opcji display_errors, PHP zgłasza nam na niej komunikat, tak jak na przykładzie poniżej:
Trzeba przyznać, że takie „dodatkowe ozdobniki” na samej górze sklepu internetowego czy firmowej strony mogą skutecznie odstraszyć naszych klientów. Oczywiście zmiany na stronie można zaplanować z wyprzedzeniem, następnie przeprowadzić je i zweryfikować ich efekty, np. w godzinach nocnych, uprzednio wyłączając dostęp do strony dla użytkowników zewnętrznych. Niekiedy jednak błędy działania skryptu PHP mogą pojawić się niespodziewanie, wpływając negatywnie na sposób pracy witryny. Warto byłoby o tym wiedzieć wcześniej, zanim zgłoszą nam to klienci lub spostrzeżemy się np. że nie pojawiają się nowe zamówienia. Czy mamy jakąkolwiek możliwość weryfikowania błędów składni skryptów PHP bez włączania opcji display_errors?
Jak zwykle – nazwa.pl przychodzi z pomocą!
W przypadku tradycyjnych hostingów diagnozowanie błędów PHP możliwe jest tylko poprzez monitorowanie komunikatów, które pojawiają się na samej stronie dzięki display_errors. Niestety, posiadając na stałe włączoną tę opcję, nie tylko my będziemy widzieli te błędy. Zobaczą je też nasi klienci.
Oferowany przez nazwa.pl CloudHosting, poza najbardziej zaawansowaną technologią sprzętową, charakteryzuje się również bardzo rozbudowanym zapleczem systemowym, stworzonym przez naszych inżynierów i pozwalającym nam na wdrażanie rozwiązań, których rzeczywiście potrzebują nasi użytkownicy. Wsłuchując się w Wasz głos, na wszystkich serwerach CloudHosting uruchomiliśmy rozszerzone logowanie błędów z PHP, które realizowane jest do systemowego dziennika błędów. Każdy właściciel serwera może w ciągu kilku chwili sprawdzić jego zapis z poziomu CloudHosting Panel. Czy wiesz, że dziennik błędów czuwa także na Twoim serwerze przez cały czas, bez względu na to, czy masz włączoną opcję display_errors, czy zdecydowałeś się jej nie włączać?
KONIECZNIE PRZECZYTAJ NA BLOGU:
WIĘCEJ INFORMACJI Z CENTRUM POMOCY:
No dobrze, ale gdzie jest ten Error Log?
Dziennik błędów jest elementem systemu logów każdej usługi CloudHosting. Dostępny jest poprzez CloudHosting Panel, do którego można zalogować się z poziomu Panelu Klienta nazwa.pl lub poprzez adres https://admin.nazwa.pl. CloudHosting Panel to narzędzie, dzięki któremu – z poziomu przeglądarki WWW na komputerze czy np. smartfonie – można konfigurować wszystkie istotne funkcje na swoim hostingu. Jedną z opcji CloudHosting Panel są szczegółowe statystyki serwera oraz zapisy jego logów dostępne w postaci dwóch dzienników: dostępu (Access Log) i błędów (Error Log). Aby odczytać te dzienniki, wystarczy po zalogowaniu do CloudHosting Panel wybrać menu Statystyki, a następnie Logi serwera.
CloudHosting Panel umożliwia weryfikację zapisów dziennika dostępu i dziennika błędów do 30 dni wstecz. Można pobrać logi z konkretnego dnia lub wyświetlić ostatnie zapisy, które zostały odnotowane na podstawie tego, jak pracuje umieszczona na serwerze strona WWW. Zatem jeżeli chcemy zdiagnozować problem, który wystąpił w konkretnym dniu, wystarczy że pobierzemy zapisy dziennika błędów z tego dnia. Natomiast, gdy zauważyliśmy problem w działaniu strony, np. przed chwilą lub chcemy prewencyjnie sprawdzić, czy strona pracuje w 100% poprawnie, w zupełności wystarczy podgląd ostatnich zapisów Error Log.
Nie ma się czego bać!
Mimo że na pierwszy rzut oka zapisy dziennika błędów mogą wydawać się niezrozumiałe, to już po chwili bez większego problemu odnajdziemy w nich to, co pozwoli nam na naprawienie potencjalnych nieprawidłowości w działaniu strony WWW. Error Log to chronologiczny zapis wydarzeń, które zostały zaklasyfikowane przez serwer jako niewłaściwe. Ujęte są w nim błędy pracy interpretera PHP, który jest odpowiedzialny za generowanie dynamicznych stron WWW. Interpreter PHP przetwarza skrypt do zrozumiałego dla przeglądarek, i wysyłanego przez serwer do użytkownika odwiedzającego witrynę, HTML-u. Każde odstępstwo od reguł, które wyznacza składnia PHP, może albo spowodować całkowity brak strony i pojawienie się błędu 500, albo dalszą pracę skryptu, ale z jakimiś problemami, co w efekcie może doprowadzać do różnych negatywnych zdarzeń. Aby zobrazować, na ile jest to niebezpieczne, można wskazać chociażby błąd przyjęcia zamówienia w sklepie internetowym czy brak możliwości nawiązania połączenia z systemem obsługującym płatności online. Konsekwencje takiej, nazwijmy to, częściowo działającej strony WWW, mogą być dla nas bardzo poważne! O ile szybko możemy zorientować się, że nasz sklep zupełnie nie pracuje, bo wyświetla się błąd 500, to w przypadku pozornego działania strony już nie mamy takiej wiedzy. A to, co dzieje się na zapleczu sklepu, może być równie poważne w skutkach, jak jego całkowita niedostępność. Dlatego szczególnie wówczas, gdy nie korzystamy z funkcji display_errors, warto od czasu do czasu przeglądać zapisy dziennika błędów dostępnego przez CloudHosting Panel. Analizując jego zapisy, szybko dowiemy się, jakie potencjalne problemy pojawiają się podczas działania naszej strony.
Przyjrzyjmy się przykładom
Jak wiele jest stron internetowych zbudowanych w oparciu o PHP, tak wiele jest możliwych błędów, które w trakcie ich pracy mogą się pojawić. Dlatego na początek przeanalizujmy przykładowy schemat zapisu, który jest umieszczany w Error Log, aby lepiej zrozumieć, jak należy go interpretować.
Pierwsza część komunikatu dodanego do dziennika błędów rozpoczyna się od podanej, w nawiasie kwadratowym, dokładnej daty określającej pojawienie się błędu. W naszym przypadku jest to część komunikatu zaznaczona na żółto – 21 grudnia 2021 roku o godz. 14:59:23. Kolejna część komunikatu, zaznaczona w przykładzie na zielono, to informacja o tym, który system na serwerze zgłosił dany błąd i jaki był numer id procesu obarczonego błędem (pid, czyli process id). Te informacje mogą być przydatne dla administracji serwera, ale przy analizie błędów PHP możemy je pominąć – zostały na naszym przykładzie zaznaczone na zielono. Dalszy zapis, zaznaczony na pomarańczowo [client 192.168.0.1:64705], informuje nas, z jakiego IP łączyła się osoba, której wejście na stronę wygenerowało dany błąd. U nas jest to adres 192.168.0.1.
Następnie w Error Log widzimy, oznaczony w przykładzie na czerwono, kod diagnostyczny serwera AH01071: Got error. To informacja, że serwer odnotował błąd związany z PHP. Zapis za określeniem „Got error:” to konkretna informacja pochodząca z interpretera PHP, którą przy włączonej opcji display_errors zobaczylibyśmy na naszej stronie internetowej. Ten komunikat wyjaśnia, na jaki błąd napotkał interpreter PHP. Mamy tu zgłoszony problem: INSERT, UPDATE command denied, co oznacza, że PHP nie mógł wykonać operacji INSERT i UPDATE do bazy danych strony WWW, prawdopodobnie ze względu na zbyt mały rozmiar bazy do wykonania tych czynności. Ostatnią częścią komunikatu błędu jest „referer”, czyli adres URL, który spowodował wygenerowanie określonego błędu. W powyższym przykładzie adresem URL skryptu jest: http://jakasdomena.pl/witaj-swiecie/#comment-2929.
Skoro umiemy już czytać zapisy Error Log, pora aby wymienić kilka typowych zapisów dziennika błędów i w skrócie je omówić. Oprócz samego komunikatu pod każdym z przykładów wyjaśnimy przyczynę powstania takiego zapisu wraz z sugestią, co należy zrobić, aby taki błąd więcej się nie pojawiał.
Przykład 1:
Przyczyna błędu: Funkcja set_magic_quotes_runtime została wycofana począwszy od PHP 5.3 i ostatecznie usunięta w PHP 7.0.
Rozwiązanie: Należy zaktualizować aplikację, aby była zgodna z najnowszą wersją PHP, lub włączyć na serwerze obsługę starszych wersji PHP.
Przykład 2:
Przyczyna błędu: Funkcja magic_quotes była w PHP dostępna do wersji PHP 5.3, a od wersji PHP 7.4 jest całkowicie wycofana (deprecated), przez to skrypt w tym miejscu zwraca komunikat ‘false’.
Rozwiązanie: Należy poprawić skrypt, aby był zgodny z najnowszą wersją PHP, lub skorzystać z obsługi starszych wersji PHP, w ramach których ta funkcja jest dostępna.
Przykład 3:
Przyczyna błędu: Funkcja call_user_func_array zamiast oczekiwanej wartości otrzymała ‘false’. Taki błąd może występować w przypadku WordPressa, w którym często pojawiają się błędne deklaracje add_action w pliku functions.php motywu.
Rozwiązanie: Na ogół w takich przypadkach pomaga aktualizacja wykorzystywanego motywu WordPressa do wersji zgodnej z używaną wersją skryptu.
Przykład 4:
Przyczyna błędu: Błędy readdir() odnoszą się do problemu z uzyskaniem dostępu do wskazanej ścieżki lub pliku, stanowiących argument jakiejś funkcji.
Rozwiązanie: W takim przypadku należy sprawdzić, czy funkcja odnosi się do istniejącej struktury katalogów/plików na serwerze lub czy katalogi/pliki nie mają ustawionych zbyt restrykcyjnych praw dostępu (chmod).
Przykład 5:
Przyczyna błędu: Pojawienie się błędu opisanego jako „session_start(): Cannot start session when headers already sent” oznacza, że skrypt, który próbował rozpocząć sesję za pomocą session_start(), nie mógł tego zrobić, gdyż sesja została rozpoczęta już wcześniej, prawdopodobnie automatycznie, np. w wyniku obecności jakiejś treści lub pustych linii w skrypcie nav.php.
Rozwiązanie: W takim przypadku konieczna jest weryfikacja, czy skrypt generujący błąd nie posiada żadnych pustych linii lub ukrytych znaków po znaczniku <?php na początku, ale przed session_start();.
Przykład 6:
Przyczyna błędu: Komunikat informuje o braku deklaracji index’u name_server w skrypcie.
Rozwiązanie: Ponieważ konstrukcja skryptu jest błędna, a index name_server jest deklarowany tylko w przesyłanym formularzu, lub po prostu nie istnieje w tablicy zmiennych, konieczne jest jego prawidłowe zdeklarowanie.
Przykład 7:
Przyczyna błędu: Błąd opisany jako „Passing INI directive through FastCGI” oznacza, że niektóre z komend konfiguracyjnych PHP, umieszczonych w pliku .htaccess, nie są dozwolone przez serwer.
Rozwiązanie: W takim wypadku trzeba zweryfikować zawartość plików .htaccess (w katalogu skryptu i w katalogach nadrzędnych), eliminując nieakceptowane przez serwer komendy konfiguracyjne.
Przykład 8:
Przyczyna błędu: Funkcja file_get_contents w przedstawionym przykładzie odwołuje się do pliku za pomocą ścieżki względnej katalog/plik_test. Na serwerze konieczne jest realizowanie odwołań poprzez ścieżkę bezwzględną (całkowitą).
Rozwiązanie: Zakładając, że plik_test istnieje, należy skorygować ustawienie w skrypcie: /home/server000000/ftp/ture/wp-content/plugins/mywpguru/mywpguru.php, i wprowadzić w nim pełen adres do plik_test, który miałby postać: /home/server000000/ftp/ture/wp-content/plugins/mywpguru/katalog/plik_test.
Nie taki błąd straszny, jak go malują 🙂
CloudHosting Panel to doskonałe narzędzie do analizy wszelkich problematycznych sytuacji, które mogą pojawiać się w trakcie pracy ze stroną internetową. Znajomość funkcji dostępnych w CloudHosting Panel umożliwia wygodną obsługę stron, nie tylko programistom, którzy je tworzą, ale również użytkownikom codziennie na nich pracującym. Zapisy Error Log, które są dostępne w Panelu, zawierają bogatą historię wszelkich zdarzeń, które mogły mieć wpływ na poprawne wyświetlanie strony WWW. Ponieważ CloudHosting Panel zapewnia dostęp do logów aż z 30 dni wstecz, można w każdym momencie wygodnie zdiagnozować i usunąć wszelkie problemy, o których właściciel strony mógł nawet potencjalnie nie zdawać sobie sprawy. Zdarzyć się może, jak pokazuje chociażby przykład nr 2 z naszego artykułu, że niektóre funkcje mogą być wycofywane w kolejnych wersjach interpretera PHP, a co za tym idzie – strona, która wcześniej działała poprawnie, z nową wersją PHP może mieć już jakiś problem. Dlatego warto regularnie przeglądać zapisy dziennika błędów. A można to robić, nie martwiąc się o konfigurację ustawienia display_errors dla PHP. Serwery CloudHosting dbają samodzielnie o zbieranie wszelkich niezbędnych informacji diagnostycznych, odnotowując wszystkie zdarzenia, które mają miejsce w związku z działaniem każdej pojedynczej strony internetowej.
