Przełączając jeden z serwerów na PHP 7 z PHP 5.3 powstał ciekawy błąd 500 (internal server error), z następującą treścią:

Parse error: syntax error, unexpected end of file nazwa pliku, w tym przypadku functions.php WordPressa in the line numer ostatniej linii pliku

Pierwszą myślą jest niedomknięty nawias, średnik, przecinek itp… Okazało się jednak, że problem leżał gdzie indziej.

Otóż na serwerze konfiguracja PHP w wersji 7 miała domyślnie dyrektywę PHP short_open_tag ustawioną na Off, co powodowało, że użycie kodu <? do rozpoczęcia bloku PHP (zamiast alternatywnego <?php) owocowało właśnie rzeczonym błędem.

Tego skrótowego znacznika otwarcia kodu PHP używa mnóstwo projektów, zaś zlokalizowanie problemu okazało się dosyć trudne – treść błędu niczego konkretnego nie mówiła (wskazywała na ostatnią, pustą linię pliku), zaś wykrywacze błędów PHP nie zgłaszały pomyłek. Również narzędzia online nie pomagały – zazwyczaj błędów wcale nie sygnalizowały wcale, a jeśli już, to bez wskazywania, gdzie one występują i czemu.

Sam problem pojawiał się więc nawet przy użyciu kodu ?><?

Rozwiązanie problemu

Najprostszą metodą jest ustawienie w pliku php.ini dyrektywy na On:

short_open_tag = On ;

Nie zawsze jednak jest to możliwe. W tym przypadku dostawca serwera hostingowego zablokował możliwość edytowania ustawień PHP, także przez funkcję PHP: @ini_set('short_open_tag', 'On');

Pozostało więc żmudne zmienianie każdego wystąpienia otwierającego znacznika PHP <? na <?php

Niestety przy mnóstwie dodatków do systemu WordPress i jego aktualizacjach taka konfiguracja serwera oznacza, że w każdej chwili witryna może przestać działać.

Dlatego też tak istotne jest, by swoje strony umieszczać na profesjonalnym hostingu, a nie byle tańszym.

Dlaczego taka dyrektywa istnieje?

Znaki <? oznaczają także początek kodu języka XML. Jeśli więc w projekcie PHP używa się XMLa, to mogą powstać problemy z nieprawidłowym włączeniem interpretera PHP, gdy używany jest kod XML.

W praktyce takie sytuacje się raczej nie zdarzają i wiele ludzi stosuje skrótowe znaczniki otwarcia kodu PHP. Jak jednak widać po tym przykładzie, jednak należy stosować pełny zapis znacznika otwarcia.

Hosting współdzielony DreamHost mimo, że bardzo dobry, ma swoje ograniczenia. Strony z czasem go przerastają. Efektem są błędy 500 internal server error lub 404 not found, ponieważ procesy httpd, które przekraczają limity RAMu lub czasu procesora, są zabijane w trakcie wykonywania, co owocuje takimi właśnie błędami.

Aby przekonać się, ile razy procesy były zabijane, można zapytać wsparcie techniczne o liczbę wykonań prockill. U nas sięgała już kilka tysięcy miesięcznie – tyle razy strony nie ładowały się poprawnie (choć w zdecydowanej większości przy ich administracji, ponieważ użytkownicy mają większość zasobów ładowanych z CloudFlare).

W takiej sytuacji najprościej jest przerzucić się na ich pakiet VPS, który różni się w praktyce tym, że można ustawiać pojemność pamięci RAM i monitorować czas zużycia procesora, co niweluje powyższe problemy. Można także zostawiać włączone na stałe procesy w pamięci, co może być bardzo przydatne dla informatyków.

Wykonaliśmy testy przed i po zmianie hostingu Shared na VPS dla witryny opartej o WordPressa.

Czasami zdarza się, że WordPress wykonuje samoczynnie aktualizacje.

Niekiedy też coś się nie powiedzie i mimo, że aktualizacja jakiegoś elementu (wtyczki, motywu, systemu) nie jest realizowana, to system w trakcie próby wykonania ręcznej aktualizacji wyświetla powiadomienie: “Aktualnie przeprowadzana jest inna aktualizacja” lub – w języku angielskim: “Another update is currently in progress”.

Jest to spowodowane włączeniem się mechanizmu zapobiegania wykonywaniu dwóch jednoczesnych aktualizacji.

Wszystko wróci do normy po 15 minutach – mechanizm sam odblokuje się i możliwe będzie ręczne przeprowadzenie aktualizacji.

Wiele firm hostingowych wdrożyło już wersję 7 języka PHP na swoje serwery, która jest znacznie szybsza od poprzednich (nawet dwukrotnie).

Jednocześnie zauważyłem, że wiele z tych firm (np. nazwa.pl, DreamHost) domyślnie ma wyłączone wsparcie dla mechanizmu OPcache, który według moich testów przyspiesza ładowanie stron na WordPressie i sklepach na WooCommerce dwu- a nawet trzykrotnie! Tak – 200% do 300%!

Najwięcej zyskują duże strony, jak sklepy. Czas ich generowania potrafił spaść z 10 sekund do 3 sekund.

Strony niezbyt skomplikowane, jak niniejsza, zyskują przyspieszenie rzędu 10% (czas ładowania spadł z 0,6s do 0,5s).

Wystarczy zapytać dostawcę hostingu, w którym miejscu można włączyć tą funkcję, a strona magicznie przyspieszy. Wiedza techniczna zazwyczaj nie jest wymagana. Dla WordPressa trzeba jednak zainstalować wtyczkę OPcache Dashboard, która automatycznie wyczyści cache po aktualizacji WordPressa, co jest niekiedy potrzebne.

Będzie to kosztem pamięci RAM, ale jeśli mamy zapas około 100MB (a tak zazwyczaj jest), to nie powinno to być żadnym problemem.

Na serwerze firmy Nazwa spotkaliśmy się z nietypowym problemem: generowane przez funkcję PHP date() polskie nazwy miesięcy i dni tygodnia zamiast polskich znaków wyświetlały typowe ikony “diamentów” z pytajnikiem w środku (tzw. krzaki), sygnalizujące problem z kodowaniem.

Generowane przez PHP, a zarazem WordPressa kodowanie tych znaków nie było kodowaniem Windows-1250, ani UTF-8, ani ISO-8859-2. Mimo jasnych ustawień domyślnego kodowania PHP w phpinfo(), nagłówków HTTP, znacznika meta na UTF-8, usilnie stosowane było bliżej niesprecyzowane kodowanie znaków. Także zapisy w górnej części pliku .htaccess nie pomogły:

AddDefaultCharset utf-8
IndexOptions +Charset=UTF-8

Dopiero wklejenie w górnej części pliku wp-config.php poniższego kodu pomogło:

setlocale(LC_ALL,[‘pl_PL.utf8’, ‘pl_PL’,’pl’,’pl_PL.utf-8′,’Polish_Poland.65001′,’polish_poland’]);

Z kolei pliki zawierające polskie znaki, a wgrane na serwer przy użyciu automatycznego ustawiania kodowania w programie FlashFXP, nie były dostępne przez przeglądarkę (błąd 404: nie znaleziono). Dopiero ręczne przestawienie enkodowania plików w ustawieniach FlashFXP na UTF-8 i ponowne wgranie (nadpisanie) plików w taki sposób pomogło i pliki stały się dostępne w przeglądarce.