W praktyce najwięcej czasu traci się nie na samą komendę, tylko na to, by sprawdzić właściwe środowisko. Najprostszy problem brzmi dziś zwykle tak: jak sprawdzić wersję PHP, żeby wynik rzeczywiście dotyczył strony na hostingu, a nie przypadkowego interpretera obok. Poniżej pokazuję metody, których sam używam najczęściej, oraz to, kiedy każda z nich ma sens.
Sprawdzenie wersji PHP zależy od tego, gdzie działa strona
- Najszybszy test w terminalu to
php -v, ale pokazuje on wersję CLI, nie zawsze tę samą co strona. - Jeśli chcesz poznać wersję działającą pod WWW, najpewniejsze jest
phpinfo()albo prosty plik testowy. - W panelu hostingu wersja bywa ustawiana osobno dla każdej domeny, subdomeny lub katalogu.
- Różnice między wynikami zwykle wynikają z PHP-FPM, wielu konfiguracji albo osobnych ustawień dla cronów.
- W 2026 roku nie warto zostawiać strony na niewspieranej gałęzi PHP, bo rośnie ryzyko błędów i luk bezpieczeństwa.
Ja zaczynam od terminala, bo to najszybszy test i od razu daje odpowiedź dla środowiska CLI. Na Linuxie i macOS zwykle wystarczy zwykła sesja SSH, a na Windowsie działa to w PowerShellu, jeśli ścieżka do PHP jest dodana do zmiennej PATH.
php -v
php --versionJeśli chcesz tylko sam numer bez dodatkowych informacji, użyj:
php -r "echo PHP_VERSION, PHP_EOL;"Na pierwszej linii zobaczysz wersję interpretera uruchamianego z linii poleceń. To ważne: wynik php -v dotyczy CLI, a nie zawsze tego samego PHP, które obsługuje witrynę. W praktyce ma to znaczenie przy Composerze, cronach i skryptach uruchamianych z konsoli. Jeśli komenda nie działa, PHP nie jest dostępne lokalnie albo nie zostało dodane do PATH.
Gdy sprawdzam aplikację wdrażaną przez serwer WWW, nie kończę na terminalu. Wtedy przechodzę do testu pod przeglądarką, bo dopiero on pokazuje wersję używaną przez samą stronę.
W przeglądarce najpewniej pokaże ją phpinfo()
Jeżeli zależy Ci na wersji używanej przez witrynę, a nie przez CLI, najczystszy test to mały plik PHP z phpinfo(). Dokumentacja PHP opisuje tę funkcję jako źródło informacji nie tylko o wersji, ale też o konfiguracji, rozszerzeniach i środowisku serwera, więc bardzo szybko widać, z czym naprawdę pracuje hosting.
Taki plik zapisuję zwykle jako phpinfo.php, wgrywam do katalogu strony i otwieram pod domeną witryny. W sekcji z informacjami o systemie szukasz pozycji PHP Version. Jeśli hosting działa poprawnie, odczyt jest jednoznaczny i pokazuje wersję dla requestów HTTP, a nie dla terminala.
To narzędzie zostawiam wyłącznie na czas testu. Nie warto trzymać publicznego pliku z phpinfo() dłużej niż to konieczne, bo ujawnia zbyt dużo danych o konfiguracji serwera. Po sprawdzeniu usuń go z hostingu.
Przeczytaj również: Audyt strony internetowej - Jak znaleźć błędy hamujące wzrost?
Gdy potrzebujesz tylko numeru w kodzie
W samej aplikacji często wystarczy mi prostszy odczyt. Do tego służy phpversion() albo stała PHP_VERSION. To rozwiązanie jest wygodne, jeśli budujesz własny CMS, robisz diagnostykę albo chcesz wypisać wersję w panelu administracyjnym.
Jeśli chcesz warunkowo sprawdzić zgodność, używam zwykle version_compare(), bo lepiej nadaje się do progów wersji niż ręczne porównywanie tekstu.
To już nie jest tylko odczyt, ale praktyczna kontrola zgodności, która przydaje się na etapie wdrożenia. Gdy masz taki punkt odniesienia, warto jeszcze zajrzeć do panelu hostingu, bo tam zwykle ustawiana jest wersja przypisana do domeny.
W panelu hostingu wersja bywa przypisana do domeny
Na hostingu współdzielonym wersja PHP często nie jest globalna dla całego konta. Jedna domena może działać na 8.4, a subdomena na 8.2, dlatego odczyt z panelu jest ważny wtedy, gdy zarządzasz kilkoma serwisami na jednym pakiecie.
W praktyce szukam sekcji związanej z PHP, domenami albo oprogramowaniem. W cPanelu najczęściej robi się to przez MultiPHP Manager, a w innych panelach logika jest podobna: wybierasz domenę i widzisz przypisaną do niej wersję.
- Zaloguj się do panelu hostingu.
- Wejdź w ustawienia domeny, aplikacji albo sekcję PHP.
- Odczytaj aktywną wersję dla konkretnej witryny.
- Sprawdź, czy subdomeny albo katalogi nie mają osobnych reguł.
Jeśli panel pokazuje inną wersję niż php -v, nie traktuję tego od razu jako błędu. Zwykle oznacza to po prostu, że hosting rozdziela środowisko CLI i środowisko WWW, albo że aplikacja działa przez inny handler, na przykład PHP-FPM. Następny krok to porównanie wyników i ustalenie, który z nich jest właściwy dla konkretnego zadania.
Który wynik jest właściwy w praktyce
Gdy porównuję kilka odczytów, patrzę przede wszystkim na to, czy chcę sprawdzić serwer, aplikację czy zadanie uruchamiane z konsoli. Ta różnica rozwiązuje większość nieporozumień, które pojawiają się na hostingu.
| Metoda | Co pokazuje | Kiedy ją wybrać | Ograniczenie |
|---|---|---|---|
php -v |
Wersję PHP CLI | SSH, Composer, cron, test lokalny | Nie musi być zgodna z wersją strony WWW |
phpinfo() |
Wersję uruchamianą przez przeglądarkę oraz konfigurację | Diagnoza witryny na hostingu | Ujawnia wiele danych, więc plik trzeba usunąć po teście |
phpversion() / PHP_VERSION
|
Wersję widzianą przez aplikację | Gdy masz dostęp do kodu CMS lub własnej aplikacji | Wymaga wejścia w kod |
| Panel hostingu | Wersję przypisaną do domeny | Gdy nie masz SSH albo chcesz potwierdzić ustawienia hostingu | Nie pokazuje automatycznie, co zwróci PHP w danym żądaniu |
Jeśli wynik z panelu i phpinfo() się rozjeżdża, ufam temu drugiemu, bo pokazuje środowisko WWW. Jeśli rozjazd dotyczy php -v, patrzę na CLI i cron, a nie na stronę. W praktyce to właśnie ten podział pozwala uniknąć fałszywych wniosków podczas migracji albo debugowania błędów po aktualizacji hostingu.
Skoro wiesz już, skąd pochodzi wynik, warto jeszcze ocenić, czy ta gałąź PHP jest w ogóle dobrym wyborem. Sam numer bywa prawidłowy technicznie, ale z perspektywy bezpieczeństwa może być już za stary.
Czy ta gałąź PHP jest jeszcze wspierana
W 2026 roku nie patrzę wyłącznie na sam numer wersji. Równie ważne jest to, czy dana gałąź ma jeszcze aktywne wsparcie albo przynajmniej poprawki bezpieczeństwa. PHP ma prosty cykl życia: dwa lata aktywnego wsparcia i kolejne dwa lata poprawek bezpieczeństwa, a potem gałąź trafia do EOL.
| Gałąź | Status w 2026 | Co to znaczy praktycznie |
|---|---|---|
| 8.5 | Aktywne wsparcie | Dobry kandydat na nowe wdrożenia, jeśli aplikacja jest zgodna |
| 8.4 | Aktywne wsparcie do 31 grudnia 2026 | Bardzo bezpieczny wybór dla większości hostingów i CMS-ów |
| 8.3 | Wsparcie bezpieczeństwa do 31 grudnia 2027 | Sensowna opcja, jeśli projekt nie wymaga nowości z 8.4 lub 8.5 |
| 8.2 | Wsparcie bezpieczeństwa do 31 grudnia 2026 | Jeszcze używana, ale plan migracji warto mieć już teraz |
| 8.1 | Koniec wsparcia 31 grudnia 2025 | Do aktualizacji jak najszybciej |
Na nowych projektach nie schodzę zwykle poniżej 8.3, a przy istniejącej stronie decyzję opieram na zgodności motywu, wtyczek i rozszerzeń, nie tylko na samym numerze. Jeśli host pokazuje 8.1 lub starszą gałąź, traktuję to jako sygnał do planu migracji, a nie do odkładania sprawy. To właśnie połączenie wersji i wsparcia mówi najwięcej o realnym ryzyku na hostingu.
Zanim zmienisz PHP, sprawdź jeszcze rozszerzenia i kopię strony
W praktyce sama wersja PHP nie zamyka tematu. Ja przed zmianą sprawdzam jeszcze intl, mbstring, curl i zip, bo właśnie brak rozszerzenia częściej wywołuje awarię CMS-a niż sam numer wersji. Warto też pamiętać, że część błędów pojawia się dopiero po wejściu w panel administracyjny, formularz kontaktowy albo proces płatności.
Jeśli hosting daje środowisko testowe, robię pierwszy przejazd właśnie tam. Gdy go nie ma, testuję po zmianie logowanie, formularze, wysyłkę maili i najważniejsze widoki frontu. Dzięki temu szybciej wychwytuję konflikt z motywem, wtyczką albo starszą biblioteką, zamiast zgadywać, czy problemem była sama wersja. Najkrótsza droga wygląda więc tak: terminal dla CLI, phpinfo() dla strony, panel hostingu dla konfiguracji domeny.
