PHP 8.2 fine supporto: migrare con prove nello staging

La fine del supporto di PHP 8.2 è fissata al 31 dicembre 2026. Da quel momento, il progetto PHP non pubblicherà più aggiornamenti di sicurezza per questa versione. Se il tuo sito gira ancora su PHP 8.2, non significa che smetterà di funzionare il primo gennaio. Significa però che continuerà a utilizzare un componente che non riceverà più correzioni ufficiali, anche quando verranno scoperti nuovi problemi.

È una distinzione importante, soprattutto per chi gestisce un sito WordPress, un e-commerce o un’applicazione sviluppata su misura. Il passaggio a una versione più recente richiede qualche controllo, ma aspettare che qualcosa si rompa è raramente la strategia migliore. Vediamo quali sono le scadenze, come capire quale PHP utilizza davvero il sito e come organizzare l’aggiornamento senza trasformarlo in un’emergenza.

Perché la fine del supporto di PHP 8.2 è una notizia da non ignorare

PHP è il linguaggio che fa funzionare buona parte dei siti dinamici. Nel caso di WordPress, per esempio, gestisce il codice lato server che genera le pagine, elabora i moduli e dialoga con il database. Il visitatore non vede la versione installata, ma ne dipende ogni volta che effettua una richiesta.

Il ciclo di vita ufficiale prevede una fase di supporto attivo, durante la quale arrivano correzioni ai bug e interventi di sicurezza, seguita da una fase dedicata alle vulnerabilità critiche. PHP 8.2 ha terminato il supporto attivo il 31 dicembre 2024 e concluderà quello di sicurezza il 31 dicembre 2026. Dopo questa data entrerà nella categoria delle versioni end of life (EOL).

La fine del supporto di PHP 8.2 non è quindi un nuovo bug, né un blocco imposto ai siti. Il problema è ciò che accade dopo: se emerge una vulnerabilità, non potrai più contare sul normale rilascio di una patch da parte del progetto PHP. Per un sito pubblico, soprattutto se contiene dati personali o gestisce ordini, non è un rischio da lasciare indefinitamente aperto.

L’aggiornamento critico di ottobre 2026 rende il tema ancora più concreto

Il 21 ottobre 2026 è stata pubblicata PHP 8.2.35, una release che risolve due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, potenzialmente sfruttabili per eseguire codice da remoto senza autenticazione. Il team PHP ha raccomandato l’aggiornamento immediato alle versioni corrette.

Questo episodio mostra perché le patch contano anche quando una versione è vicina alla pensione. Se devi ancora completare la migrazione, almeno verifica di utilizzare una release corretta del ramo 8.2.35 o successiva, se disponibile e prevista dal tuo fornitore. Aggiornare dentro il ramo 8.2 non sostituisce però la migrazione: è una misura necessaria nell’immediato, non una soluzione alla scadenza di dicembre.

Puoi consultare sia il calendario ufficiale di supporto PHP sia l’annuncio delle release di sicurezza del 21 ottobre 2026.

Quale versione scegliere al posto di PHP 8.2?

Non c’è una risposta identica per tutti. Se il sito utilizza temi e plugin aggiornati, hai generalmente più libertà di scelta. Se invece dipende da librerie vecchie o codice personalizzato, devi verificare la compatibilità prima del cambio.

Al 6 novembre 2026, il calendario ufficiale indica queste scadenze:

Versione	Supporto attivo fino al	Aggiornamenti di sicurezza fino al
PHP 8.2	31 dicembre 2024	31 dicembre 2026
PHP 8.3	31 dicembre 2025	31 dicembre 2027
PHP 8.4	31 dicembre 2026	31 dicembre 2028
PHP 8.5	31 dicembre 2027	31 dicembre 2029

PHP 8.4 rappresenta spesso una destinazione ragionevole per una migrazione pianificata, se tutti i componenti la supportano. PHP 8.5 offre un orizzonte di manutenzione più lungo, ma va scelta soltanto dopo avere verificato il software installato. PHP 8.3 può essere una tappa intermedia quando il progetto non è ancora pronto per i rami successivi; evita però di considerarla una soluzione definitiva, perché il suo supporto termina nel 2027.

Non scegliere semplicemente il numero più alto disponibile nel pannello del provider. Una versione recente non rende automaticamente compatibile un plugin abbandonato, un’estensione mancante o una vecchia libreria PHP. Conta il sistema completo, non soltanto l’interprete.

Come sapere quale versione PHP usa il tuo sito

Prima di parlare di migrazione, conviene rispondere a una domanda molto semplice: su quale versione PHP sta effettivamente girando il sito? È meno scontato di quanto sembri. Sullo stesso server possono convivere siti con versioni diverse e, in alcuni casi, il PHP usato dal terminale non coincide con quello che serve le pagine web.

Su WordPress: controlla lo stato di salute del sito

Dal pannello di amministrazione di WordPress apri Strumenti → Salute del sito → Informazioni → Server. Qui trovi la versione PHP utilizzata dall’installazione e altri dati tecnici utili. È un buon punto di partenza perché controlli il software che risponde realmente alle richieste del sito.

Se la tua installazione presenta avvisi relativi a PHP, leggili, ma non limitarti a premere il pulsante di aggiornamento. Prima controlla anche versione di WordPress, tema attivo, plugin indispensabili e componenti premium. Un’estensione che riceve aggiornamenti regolari offre generalmente prospettive migliori di una che non viene mantenuta da anni, ma la verifica di compatibilità resta necessaria.

Su Plesk e sugli altri pannelli hosting

In Plesk puoi aprire il dominio e raggiungere Dashboard → Impostazioni PHP. Il pannello mostra la versione assegnata e, secondo la configurazione, il relativo handler. Cambiare la selezione è semplice; capire se il sito continuerà a funzionare dopo il cambio è la parte che richiede attenzione.

Su cPanel o altri servizi di hosting la voce può chiamarsi MultiPHP Manager, PHP Selector o in modo simile. Se non trovi l’opzione, contatta il provider: non tutti i piani permettono di installare o scegliere liberamente qualsiasi ramo.

Da terminale: controlla versione ed estensioni

Se amministri una VPS o un server dedicato, questi comandi forniscono le prime informazioni:

php -v
php --ini
php -m

Il primo stampa la versione PHP della riga di comando; il secondo indica i file di configurazione caricati; il terzo elenca le estensioni attive. Attenzione: il risultato di php -v non dimostra quale PHP usa il sito web. Un server con PHP-FPM, per esempio, può utilizzare un eseguibile diverso per il dominio. Confronta quindi le informazioni della CLI con quelle del pannello e del pool web interessato.

Evita di lasciare online una pagina phpinfo() accessibile a chiunque. È comoda per fare diagnosi, ma espone molti dettagli della configurazione e va rimossa subito dopo l’uso, se davvero necessaria.

Il vero ostacolo non è PHP: sono le dipendenze del sito

Quando si parla di aggiornamento PHP, viene spontaneo pensare a un’operazione di pochi clic. Spesso è così per il cambio di versione in sé. I problemi iniziano quando il sito usa componenti che si aspettano comportamenti presenti soltanto nelle release precedenti.

Su WordPress i primi elementi da esaminare sono il core, il tema, i plugin, gli strumenti di cache e le eventuali personalizzazioni nel tema figlio. Un sito può aprirsi correttamente e mostrare l’errore soltanto quando un visitatore invia un modulo, quando parte un pagamento o quando un plugin elabora un file.

Nelle applicazioni PHP personalizzate controlla framework, pacchetti Composer, estensioni native, accesso a MySQL o MariaDB, gestione delle sessioni e script eseguiti da cron. Se il progetto utilizza Composer, il file composer.lock aiuta a ricostruire le dipendenze effettivamente installate. Testa i requisiti con l’interprete di destinazione, non soltanto con quello vecchio.

Un’estensione che non supporta PHP 8.4 o 8.5 non si risolve abbassando il livello di segnalazione degli errori. A volte serve aggiornare una libreria, sostituire un componente oppure intervenire su poche righe di codice. Altre volte emerge un problema più ampio: il progetto non riceve manutenzione da tempo.

Aggiornare PHP senza mettere a rischio il sito: il metodo pratico

Il percorso più affidabile non consiste nel cambiare subito la versione in produzione e controllare se la homepage compare ancora. Serve una copia su cui provare tutte le funzioni importanti. Anche per un sito di piccole dimensioni bastano pochi accorgimenti per evitare gli errori più frequenti.

1. Fai un backup che sai ripristinare

Salva file, database e configurazione. Se gestisci un e-commerce, presta attenzione ai dati che possono cambiare tra il backup e l’intervento: ordini, clienti e pagamenti non devono sparire durante un eventuale ritorno alla versione precedente. Un backup mai verificato è una promessa, non un piano di recupero.

2. Crea uno staging e aggiorna i componenti

Prepara un ambiente di prova separato, possibilmente sullo stesso tipo di hosting e con le stesse estensioni. Blocca l’indicizzazione, limita gli accessi e sostituisci le credenziali di pagamento, email e servizi esterni con quelle di test. Uno staging non deve spedire newsletter o effettuare addebiti reali.

Prima aggiorna core, plugin, tema e librerie secondo le indicazioni dei rispettivi produttori. Poi seleziona la versione PHP di destinazione. Separare le due operazioni aiuta a capire da dove proviene un errore.

3. Prova le funzioni che contano, non soltanto la homepage

Per un blog controlla login, pubblicazione, ricerca, caricamento immagini, form di contatto e invio email. Per un negozio verifica carrello, checkout in modalità test, calcolo dei costi, notifiche e aggiornamento dello stato degli ordini. Per una webapp aggiungi esportazioni, importazioni, API, autenticazione e attività pianificate.

Controlla anche i log di PHP e del web server. Una pagina che si apre può comunque produrre avvisi o errori in una funzione utilizzata raramente. Se qualcosa non va, annota il percorso preciso e prova a riprodurre il problema prima di cambiare altri componenti.

4. Esegui il cambio in produzione e tieni pronto il ritorno

Scegli un momento con traffico ridotto, crea un backup aggiornato e applica solo la configurazione già testata. Verifica immediatamente i percorsi essenziali e controlla i log anche nelle ore successive, soprattutto se il sito utilizza cron, code o elaborazioni notturne.

Per tornare indietro potrebbe non bastare selezionare PHP 8.2: se hai cambiato anche codice e struttura del database, devi sapere quali elementi ripristinare insieme. È il motivo per cui un piano di rollback va preparato prima di modificare la produzione, non durante un guasto.

Gli errori più comuni dopo il cambio di versione

I sintomi possono essere molto diversi. Una pagina bianca o un errore 500 suggeriscono di controllare immediatamente i log applicativi e PHP-FPM. Un errore di tipo può segnalare che il codice passa a una funzione un valore non più accettato. Un plugin che non esegue un’operazione potrebbe dipendere da una libreria incompatibile o da un’estensione non caricata.

Le segnalazioni di deprecation meritano attenzione, ma non vanno confuse automaticamente con un blocco del servizio. Segnalano comportamenti destinati a cambiare o sparire in futuro. Nasconderle dal pubblico è corretto; ignorarle anche nei log e nei test non lo è.

Quando trovi un problema, evita di disattivare dieci plugin contemporaneamente. Procedi per esclusione in staging e tieni traccia di ciò che modifichi. Se il difetto riguarda un componente commerciale, contatta lo sviluppatore indicando versione del plugin, PHP di destinazione, messaggio d’errore e passaggi per riprodurlo, senza inviare password o dati personali.

Se non puoi aggiornare subito, cosa puoi fare?

Capita soprattutto con gestionali, portali aziendali e software scritto diversi anni fa. Un’applicazione può essere essenziale per il lavoro e, allo stesso tempo, non essere pronta per PHP 8.4 o 8.5. In questo caso la scelta peggiore è lasciare la questione senza una data e senza un responsabile.

Fino alla scadenza, mantieni il ramo 8.2 aggiornato con le correzioni ufficiali disponibili, a partire dalla release di sicurezza 8.2.35 del 21 ottobre 2026. Valuta poi con lo sviluppatore quali incompatibilità impediscono la migrazione e quanto lavoro serve per eliminarle.

Alcuni fornitori offrono manutenzione di sicurezza estesa per versioni PHP fuori dal ciclo ufficiale. Può essere una soluzione temporanea, ma bisogna verificare chi distribuisce le patch, quali problemi copre e per quanto tempo. Non è la stessa cosa del supporto garantito direttamente dal progetto PHP.

Nel frattempo puoi limitare l’esposizione del sistema, rivedere gli accessi amministrativi e monitorare con più attenzione gli errori e gli eventi di sicurezza. Nessuno di questi accorgimenti sostituisce una patch mancante: servono a gestire il rischio mentre prepari una soluzione sostenibile.

Una versione più recente rende anche il sito più veloce?

È possibile ottenere benefici, ma non aspettarti un miglioramento identico su ogni progetto. Le prestazioni dipendono da codice, query SQL, opcache, cache applicativa, configurazione del server e risorse disponibili. In alcuni casi il cambio di PHP riduce i tempi di elaborazione; in altri il collo di bottiglia rimane altrove.

Per confrontare due versioni, misura gli stessi percorsi in condizioni simili: tempi di risposta, utilizzo di memoria, errori e funzioni più utilizzate. Se vuoi approfondire l’ottimizzazione oltre la migrazione, trovi altri controlli pratici nella nostra guida su come migliorare la velocità di un sito WordPress.

Ricorda però l’ordine delle priorità: prima compatibilità e sicurezza, poi prestazioni. Un checkout più veloce non è un successo se non completa correttamente gli ordini.

Cosa conviene fare prima del 31 dicembre 2026

La fine del supporto di PHP 8.2 non deve diventare una corsa dell’ultimo giorno. Se amministri uno o due siti WordPress, la prima verifica può richiedere meno di un’ora: scopri la versione in uso, controlla temi e plugin, verifica la disponibilità di uno staging e organizza un backup. Con applicazioni personalizzate o molti domini il lavoro aumenta, ma il metodo resta lo stesso.

La scelta più sensata è individuare una versione supportata e compatibile, provarla su una copia del sito e pianificare il passaggio. Se una dipendenza blocca tutto, documenta il motivo e stabilisci un intervento preciso. Il sito potrà anche continuare a funzionare nel 2027 con PHP 8.2, ma questo non significa che sia una buona idea lasciarlo lì.