Hai scritto codice PHP funzionante sull’ultima versione, lo hai messo in produzione e ti è arrivata una valanga di segnalazioni di bug da clienti su hosting obsoleti. Ti suona familiare? Una sintassi che a te sembra «ovvia» diventa un errore fatale su PHP 7.0. Installare una dozzina di versioni datate in locale per verificare ogni frammento è un lavoro di mezza giornata, sempre che sia possibile.

Il problema è più profondo di quanto sembri. Le vecchie versioni di PHP spariscono dai repository ufficiali, non compilano sui kernel Linux moderni ed entrano in conflitto con le estensioni. WordPress gira ancora su server in cui l’hosting non si è preoccupato di aggiornare PHP. Risultato: il tuo plugin o tema si rompe per centinaia di utenti solo perché hai usato un argomento tipizzato string o la sintassi abbreviata per gli array.

Ma c’è uno strumento che risolve il problema in pochi secondi: 3v4l.org, un tester PHP online gratuito su oltre 300 versioni in simultanea. Nessuna installazione, nessuna macchina virtuale. In questa guida ti mostro come individuare le incompatibilità prima del rilascio, con esempi concreti di errori che noi stessi abbiamo mandato in produzione.

💡 Panoramica rapida:

• Incolla un frammento di codice PHP su 3v4l.org ed eseguilo su tutte le versioni, da PHP 4.3.0 fino all’ultima 8.5
• Analizza l’output raggruppato: il sito mostra dove il codice funziona, dove genera errori e dove il comportamento cambia
• Studia due classici esempi di incompatibilità che rompono i plugin WordPress sugli hosting obsoleti, con codice e link a test dal vivo
• Confronta metodi di verifica alternativi: container Docker, PHPBrew, l’ispettore integrato di PhpStorm, con pro e contro
• Guarda un video in inglese che mostra il flusso di lavoro TemPHPest + 3v4l direttamente da VSCode

Perché l’installazione manuale delle vecchie versioni di PHP è un calvario

Se amministri un server Linux lo avrai notato di sicuro: i rami PHP vecchi e non più supportati spariscono semplicemente dai gestori di pacchetti. Il repository ppa:ondrej/php, la fonte principale di pacchetti PHP per Ubuntu, avvisa onestamente durante l’installazione:

Vengono fornite solo le versioni supportate di PHP per i rilasci Ubuntu supportati.

A giugno 2026 i rami ufficialmente supportati sono 8.2, 8.3, 8.4 e 8.5. PHP 8.1 è andato in pensione a dicembre 2025. PHP 7.4 è storia da un pezzo. Ma sugli hosting condivisi e sui VPS obsoleti si incontrano ancora PHP 7.0, o perfino 5.6. Verificare il codice su queste versioni in locale è un’impresa.

PHPBrew un tempo salvava la situazione: l’utility compilava qualsiasi versione di PHP dai sorgenti e permetteva di passare dall’una all’altra con un comando. Ma il progetto non viene praticamente più aggiornato dal 2020 e compilare PHP 5.6 su kernel Linux 6.x è un bel rompicapo tra patch e flag di compatibilità. I container Docker sono più semplici, ma richiedono di scrivere un Dockerfile per ogni versione, scaricare le immagini e occupare comunque gigabyte di spazio su disco.

Esiste un’alternativa, e funziona direttamente nel browser.

3V4l.org: il tuo tester online per oltre 300 versioni di PHP

3v4l.org (leetspeak per «eval») è un sandbox online che esegue il tuo codice PHP su più di 300 versioni dell’interprete in simultanea. Dall’antico PHP 4.3.0 fino all’ultimo 8.5. Il creatore del progetto ha compilato e mantiene ogni versione significativa pubblicata nell’intera storia del linguaggio.

Il meccanismo è semplice fino al genio: incolli un frammento nel pannello di sinistra, premi eval() e in pochi secondi ottieni una tabella di risultati. Il sito raggruppa le versioni in base all’output: le righe verdi indicano che il codice è stato eseguito in modo identico, quelle gialle/rosse che il comportamento cambia o che si è verificato un errore. Vedi subito a partire da quale versione minima di PHP la tua sintassi diventa accettabile.

La cosa più preziosa: 3v4l.org mostra il testo dell’errore per ogni versione problematica. Non un astratto «incompatibile», ma uno specifico Parse error: syntax error, unexpected '[' in ..., con il numero di riga indicato. Questo fa risparmiare ore di debugging.

Ogni test riceve un URL univoco; il link può essere allegato a un ticket, inviato a un team lead o usato come documentazione: «Ecco la prova che le espressioni match si rompono su PHP 7.4».

Esempio 1: sintassi abbreviata per gli array, una mina per WordPress

Uno sviluppatore scrive in JavaScript, passa a PHP e per abitudine crea un array:

1
$a = [];

Sembra innocuo. Sulla tua macchina locale con PHP 8.4 funziona. Su un server di test con PHP 8.2 funziona anche. Mandi in produzione e i clienti con PHP 5.6 vedono una schermata bianca.

La sintassi abbreviata [] è comparsa solo in PHP 5.4. Prima esisteva solo array(). E sebbene PHP 5.4 sia uscito nel 2012, le statistiche di WordPress.org hanno mostrato per decenni una quota significativa di installazioni su versioni PHP inferiori alla 5.4. Oggi la situazione è migliorata, ma i plugin WordPress devono ancora tenere conto delle sfumature di compatibilità.

Esegui questo snippet su 3v4l.org e ottieni un verdetto definitivo:

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

Niente congetture, niente lettura del manuale per ogni costrutto. Tempo risparmiato: 30 secondi invece di 15 minuti a cercare su Google «quale versione PHP supporta la sintassi short per gli array».

Esempio 2: type hint, quando il codice si rompe in silenzio su vecchie versioni PHP

Le dichiarazioni di tipo rendono PHP più rigoroso e prevedibile. Ma l'evoluzione dei type hint è stata disomogenea, e questo crea una trappola. Guarda questo codice:

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

Sembrano tre dichiarazioni identiche. Ma testandolo su 3v4l.org emerge una sorpresa:

I tipi scalari string, int e bool sono arrivati solo con PHP 7.0, 12 anni dopo i tipi classe! Se il tuo plugin dichiara una versione PHP minima 5.6 e hai usato function register(string $username), su un hosting obsoleto questo produce un criptico fatal error:

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

Il messaggio è fuorviante: «must be an instance of string, string given». Il cliente lo legge come un geroglifico e scrive una recensione furiosa. Il motivo è semplice: PHP 5.6 non capisce i type hint scalari e cerca di interpretare string come nome di una classe.

Con 3v4l.org scovi queste incompatibilità in un minuto, non dopo una dozzina di bug report.

Alternative: IDE, Docker e utility da console

3v4l.org copre la maggior parte degli scenari di verifica della compatibilità, ma non tutti. Ecco cos'altro c'è nell'arsenale, con pro e contro.

PhpStorm. L'ispettore integrato di JetBrains evidenzia la sintassi incompatibile con la versione PHP selezionata: specifichi «PHP 7.4» nelle impostazioni e l'editor sottolinea match(), le proprietà tipizzate, str_contains(). Tuttavia, PhpStorm costa (abbonamento da $99/anno) e il controllo è statico, non c'è esecuzione reale del codice. L'ispettore non mostra la differenza di comportamento di array_key_last() tra le versioni, mentre 3v4l.org sì.

Docker. L'approccio più flessibile: docker run -v $(pwd):/app php:5.6 php /app/test.php esegue il codice in un ambiente esatto. Ma testare 10 versioni richiede 10 container, 10 immagini diverse e uno script di automazione. Per la verifica rapida di uno snippet, è sproporzionato.

PHPBrew locale. Come accennato sopra, il progetto è congelato e compilare versioni antiche di PHP su un kernel moderno richiede acrobazie con le patch. Nel 2026, è più semplice aprire 3v4l.org.

GitHub Actions / CI. Una matrice di versioni PHP nella CI (ad esempio, strategy.matrix.php: ['7.4', '8.0', '8.1', '8.2', '8.3', '8.4', '8.5']) intercetta i problemi a ogni push. È un must per le librerie, ma per chi sviluppa plugin WordPress in Sublime Text o VSCode senza CI, 3v4l.org resta lo strumento più accessibile e veloce.

Video: TemPHPest + 3v4l direttamente da VSCode

L'estensione TemPHPest per VSCode integra 3v4l.org nell'editor: selezioni il codice, premi una scorciatoia da tastiera e ottieni i risultati su tutte le versioni PHP senza aprire il browser. L'autore dell'estensione ha registrato una breve dimostrazione:

La combinazione VSCode + TemPHPest + 3v4l.org offre un'esperienza quasi senza interruzioni: scrivi codice, verifichi subito la compatibilità, correggi gli errori. Funziona più velocemente che passare dall'editor al browser.

⁉️🤔 Domande frequenti

3v4l.org è gratuito?

Sì, completamente. Nessuna registrazione, nessun limite sul numero di esecuzioni, nessuna pubblicità. Il servizio è open source e gira sul server personale del creatore. Se lo usi con regolarità, puoi supportare l'autore tramite GitHub Sponsors, contribuendo a coprire i costi di hosting ed elettricità.

Quali versioni di PHP sono disponibili su 3v4l.org?

Tutte le release significative, a partire da PHP 4.3.0 (pubblicato nel 2002) fino all'ultima 8.5 (novembre 2025). Ogni release minore è una riga separata nella tabella dei risultati. In totale, più di 300 versioni. Se una versione necessaria non è presente nell'elenco, l'autore aggiunge tempestivamente le nuove release.

Si possono testare interi progetti o solo frammenti?

3v4l.org è pensato per frammenti di codice isolati, funzioni, classi, singoli algoritmi. Puoi incollare diverse centinaia di righe, ma senza require e include con autoloading di Composer e connessioni a database. Per il test di integrazione completo di un progetto, sono più adatti i container Docker o GitHub Actions con una matrice di versioni PHP.

È sicuro incollare codice sensibile su un server di terze parti?

No. Il codice su 3v4l.org ottiene un URL pubblico ed è tecnicamente accessibile tramite link diretto. Non usare il servizio per dati confidenziali, chiavi API, password, logica di business proprietaria. Per codice proprietario, esegui un container Docker in locale: docker run -v $(pwd):/app php:7.4 php /app/private-code.php.

In cosa 3v4l.org è migliore del controllo integrato nell'IDE?

L'analisi statica nell'IDE (PhpStorm, PHPStan) verifica sintassi e tipi ma non esegue il codice. 3v4l.org esegue realmente il frammento attraverso gli interpreti di tutte le versioni e mostra l'output effettivo, le differenze di comportamento di array_key_last(), json_encode() e preg_match() tra le versioni. Inoltre, non richiede l'acquisto di un IDE, funziona nel browser.

Cosa scegliere per la verifica della compatibilità del codice PHP nel 2026

Per il lavoro quotidiano come autore di temi e plugin, lo schema è questo. Un frammento che solleva dubbi va direttamente su 3v4l.org. Risultato in 5 secondi, il link al test viene allegato al commit. Per un progetto in cui la compatibilità con una dozzina di versioni PHP è importante, una matrice su GitHub Actions: la configuri una volta e ogni push viene eseguito automaticamente. Per una verifica rapida del codice altrui prima di una code review, TemPHPest su VSCode (gratuito, integrato con 3v4l.org).

La cosa principale che è cambiata rispetto al 2020 (quando è apparsa la versione originale di questo materiale): PHP 5.6 ha finalmente lasciato la maggior parte delle piattaforme di hosting, la soglia minima è diventata PHP 7.4 e all'orizzonte c'è PHP 8.5 con nuove funzionalità e nuove potenziali incompatibilità. Ma il principio resta invariato: verifica la compatibilità prima del rilascio, dormi sonni tranquilli. 3v4l.org rende questa verifica banale.