W praktyce chodzi o to, by bez zgadywania ustalić, jaka wersja PHP działa na serwerze i czy zgadza się z konfiguracją domeny, panelu hostingu oraz samej aplikacji. Poniżej pokazuję, jak sprawdzić wersję PHP w terminalu, przez plik testowy, w panelu hostingu i w kodzie strony, a przy okazji wyjaśniam, skąd biorą się rozbieżności.
Najkrótsza droga do pewnej odpowiedzi i uniknięcia pomyłek
- Terminal pokazuje wersję PHP używaną przez CLI, więc to najszybszy test przy dostępie SSH.
- phpinfo() sprawdza wersję widoczną w przeglądarce i zwykle najlepiej opisuje środowisko strony.
- Panel hostingu mówi, jaka wersja jest przypisana do domeny lub konta, ale nie zawsze jest to samo co CLI.
- Rozbieżności między wynikami są normalne, gdy serwer ma kilka instalacji PHP albo różne handlery.
- phpinfo() usuń od razu po teście, bo pokazuje zbyt dużo informacji o serwerze.
Najszybciej sprawdzisz to w terminalu, jeśli masz SSH
Jeśli mam dostęp do SSH, zaczynam od terminala. To najszybsza metoda i zwykle wystarcza, gdy chcę tylko potwierdzić, jaka wersja interpretera jest dostępna w powłoce systemowej. Wpisuję po prostu php -v i od razu widzę numer wydania oraz informację, czy uruchamia się wariant CLI.
php -vW praktyce dostaniesz odpowiedź w stylu PHP 8.x.y (cli). Sama końcówka (cli) jest ważna, bo mówi, że wynik dotyczy PHP Command Line Interface, a niekoniecznie tej samej instalacji, z której korzysta strona WWW. To pierwsza rzecz, o której wielu administratorów zapomina, a potem dziwi się, że panel pokazuje coś innego niż test w przeglądarce.
Jeżeli na serwerze działa kilka wersji PHP, sam alias php może prowadzić do innej instalacji niż ta, której oczekujesz. Wtedy sprawdzam jeszcze:
which php
php8.3 -v
/usr/bin/ea-php83 -vTaki test szybko pokazuje, czy serwer ma kilka binarek i która z nich faktycznie reaguje w danym kontekście. To szczególnie przydatne na hostingu współdzielonym oraz na maszynach z wieloma projektami. Następny krok to już porównanie wyniku z wersją używaną przez samą stronę.
Gdy nie masz SSH, użyj prostego pliku testowego z phpinfo()
Jeśli nie mam dostępu do terminala, najprościej tworzę tymczasowy plik w katalogu publicznym, na przykład info.php. W środku wystarczy jedna linia:
<?php
phpinfo();Po wejściu na adres tego pliku w przeglądarce dostajesz pełny raport o konfiguracji PHP. Szukam tam przede wszystkim trzech pól: PHP Version, Server API oraz Loaded Configuration File. Pierwsze mówi o wersji, drugie o sposobie uruchomienia interpretera, a trzecie podpowiada, z którego pliku php.ini korzysta dana instancja.
To właśnie ta metoda najlepiej odpowiada na pytanie o wersję używaną przez stronę, a nie tylko przez powłokę systemową. Ma jednak jeden istotny minus: phpinfo() ujawnia sporo danych o serwerze, rozszerzeniach i ścieżkach systemowych, więc po sprawdzeniu trzeba plik natychmiast usunąć. Zostawienie go publicznie to zbędne ryzyko, zwłaszcza na hostingu współdzielonym.
Jeżeli chcesz jeszcze prostszy wariant, możesz zamiast pełnego raportu wyświetlić samą wersję:
<?php
echo PHP_VERSION;To rozwiązanie jest uboższe diagnostycznie, ale wystarcza, gdy potrzebujesz tylko szybkiego potwierdzenia numeru wydania. Gdy jednak coś się nie zgadza, pełne phpinfo() daje więcej tropów do analizy, dlatego właśnie polecam je jako drugi krok.
Panel hostingu też pokaże wersję przypisaną do domeny
Na wielu hostingach wersję PHP ustawia się per domena albo per katalog. W praktyce oznacza to, że panel administracyjny może pokazywać jedną wersję, a CLI lub test w innym miejscu da wynik inny. Dlatego zawsze traktuję panel jako źródło konfiguracji, a nie ostateczny dowód tego, co aktualnie wykonuje kod.
W cPanel szukasz zwykle sekcji związanej z MultiPHP Manager, a w Plesku ustawień PHP dla domeny lub subdomeny. Tam wybierasz wersję, handlery i dodatkowe parametry. Jeśli w menu nie ma oczekiwanej wersji, najczęściej oznacza to, że dostawca hostingu jej nie zainstalował albo ograniczył dostęp do tego wariantu dla danego konta.
Warto pamiętać o jeszcze jednej rzeczy: na niektórych hostingach wersja jest dziedziczona z ustawień globalnych. To znaczy, że domena może korzystać z domyślnej konfiguracji konta, dopóki ręcznie jej nie zmienisz. Taka sytuacja często tłumaczy, dlaczego po zmianie w panelu jeden projekt działa na nowej wersji, a drugi nadal korzysta ze starszej.
Jeśli zarządzasz większą liczbą stron, panel jest bardzo użyteczny do porządkowania środowiska. Nie odpowie jednak sam z siebie na pytanie, co faktycznie uruchamia aplikację w danym żądaniu. Do tego potrzebny jest jeszcze test w przeglądarce albo bezpośrednio w kodzie.
Dlaczego terminal i strona mogą pokazywać różne wydania
To jeden z najczęstszych powodów nieporozumień przy administracji stronami WWW. PHP w terminalu i PHP obsługujące stronę mogą działać jako dwie różne instancje, uruchamiane przez inne mechanizmy. W praktyce spotkasz się z rozdzieleniem na CLI, CGI, FastCGI albo PHP-FPM, czyli różne sposoby podpinania interpretera do środowiska serwera.
| Metoda | Co sprawdza | Kiedy użyć | Na co uważać |
|---|---|---|---|
php -v |
Wersję PHP w CLI | Gdy masz SSH i chcesz szybki wynik | Nie musi być to samo PHP, co dla strony |
phpinfo() |
Wersję używaną przez stronę w przeglądarce | Gdy chcesz sprawdzić runtime witryny | Trzeba usunąć plik po teście |
| Panel hostingu | Wersję przypisaną do domeny lub konta | Gdy zarządzasz konfiguracją bez SSH | Może pokazywać ustawienie, a nie faktyczny runtime |
PHP_VERSION / phpversion() |
Wersję widzianą przez kod aplikacji | Gdy testujesz zachowanie skryptu | Wynik zależy od miejsca wykonania skryptu |
Ta różnica jest szczególnie ważna na hostingu z wieloma wersjami PHP. Zdarza się, że administrator zmienia wersję w panelu, ale stara konfiguracja w katalogu lub w pliku .htaccess nadal wymusza inny wariant. Dlatego gdy wyniki się rozjeżdżają, nie zakładam od razu błędu po stronie hostingu. Najpierw sprawdzam, w jakim kontekście wykonuje się kod.
Jeśli widzisz rozbieżność, najpierw porównaj wynik z terminala, wynik z phpinfo() i ustawienie w panelu. W większości przypadków jeden z tych trzech elementów od razu pokaże, gdzie leży problem. To oszczędza czas i eliminuje zgadywanie.
Najczęstsze błędy przy sprawdzaniu wersji i jak ich uniknąć
W pracy z hostingiem widzę kilka powtarzalnych pomyłek. Pierwsza to traktowanie php -v jako odpowiedzi o stronie WWW. To tylko prawda o CLI. Druga to zostawianie pliku z phpinfo() na produkcji, co niepotrzebnie odsłania konfigurację serwera. Trzecia to sprawdzanie wersji w złym katalogu, gdy aplikacja działa w innym podfolderze albo na innej domenie.
- Mylenie CLI z runtime strony - wynik z terminala nie musi odpowiadać temu, co widzi przeglądarka.
- Pomijanie dziedziczenia ustawień - domena może przejmować konfigurację z poziomu konta lub katalogu nadrzędnego.
- Zbyt szybkie zaufanie panelowi - panel pokazuje wybór lub konfigurację, ale nie zawsze potwierdza faktyczne wykonanie kodu.
- Brak porównania z phpinfo() - bez tego trudniej ustalić, który handler rzeczywiście obsługuje żądania.
- Nieusunięty plik testowy - to niepotrzebne ryzyko bezpieczeństwa i jeden z najłatwiejszych do uniknięcia błędów.
Jeśli aplikacja po zmianie wersji zaczyna działać inaczej, nie ograniczam się do samego numeru wydania. Sprawdzam też rozszerzenia, lokalny php.ini, a czasem nawet pamięć podręczną po stronie serwera lub CMS-a. Sama zgodność wersji nie gwarantuje jeszcze zgodności zachowania, zwłaszcza przy starszych projektach.
Jedna reguła, która oszczędza najwięcej czasu
Gdy potrzebuję krótkiej i pewnej odpowiedzi, trzymam się prostej zasady: terminal mówi o CLI, przeglądarka mówi o stronie, a panel hostingu mówi o konfiguracji przypisanej do domeny. Te trzy perspektywy razem dają pełny obraz i pozwalają od razu zobaczyć, gdzie powstała rozbieżność.
Jeśli masz tylko kilka sekund, zacznij od php -v. Jeśli wynik dotyczy strony, dołóż phpinfo(). Jeśli chcesz zrozumieć, dlaczego serwer działa właśnie tak, sprawdź panel hostingu i sposób przypisania wersji do domeny. Taki układ zwykle wystarcza, żeby szybko i bez domysłów ustalić właściwą wersję PHP oraz znaleźć źródło problemu.
