Fine supporto PHP 8.2: cosa fare entro il 31/12/2026

Cosa succede davvero il 31 dicembre 2026

Ogni ramo di PHP segue un ciclo di vita pubblicato su php.net: due anni di supporto attivo, in cui vengono corretti bug e problemi di sicurezza, poi altri due anni di solo supporto di sicurezza, con rilasci pubblicati soltanto quando servono. Finiti i quattro anni il ramo raggiunge la fine del ciclo di vita (end of life, EOL) e non riceve più alcuna correzione.

PHP 8.2 è uscito l'8 dicembre 2022. Il supporto attivo si è chiuso il 31 dicembre 2024: da quasi due anni riceve solo correzioni di sicurezza critiche, non più quelle dei bug ordinari. Il 31 dicembre 2026 termina anche questa fase. Ecco la situazione dei rami recenti secondo php.net:

Il 1° gennaio 2027 non si spegne nulla: il sito risponderà esattamente come il giorno prima. Cambia il fatto che ogni vulnerabilità scoperta da quel momento nel motore PHP non avrà più una correzione ufficiale per il ramo 8.2. Chi è ancora su PHP 8.1 o precedenti è già in questa situazione e deve seguire lo stesso piano, con un salto più lungo.

I rischi concreti di restare su PHP 8.2

• Sicurezza: php.net avverte che chi usa un ramo a fine vita può essere esposto a vulnerabilità che non verranno corrette. Il rischio non esplode il primo giorno, ma cresce con ogni mese che passa.
• Plugin e temi bloccati: gli sviluppatori alzano gradualmente il valore «Requires PHP». Quando la nuova versione di un plugin richiede un PHP più recente, WordPress ti avvisa che non funziona con la tua versione e non mostra il pulsante di aggiornamento. Resti fermo su una release vecchia, con i suoi bug.
• Dipendenze Composer: framework e librerie fissano una versione minima di PHP; restare indietro blocca gli aggiornamenti dell'intera catena di pacchetti.
• Disponibilità sul server: dopo la fine vita alcuni provider tolgono le versioni non supportate dai pannelli o le mantengono solo per un periodo limitato. Chiedi al tuo provider cosa farà e da quando.

Come verificare quale versione PHP usa il tuo sito

Sullo stesso server possono convivere più versioni di PHP: una per il sito, un'altra per la riga di comando, a volte una diversa per ogni dominio. Quella che conta è la versione che serve davvero le pagine.

1. Bacheca WordPress: Strumenti > Salute del sito > Info > Server. Trovi la versione PHP usata dal web server e i limiti principali.
2. cPanel: apri MultiPHP Manager. L'elenco mostra la versione di ogni dominio. Se compare «inherit», il dominio usa la versione predefinita del server, decisa dall'amministratore: potrebbe cambiare senza che tu tocchi nulla.
3. Plesk o pannelli proprietari: controlla le impostazioni PHP del singolo dominio, non quelle generali dell'account.
4. Senza pannello: crea un file temporaneo che stampi solo PHP_VERSION, aprilo dal browser e cancellalo subito. Non lasciare online una pagina phpinfo(), che espone molti dettagli del server.

# Versione della riga di comando: può essere diversa da quella del sito
php -v

# PHP usato da WP-CLI (anche questo è il PHP da riga di comando)
wp cli info

# Progetti Composer: quali pacchetti impediscono il passaggio a PHP 8.4
composer why-not php 8.4

WordPress e plugin: compatibilità con PHP 8.3 e 8.4

Sul core, se è aggiornato, c'è poco da temere. WordPress raccomanda ufficialmente PHP 8.3 o superiore e la tabella di compatibilità del core indica queste soglie:

Da WordPress 7.0 il core richiede almeno PHP 7.4. Ma «compatibile» riguarda il core: i problemi veri nascono quasi sempre da plugin, temi, page builder e codice scritto su misura. Nel readme dei plugin il campo «Requires PHP» indica solo la versione minima, mentre «Tested up to» si riferisce alla versione di WordPress, non a quella di PHP. Non esiste un campo ufficiale che dichiari fino a quale PHP un plugin è stato testato: lo scopri solo con i test o chiedendo allo sviluppatore.

Cosa cambia nel codice passando da 8.2 a 8.3 e 8.4

• PHP 8.3 ha un elenco di incompatibilità breve e mirato: per esempio range() ora genera errori con argomenti non validi e number_format() rispetta i decimali negativi.
• PHP 8.4 depreca i parametri «implicitamente nullable», come function foo(Tipo $a = null) senza il punto interrogativo davanti al tipo. È il caso più diffuso nel codice datato e produce avvisi di deprecazione, non errori.
• Con 8.4 alcune estensioni escono dalla distribuzione standard e passano a PECL, tra cui IMAP e PSpell. Se un plugin legge caselle email via IMAP, verifica che l'estensione sia ancora installata sul server.
• Sempre in 8.4 diventano deprecati la costante E_STRICT, trigger_error() con E_USER_ERROR e le funzioni mysqli_ping(), mysqli_kill() e mysqli_refresh().

8.3, 8.4 o 8.5: quale versione scegliere

Se aggiorni adesso, conviene un salto che duri. PHP 8.3 riceve già solo patch di sicurezza e arriva a fine vita il 31 dicembre 2027: tra un anno saresti di nuovo qui. PHP 8.4 è coperto fino al 31 dicembre 2028 ed è supportato dal core WordPress dalla 6.7: per la maggior parte dei siti, secondo noi, è il compromesso più prudente. PHP 8.5 arriva al 2029, ma è il ramo più giovane: ha senso se lo stack è recente e hai test che lo dimostrano.

Piano di aggiornamento passo passo, con staging

1. Inventario: per ogni sito annota versione PHP, versione di WordPress, tema, plugin attivi e licenze premium. Un plugin con licenza scaduta spesso non si aggiorna, e blocca l'intero piano.
2. Backup completo di file e database, verificato: prova a ripristinarlo almeno una volta in un ambiente separato.
3. Aggiorna core, tema e plugin restando sul PHP attuale. Così separi i problemi degli aggiornamenti da quelli del cambio di versione.
4. Crea una copia di staging con la stessa configurazione della produzione: stesse estensioni PHP, stessi limiti di memoria, stesso web server. Bloccane l'indicizzazione e disattiva l'invio di email reali e i webhook dei pagamenti.
5. In staging attiva il log degli errori di WordPress (snippet qui sotto) e porta PHP a 8.4.
6. Testa i percorsi critici: home e pagine principali, login e bacheca, editor e page builder, moduli di contatto, ricerca, carrello e checkout in modalità test, caricamento immagini, attività pianificate, plugin di backup.
7. Leggi wp-content/debug.log e il log PHP del server. Separa gli errori fatali, da risolvere subito, dalle deprecazioni, da pianificare.
8. Correggi: aggiorna o sostituisci i plugin problematici, chiedi una patch allo sviluppatore, sistema il codice su misura. Nei progetti Composer esegui composer check-platform-reqs con il nuovo PHP.
9. Scegli una finestra di basso traffico, avvisa il cliente e fai un nuovo backup subito prima del passaggio.
10. Cambia la versione PHP in produzione, svuota la cache di pagina e quella della CDN, poi ripeti i test principali.
11. Nei giorni successivi controlla log e attività pianificate: alcuni problemi emergono solo con i cron notturni o con i picchi di traffico.

// wp-config.php, SOLO in staging: prima della riga "That's all, stop editing!"
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );       // scrive in wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // niente errori a schermo
@ini_set( 'display_errors', 0 );

Rollback: come tornare indietro senza fare danni

Riportare la versione di PHP a quella precedente dal pannello richiede pochi secondi, ed è il motivo per cui questo intervento si può fare riducendo al minimo l'interruzione. Tornare a 8.2, però, non annulla quello che è successo nel frattempo.

• Se durante il lavoro hai installato nuove versioni di plugin, queste possono aver modificato il database: per tornare davvero allo stato precedente serve ripristinare anche il backup del database.
• Su un e-commerce, ripristinare il database significa perdere ordini e registrazioni arrivati dopo il backup. Decidi prima chi controlla e fino a quando il rollback è accettabile.
• Scrivi in anticipo la soglia di rollback, per esempio un errore fatale su checkout o login che non riesci a correggere entro un tempo concordato.
• Ricorda che il ritorno a 8.2 è una misura temporanea: dopo il 31 dicembre è solo un rinvio, non un punto d'arrivo.

Checklist per agenzie che gestiscono molti siti

• Un unico foglio con tutti i siti: versione PHP attuale, data prevista del passaggio, responsabile.
• Obiettivo PHP 8.4 per tutti entro dicembre; 8.3 solo come ripiego per i siti con un blocco documentato, con una data per risolverlo.
• Priorità ai siti con e-commerce, aree riservate o plugin che non vengono aggiornati da molto tempo.
• Verifica delle licenze premium di temi e plugin prima di cominciare, non durante.
• Comunicazione al cliente: cosa cambia, quando, chi contattare se nota qualcosa di strano.
• Domini impostati su «inherit»: assegna una versione esplicita, così un cambio della versione predefinita del server non ti coglie di sorpresa.
• A lavoro finito, annota nel contratto di manutenzione la prossima scadenza: con PHP 8.4 è il 31 dicembre 2028.

Se preferisci che sia qualcun altro a gestirlo, il team di lubemy può seguire con te inventario, staging e cambio di versione, sito per sito. In ogni caso il calendario è questo: la scadenza è il 31 dicembre, ma i test vanno iniziati adesso.