Du skrev fungerande PHP-kod på den senaste versionen, pushade till produktion och fick en flod av buggrapporter från kunder på gammal hosting. Låter det bekant? Syntax som känns "självklar" för dig blir ett fatalt fel på PHP 7.0. Att installera ett dussin föråldrade versioner lokalt för att kontrollera varje snutt är en halvdagsuppgift, om det ens är möjligt.

Problemet är djupare än det verkar. Gamla PHP-versioner försvinner från officiella paketarkiv, går inte att kompilera på moderna Linux-kärnor och hamnar i konflikt med tillägg. WordPress körs fortfarande på servrar där hosten varit för lat för att uppdatera PHP. Resultatet blir att din plugin eller ditt tema kraschar för hundratals användare bara för att du använde ett typat string-argument eller kort arraysyntax.

Men det finns ett verktyg som löser problemet på sekunder: 3v4l.org, en gratis online PHP-kodtestare för 300+ versioner samtidigt. Ingen installation, inga virtuella maskiner. I den här guiden visar jag hur du fångar inkompatibiliteter före release och demonstrerar verkliga fel som vi själva skeppade till produktion.

💡 Snabb överblick:

• Klistra in en PHP-kodsnutt på 3v4l.org och kör den mot alla versioner, från PHP 4.3.0 till senaste 8.5
• Granska den grupperade utdatan: sajten visar var koden fungerar, var den kastar fel och var beteendet skiljer sig
• Studera två klassiska inkompatibilitetsexempel som knäcker WordPress-plugins på gammal hosting, med kod och länkar till livedemonstrationer
• Jämför alternativa verifieringsmetoder: Docker-containrar, PHPBrew, inbyggd PhpStorm-inspektör, deras för- och nackdelar
• Se en EN-video som demonstrerar arbetsflödet TemPHPest + 3v4l direkt från VSCode

Varför manuell installation av gamla PHP-versioner är plågsam

Om du administrerar en Linux-server har du säkert märkt att gamla, icke-supportade PHP-grenar helt enkelt försvinner från pakethanterarna. Paketarkivet ppa:ondrej/php, huvudkällan för PHP-paket till Ubuntu, varnar ärligt under installationen:

Only supported versions of PHP for supported Ubuntu releases are provided.

I juni 2026 är de officiellt supportade grenarna 8.2, 8.3, 8.4 och 8.5. PHP 8.1 pensionerades i december 2025. PHP 7.4 har länge varit historia. Men på delade hostingtjänster och föråldrade VPS:er stöter du fortfarande på PHP 7.0, eller till och med 5.6. Att kontrollera kod mot dem lokalt är ett äventyr.

PHPBrew räddade dagen förr: verktyget kunde kompilera vilken PHP-version som helst från källkod och växla mellan dem med ett kommando. Men projektet har knappt uppdaterats sedan 2020, och att kompilera PHP 5.6 på Linux-kärna 6.x är en riktig pärs med patchar och kompatibilitetsflaggor. Docker-containrar är enklare men kräver att man skriver en Dockerfile för varje version, laddar ner avbilder och ändå äter upp gigabyte med diskutrymme.

Det finns ett alternativ, och det fungerar direkt i din webbläsare.

3V4l.org: din onlinetestare för 300+ PHP-versioner

3v4l.org (leetspeak för "eval") är en online-sandlåda som kör din PHP-kod på mer än 300 tolkversioner samtidigt. Från uråldriga PHP 4.3.0 till senaste 8.5. Projektets skapare har kompilerat och underhåller varje betydande version som släppts genom språkets historia.

Mekaniken är genialt enkel: klistra in en snutt i den vänstra panelen, tryck på eval(), och inom sekunder får du en resultattabell. Sajten grupperar versioner efter utdata: gröna rader betyder att koden kördes identiskt, gula/röda betyder att beteendet skiljer sig eller att ett fel uppstod. Du ser omedelbart vid vilken lägsta PHP-version din syntax blir acceptabel.

Det som är särskilt värdefullt: 3v4l.org visar feltexten för varje problematisk version. Inte ett abstrakt "inkompatibel", utan specifikt Parse error: syntax error, unexpected '[' in ..., med radnummer angivet. Detta sparar timmar av felsökning.

Varje test får en unik URL, länken kan bifogas en ärendehanteringspost, skickas till en teamledare eller användas som dokumentation: "Här är beviset på att match-uttryck går sönder på PHP 7.4."

Exempel 1: kort arraysyntax, en mina för WordPress

En utvecklare skriver i JavaScript, växlar till PHP och skapar av vana en array:

1
$a = [];

Ser harmlöst ut. På din lokala maskin med PHP 8.4 fungerar det. På en testserver med PHP 8.2 fungerar det också. Pusha till produktion, och kunder med PHP 5.6 får en vit skärm.

Kort arraysyntax [] dök upp först i PHP 5.4. Innan dess fanns bara array(). Och även om PHP 5.4 kom ut 2012, visade WordPress.org-statistik i årtionden en betydande andel installationer på PHP-versioner under 5.4. Situationen har förbättrats nu, men WordPress-plugins måste fortfarande ta hänsyn till kompatibilitetsnyanser.

Kör det här utdraget genom 3v4l.org](https://3v4l.org/v75em), så får du ett definitivt besked:

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

Inga gissningar, ingen manual att läsa för varje konstruktion. Tidsbesparing: 30 sekunder i stället för 15 minuters googlande på "vilken PHP-version stöder short array syntax".

Exempel 2: typhintar, när kod tyst går sönder på gammal PHP

Typdeklarationer gör PHP striktare och mer förutsägbart. Men utvecklingen av typhintar var ojämn, och det skapar en fälla. Titta på den här koden:

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]);

Ser ut som tre identiska deklarationer. Men test på 3v4l.org avslöjar en överraskning:

Skalära typerna string, int och bool kom först i PHP 7.0, 12 år efter klasstyper! Om ditt plugin anger lägsta PHP-version 5.6, och du använde function register(string $username), ger det här på gammal hosting ett kryptiskt fatal error:

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

Meddelandet är förvirrande: "must be an instance of string, string given." Kunden läser det som rappakalja och skriver en arg recension. Orsaken är enkel: PHP 5.6 förstår inte skalära typhintar och försöker tolka string som ett klassnamn.

Med 3v4l.org fångar du sådana inkompatibiliteter på en minut, inte efter ett dussin felrapporter.

Alternativ: IDE, Docker och konsollverktyg

3v4l.org täcker de flesta scenarier för kompatibilitetskontroll, men inte alla. Här är vad mer som finns i arsenalen, med för- och nackdelar.

PhpStorm. JetBrains inbyggda inspektör markerar syntax som är inkompatibel med den valda PHP-versionen: du anger "PHP 7.4" i inställningarna, och editorn stryker under match(), typade egenskaper, str_contains(). Men PhpStorm kostar pengar (prenumeration från $99/år), och kontrollen är statisk, det sker ingen faktisk kodexekvering. Inspektören visar inte skillnaden i array_key_last()-beteende mellan versioner, medan 3v4l.org gör det.

Docker. Det mest flexibla tillvägagångssättet: docker run -v $(pwd):/app php:5.6 php /app/test.php kör kod i en exakt miljö. Men att testa 10 versioner kräver 10 containrar, 10 olika images och ett automatiseringsskript. För snabb verifiering av kodsnuttar är det overkill.

Lokal PHPBrew. Som nämnts ovan är projektet fryst, och att bygga gamla PHP-versioner på en modern kärna kräver dans med patchar. År 2026 är det enklare att öppna 3v4l.org.

GitHub Actions / CI. En matris av PHP-versioner i CI (till exempel strategy.matrix.php: ['7.4', '8.0', '8.1', '8.2', '8.3', '8.4', '8.5']) fångar problem vid varje push. Det här är ett måste för bibliotek, men för WordPress-plugin-utvecklare som skriver i Sublime Text eller VSCode utan CI förblir 3v4l.org det mest tillgängliga och snabbaste verktyget.

Video: TemPHPest + 3v4l direkt från VSCode

TemPHPest-tillägget för VSCode integrerar 3v4l.org i editorn: markera kod, tryck på en kortkommando och få resultat på alla PHP-versioner utan att öppna en webbläsare. Tilläggets skapare spelade in en kort demonstration:

Kombinationen VSCode + TemPHPest + 3v4l.org ger en nästan sömlös upplevelse: skriv kod, kontrollera kompatibilitet direkt, åtgärda fel. Fungerar snabbare än att växla mellan editor och webbläsare.

⁉️🤔 Vanliga frågor

Är 3v4l.org gratis?

Ja, helt och hållet. Ingen registrering, inga begränsningar i antal körningar, inga annonser. Tjänsten är öppen källkod och körs på skaparens privata server. Om du använder den regelbundet kan du stödja författaren via GitHub Sponsors, vilket hjälper till att betala för hosting och el.

Vilka PHP-versioner finns tillgängliga på 3v4l.org?

Alla betydande releaser, från PHP 4.3.0 (släppt 2002) till den senaste 8.5 (november 2025). Varje mindre release är en separat rad i resultattabellen. Totalt antal, mer än 300 versioner. Om en version du behöver inte finns i listan lägger författaren till nya releaser snabbt.

Kan man testa hela projekt eller bara kodsnuttar?

3v4l.org är utformat för isolerade kodfragment, funktioner, klasser, enskilda algoritmer. Du kan klistra in flera hundra rader, men utan require och include med composer autoloading och databasanslutningar. För full integrationstestning av ett projekt passar Docker-containrar eller GitHub Actions med en PHP-versionsmatris bättre.

Är det säkert att klistra in känslig kod på en tredjepartsserver?

Nej. Kod på 3v4l.org får en publik URL och är tekniskt sett åtkomlig via direktlänk. Använd inte tjänsten för konfidentiell data, API-nycklar, lösenord, proprietär affärslogik. För proprietär kod, kör en lokal Docker-container: docker run -v $(pwd):/app php:7.4 php /app/private-code.php.

På vilket sätt är 3v4l.org bättre än inbyggd IDE-kontroll?

Statisk analys i IDE (PhpStorm, PHPStan) kontrollerar syntax och typer men kör inte kod. 3v4l.org kör faktiskt kodsnutten genom tolkar för alla versioner och visar faktisk utdata, skillnader i beteende hos array_key_last(), json_encode() och preg_match() mellan versioner. Dessutom krävs inget köp av IDE, det fungerar i en webbläsare.

Vad man ska välja för PHP-kodkompatibilitetskontroll 2026

För dagligt arbete som tema- och pluginutvecklare ser upplägget ut så här. En kodsnutt som väcker tvivel går direkt till 3v4l.org. Resultat på 5 sekunder, länk till testet bifogas commiten. Ett projekt där kompatibilitet med ett dussin PHP-versioner är viktigt, en matris i GitHub Actions: sätt upp den en gång, så körs varje push automatiskt. Snabbkoll av någon annans kod före kodgranskning, TemPHPest i VSCode (gratis, integrerat med 3v4l.org).

Det viktigaste som har förändrats jämfört med 2020 (när originalversionen av detta material först publicerades): PHP 5.6 har slutligen lämnat de flesta webbhotell, miniminivån blev PHP 7.4, och vid horisonten syns PHP 8.5 med nya funktioner och nya potentiella inkompatibiliteter. Men principen förblir oförändrad: kontrollera kompatibilitet före release, sov gott. 3v4l.org gör denna kontroll trivial.