Napisał Pan/Pani działający kod PHP na świeżej wersji, wrzucił na produkcję i dostał lawinę zgłoszeń błędów od klientów na starych hostingach. Brzmi znajomo? Składnia, która dla Pana/Pani jest „oczywista", na PHP 7.0 kończy się błędem krytycznym. A zainstalowanie lokalnie kilkunastu przestarzałych wersji, żeby sprawdzić każdy fragment, to zajęcie na pół dnia, o ile w ogóle jest możliwe.

Problem jest głębszy, niż się wydaje. Stare wersje PHP znikają z oficjalnych repozytoriów, nie kompilują się na współczesnych jądrach Linuxa i powodują konflikty z rozszerzeniami. A WordPress wciąż działa na serwerach, gdzie dostawca hostingu nie pofatygował się z aktualizacją PHP. W rezultacie Pana/Pani wtyczka lub motyw przestaje działać u setek użytkowników tylko dlatego, że użył Pan/Pani typowanego argumentu string albo krótkiej składni tablicy.

Istnieje jednak narzędzie, które rozwiązuje ten problem w kilka sekund: 3v4l.org, darmowy tester kodu PHP online na ponad 300 wersjach jednocześnie. Bez instalacji, bez maszyn wirtualnych. W tym poradniku pokażę, jak z jego pomocą wyłapać niezgodności przed wydaniem, oraz przedstawię na rzeczywistych przykładach błędy, które sami przeoczyliśmy na produkcji.

💡 Szybki przegląd:

• Wklej fragment kodu PHP na 3v4l.org i uruchom wykonanie na wszystkich wersjach, od PHP 4.3.0 do najnowszej 8.5
• Spójrz na zgrupowane wyniki: strona pokaże, gdzie kod działa, gdzie zgłasza błąd i gdzie zachowanie się różni
• Poznaj dwa klasyczne przykłady niezgodności, które psują wtyczki WordPress na starych hostingach, wraz z kodem i linkami do testu na żywo
• Porównaj alternatywne sposoby sprawdzania: kontenery Docker, PHPBrew, wbudowany inspektor PhpStorm, ich zalety i wady
• Obejrzyj film po angielsku z demonstracją integracji TemPHPest + 3v4l prosto z VSCode

Dlaczego ręczna instalacja starych wersji PHP to droga przez mękę

Jeśli administruje Pan/Pani serwerem na Linuksie, z pewnością zauważył Pan/Pani: stare, niewspierane gałęzie PHP po prostu znikają z menedżerów pakietów. Repozytorium ppa:ondrej/php, główne źródło pakietów PHP dla Ubuntu, uczciwie ostrzega podczas instalacji:

Dostarczane są tylko wspierane wersje PHP dla wspieranych wydań Ubuntu.

W czerwcu 2026 roku oficjalnie wspierane są gałęzie 8.2, 8.3, 8.4 i 8.5. PHP 8.1 odszedł na emeryturę w grudniu 2025. PHP 7.4 to już od dawna historia. Ale na hostingach współdzielonych i przestarzałych VPS-ach wciąż można trafić na PHP 7.0, a nawet 5.6. A sprawdzenie na nich kodu lokalnie to prawdziwe wyzwanie.

PHPBrew kiedyś ratował sytuację: narzędzie potrafiło skompilować dowolną wersję PHP z kodu źródłowego i przełączać się między nimi jedną komendą. Jednak projekt praktycznie nie jest aktualizowany od 2020 roku, a skompilowanie PHP 5.6 na jądrze Linux 6.x to łamigłówka z łatkami i flagami zgodności. Kontenery Dockera są prostsze, ale wymagają napisania Dockerfile dla każdej wersji, pobrania obrazów i i tak zajmują gigabajty przestrzeni dyskowej.

Alternatywa istnieje i działa prosto w przeglądarce.

3V4l.org: Pana/Pani tester online na ponad 300 wersji PHP

3v4l.org (leetspeak od „eval") to internetowa piaskownica, która wykonuje Pana/Pani kod PHP na ponad 300 wersjach interpretera jednocześnie. Od wiekowego PHP 4.3.0 po najnowsze 8.5. Twórca projektu skompilował i utrzymuje każdą znaczącą wersję wydaną w całej historii języka.

Mechanizm jest genialnie prosty: wkleja Pan/Pani fragment w lewy panel, klika eval() i po kilku sekundach otrzymuje tabelę wyników. Strona grupuje wersje według wyniku: zielone wiersze oznaczają, że kod zadziałał tak samo, żółte/czerwone, że zachowanie się różni lub wystąpił błąd. Od razu widać, na jakiej minimalnej wersji PHP Pana/Pani składnia staje się poprawna.

Co szczególnie cenne: 3v4l.org pokazuje treść błędów dla każdej problematycznej wersji. Nie abstrakcyjne „niezgodne", tylko konkretne Parse error: syntax error, unexpected '[' in ..., ze wskazaniem wiersza. To oszczędza godziny debugowania.

Każdy test otrzymuje unikalny adres URL, link można dodać do zgłoszenia, wysłać liderowi zespołu lub wykorzystać jako dokumentację: „Oto dowód, że wyrażenie match nie działa na PHP 7.4".

Przykład 1: krótka składnia tablicy, mina pod WordPressem

Programista pisze w JavaScript, przełącza się na PHP i z przyzwyczajenia tworzy tablicę:

1
$a = [];

Wygląda niewinnie. Na Pana/Pani lokalnej maszynie z PHP 8.4 działa. Na serwerze testowym z PHP 8.2 również. Wdrożenie na produkcję i klienci z PHP 5.6 widzą biały ekran.

Krótka składnia tablicy [] pojawiła się dopiero w PHP 5.4. Wcześniej dostępna była tylko array(). I choć PHP 5.4 został wydany w 2012 roku, statystyki WordPress.org przez dekady pokazywały znaczący odsetek instalacji na wersjach PHP niższych niż 5.4. Obecnie sytuacja się poprawiła, ale wtyczki do WordPressa nadal muszą uwzględniać niuanse związane ze zgodnością.

Proszę uruchomić ten snippet przez 3v4l.org, a otrzymają Państwo jednoznaczny werdykt:

1
PHP 5.3.x and older: Parse error: syntax error, unexpected '['
2
PHP 5.4.x and newer: OK

Żadnych domysłów, żadnego czytania manuala dla każdej konstrukcji. Oszczędność: 30 sekund zamiast 15 minut googlowania „od której wersji PHP działa krótka składnia tablic".

Przykład 2: type hints, gdy kod po cichu psuje się na starym PHP

Deklaracje typów argumentów czynią PHP bardziej rygorystycznym i przewidywalnym. Ale ewolucja type hints przebiegała nierównomiernie, co tworzy pułapkę. Proszę spojrzeć na kod:

1
function handleException(Exception $e) {}
2
function greet(string $name) {}
3
function processItems(array $items) {}
4
 
5
handleException(new Exception('Test'));
6
greet("hello");
7
processItems([1, 2, 3]);

Pozornie trzy jednorodne deklaracje. Ale test na 3v4l.org pokazuje niespodziankę:

Typy skalarne string, int i bool pojawiły się dopiero w PHP 7.0, 12 lat po typach klasowych! Jeśli Państwa wtyczka deklaruje minimalną wersję PHP 5.6, a użyli Państwo function register(string $username), na starym hostingu da to niezrozumiały błąd fatalny:

1
Catchable fatal error: Argument 1 passed to greet() must be an instance of string,
2
string given in...

Komunikat jest mylący: „must be an instance of string, string given". Klient odczytuje to jako nonsens i pisze gniewną opinię. A przyczyna jest prosta: PHP 5.6 nie rozumie skalarnego type hint i próbuje zinterpretować string jako nazwę klasy.

Z 3v4l.org wyłapują Państwo takie niezgodności w minutę, a nie po dziesięciu zgłoszeniach błędów.

Alternatywy: IDE, Docker i narzędzia konsolowe

3v4l.org pokrywa większość scenariuszy sprawdzania zgodności, ale nie wszystkie. Oto co jeszcze jest w arsenale, z plusami i minusami.

PhpStorm. Wbudowany inspektor JetBrains podświetla składnię niezgodną z wybraną wersją PHP: wskazują Państwo w ustawieniach „PHP 7.4", a edytor podkreśla match(), typed properties, str_contains(). Jednak PhpStorm kosztuje (subskrypcja od $99/rok), a sprawdzanie jest statyczne, nie ma rzeczywistego wykonania kodu. Inspektor nie pokaże różnicy w zachowaniu array_key_last() między wersjami, a 3v4l.org pokaże.

Docker. Najbardziej elastyczny sposób: docker run -v $(pwd):/app php:5.6 php /app/test.php uruchomi kod w dokładnym środowisku. Ale do przetestowania 10 wersji potrzeba 10 kontenerów, 10 różnych obrazów i skryptu automatyzacji. Do szybkiego sprawdzenia snippeta, nadmiarowe.

Lokalny PHPBrew. Jak wspomniano wyżej, projekt jest zamrożony, a kompilacja starych wersji PHP na nowoczesnym jądrze wymaga tańców z łatkami. W 2026 roku prościej jest otworzyć 3v4l.org.

GitHub Actions / CI. Macierz wersji PHP w CI (np. strategy.matrix.php: ['7.4', '8.0', '8.1', '8.2', '8.3', '8.4', '8.5']) wyłapuje problemy podczas każdego pusha. To must-have dla bibliotek, ale dla autorów wtyczek WordPress, którzy piszą w Sublime Text lub VSCode bez CI, 3v4l.org pozostaje najdostępniejszym i najszybszym narzędziem.

Wideo: TemPHPest + 3v4l prosto z VSCode

Rozszerzenie TemPHPest dla VSCode integruje 3v4l.org z edytorem: zaznaczają Państwo kod, naciskają kombinację klawiszy i otrzymują wynik na wszystkich wersjach PHP, bez otwierania przeglądarki. Autor rozszerzenia nagrał krótką demonstrację:

Połączenie VSCode + TemPHPest + 3v4l.org daje niemal bezszwowe doświadczenie: piszą Państwo kod, od razu sprawdzają zgodność, poprawiają błędy. Działa szybciej niż przełączanie się między edytorem a przeglądarką.

⁉️🤔 Często zadawane pytania

Czy 3v4l.org jest darmowe?

Tak, całkowicie. Bez rejestracji, bez ograniczeń liczby uruchomień, bez reklam. Serwis o otwartym kodzie źródłowym, działa na prywatnym serwerze autora. Jeśli korzysta Pan/Pani regularnie, może Pan/Pani wesprzeć autora przez GitHub Sponsors, co pomoże opłacić hosting i energię elektryczną.

Jakie wersje PHP są dostępne na 3v4l.org?

Wszystkie znaczące wydania, począwszy od PHP 4.3.0 (wydanego w 2002 roku) aż do najnowszego 8.5 (listopad 2025). Każde wydanie pomniejsze to osobny wiersz w tabeli wyników. Łącznie ponad 300 wersji. Jeśli potrzebnej wersji nie ma na liście, autor dodaje nowe wydania operatywnie.

Czy można testować całe projekty, a nie tylko fragmenty kodu?

3v4l.org jest przystosowany do izolowanych fragmentów kodu, funkcji, klas, pojedynczych algorytmów. Można wkleić kilkaset linii, ale bez require i include z autoloaderem composera i połączeniem z bazą danych. Do pełnoprawnego testowania integracyjnego projektu lepiej nadają się kontenery Docker lub GitHub Actions z macierzą wersji PHP.

Czy bezpiecznie jest wklejać wrażliwy kod na obcy serwer?

Nie. Kod na 3v4l.org otrzymuje publiczny adres URL i jest technicznie dostępny przez bezpośredni link. Nie należy używać serwisu do danych poufnych, kluczy API, haseł, zamkniętej logiki biznesowej. Dla kodu własnościowego proszę uruchomić lokalny kontener Docker: docker run -v $(pwd):/app php:7.4 php /app/private-code.php.

Czym 3v4l.org jest lepszy od wbudowanego sprawdzania w IDE?

Analiza statyczna w IDE (PhpStorm, PHPStan) sprawdza składnię i typy, ale nie wykonuje kodu. 3v4l.org faktycznie przepuści fragment przez interpretery wszystkich wersji i pokaże rzeczywiste wyjście, różnicę w zachowaniu array_key_last(), json_encode() i preg_match() między wersjami. Do tego nie wymaga zakupu IDE, działa w przeglądarce.

Co wybrać do sprawdzania kompatybilności kodu PHP w 2026 roku

Do codziennej pracy autora tematów i wtyczek schemat jest następujący. Fragment kodu budzący wątpliwości od razu trafia do 3v4l.org. Wynik w 5 sekund, link do testu dołączany jest do commita. Projekt, w którym ważna jest kompatybilność z kilkunastoma wersjami PHP, macierz w GitHub Actions: raz skonfigurowana i każdy push jest automatycznie testowany. Szybkie sprawdzenie cudzego kodu przed code review, TemPHPest w VSCode (bezpłatnie, zintegrowany z 3v4l.org).

Najważniejsze, co zmieniło się w porównaniu z 2020 rokiem (kiedy pierwotna wersja tego materiału dopiero powstała): PHP 5.6 ostatecznie zniknął z większości hostingów, minimalną poprzeczką stało się PHP 7.4, a na horyzoncie jest PHP 8.5 z nowymi funkcjami i nową potencjalną niekompatybilnością. Ale zasada pozostaje niezmienna: sprawdził Pan/Pani kompatybilność przed wydaniem, śpi Pan/Pani spokojnie. 3v4l.org czyni to sprawdzenie trywialnym.