Un WordPress fermo da anni ha di solito una storia simile. Il sito funziona, gli aggiornamenti automatici dei plugin sono stati disattivati dopo un problema, e nella bacheca compare un avviso che invita ad aggiornare PHP. Chi prova a farlo dal pannello dell’hosting scopre che un plugin va in errore, torna alla versione precedente e rimanda. Intanto il core resta indietro, perché le versioni nuove richiedono un PHP più recente, e il PHP resta indietro perché il sito non regge quello nuovo.
In questo articolo vediamo come uscire da questo blocco senza fermare il sito: quali versioni di PHP richiede WordPress e fino a quale versione del core si può arrivare con il PHP che hai, come preparare l’ambiente di prova, in che ordine alternare gli aggiornamenti di PHP, core, temi e plugin e come fare il passaggio in produzione con la possibilità di tornare indietro in pochi secondi.
Perché WordPress resta indietro
WordPress alza periodicamente la versione minima di PHP richiesta dal core. Quando succede, i siti con un PHP più vecchio smettono di ricevere la proposta di aggiornamento alla nuova versione principale e restano sull’ultima compatibile. Ufficialmente è supportata solo la versione più recente di WordPress: il team di sicurezza riporta le correzioni sui rami precedenti quando lo ritiene utile, ma senza garanzia, e a luglio 2025 ha smesso di farlo per i rami dal 4.1 al 4.6.
Lo stesso meccanismo vale per i plugin. Dalla versione 5.2 WordPress legge l’intestazione Requires PHP e impedisce di attivare un plugin che richiede un PHP più recente di quello installato. Molti autori, quando adeguano il codice a PHP 8, alzano anche il requisito minimo: il sito resta così con versioni dei plugin vecchie, che spesso contengono vulnerabilità corrette nelle release successive.
Le soglie di PHP di WordPress
Negli ultimi anni la versione minima di PHP è salita quattro volte. La tabella indica, per ogni versione di PHP, l’ultima versione principale di WordPress che si può installare. A novembre 2026 WordPress raccomanda PHP 8.3 o superiore, come indicato nella pagina dei requisiti e nel chiarimento pubblicato su Make WordPress a maggio 2026.
| PHP installato | Ultima versione principale di WordPress | Motivo |
|---|---|---|
| 5.6 | 6.2 | WordPress 6.3 (agosto 2023) richiede PHP 7.0 |
| 7.0 e 7.1 | 6.5 | WordPress 6.6 (luglio 2024) richiede PHP 7.2.24 |
| 7.2 e 7.3 | 6.9 | WordPress 7.0 (maggio 2026) richiede PHP 7.4 |
| 7.4 e successive | 7.0 e successive | versione minima attuale |
La conseguenza pratica è che il percorso di aggiornamento è fatto di gradini. Un sito su PHP 7.0 può arrivare a WordPress 6.5 senza cambiare interprete; per salire oltre deve prima passare a un PHP più recente. Conoscere questi gradini permette di pianificare la sequenza senza tentativi.
Prima di tutto: inventario e copia di prova
Nessun aggiornamento si prova sul sito in produzione. Il primo passo è una copia completa, database e cartella di WordPress, su un server di prova con la stessa versione di PHP della produzione e con la possibilità di installarne altre accanto. Sui server Linux è normale avere più versioni di PHP-FPM in parallelo, dai repository della distribuzione o da quelli di terze parti come Remi e deb.sury.org, e scegliere per ogni sito quale usare.
Sulla copia si raccoglie l’inventario, che con WP-CLI richiede pochi comandi:
# Copia di sicurezza di database e contenuti prima di ogni passo
wp db export prima-del-passo-1.sql
tar czf wp-content-passo-1.tar.gz wp-content
# Versione del core, plugin e temi con gli aggiornamenti disponibili
wp core version
wp plugin list --fields=name,status,version,update_version
wp theme list --fields=name,status,version,update_version
# I file del core e dei plugin del repository ufficiale sono integri?
wp core verify-checksums
wp plugin verify-checksums --all
# Sulla copia di prova: niente email ai clienti, URL del server di prova
wp search-replace 'https://www.example.it' 'https://prova.example.it' --skip-columns=guidIl controllo delle checksum è importante su un sito fermo da tempo: segnala file del core o dei plugin modificati a mano, che un aggiornamento sovrascriverà, e a volte file aggiunti da un’intrusione passata. Per ogni plugin annota tre cose: se è ancora mantenuto, se l’ultima versione richiede un PHP più recente e se è un plugin a pagamento con la licenza scaduta, perché in quel caso gli aggiornamenti non arrivano dal pannello.
Sulla copia attiva anche il log degli errori di WordPress, scrivendo in wp-config.php le costanti WP_DEBUG e WP_DEBUG_LOG a true e WP_DEBUG_DISPLAY a false. Gli avvisi finiscono in wp-content/debug.log e diventano l’elenco di lavoro dei passi successivi.
La scala: un passo di PHP, un passo di WordPress
Il principio è semplice: si aggiorna tutto quello che funziona sul PHP attuale, poi si sale di un gradino con PHP, poi di nuovo con WordPress e i plugin. Immaginiamo, come scenario di esempio, un sito con WordPress 5.8 su PHP 7.0. La sequenza sulla copia di prova è questa:
- plugin e tema all’ultima versione che dichiara di funzionare con PHP 7.0;
- core fino a WordPress 6.5, l’ultima versione principale per PHP 7.0, seguito da
wp core update-db; - passaggio a PHP 7.4, un gradino intermedio che di solito richiede poche correzioni;
- core alla versione corrente, plugin e tema alle versioni che richiedono PHP 7.4 o superiore;
- passaggio a PHP 8.3, la versione raccomandata, con la lettura attenta del log;
- correzione, sostituzione o rimozione di ciò che resta incompatibile.
Dopo ogni passo si fa una copia del database e si provano i percorsi che contano: la home, una pagina e un articolo, i moduli di contatto, l’area riservata se c’è, il carrello e il pagamento in un negozio, la pubblicazione di un contenuto dalla bacheca. Fare un passo alla volta rende ogni errore riconducibile a una sola causa.
Plugin e temi: cosa aggiornare e cosa no
Il core di WordPress raramente crea problemi: è testato su tutte le versioni di PHP supportate. Gli intoppi arrivano dai plugin e dal tema, e si dividono in pochi casi ricorrenti.
- Plugin mantenuti: si aggiornano seguendo la scala. Prima di un salto di versione principale conviene leggere il changelog, perché alcuni cambiano struttura dei dati o impostazioni al primo avvio.
- Plugin a pagamento con licenza scaduta: si rinnova la licenza o si scarica a mano l’ultima versione dall’area clienti del produttore. Sono tra i più indietro nei siti fermi da anni.
- Plugin abbandonati: vanno adattati, sostituiti o riscritti, una scelta che trattiamo nell’articolo sui plugin WordPress abbandonati.
- Plugin non usati: si rimuovono. Ogni plugin disattivato ma presente sul server è codice che un attaccante può raggiungere direttamente.
- Tema: se è stato modificato nei suoi file, l’aggiornamento cancella le modifiche. Prima vanno spostate in un tema figlio, come spieghiamo nell’articolo su child theme e personalizzazioni.
Gli errori tipici che compaiono nel log passando a PHP 8 sono pochi e riconoscibili: funzioni rimosse come create_function() ed each(), che causano un errore fatale; parametri di tipo sbagliato passati alle funzioni interne, che in PHP 8 sollevano un’eccezione; avvisi di deprecazione per null passato a funzioni come strlen() in PHP 8.1 e per le proprietà dinamiche in PHP 8.2. I primi due vanno corretti prima del rilascio, gli avvisi si annotano e si correggono con calma.
Il passaggio in produzione senza fermare il sito
Quando la copia di prova funziona sull’ultima versione di PHP e di WordPress, la produzione si aggiorna ripetendo la stessa sequenza già collaudata. Il modo più sicuro per farlo senza interruzioni visibili è preparare tutto in anticipo:
- installare sul server di produzione il nuovo PHP-FPM accanto a quello in uso, con la stessa configurazione e le stesse estensioni provate in test;
- fare una copia di sicurezza di database e file, e verificarla;
- attivare per pochi minuti la modalità manutenzione con
wp maintenance-mode activate, aggiornare core, plugin e tema alle versioni provate e lanciarewp core update-db; - cambiare nel server web il pool di PHP-FPM del sito, ricaricare la configurazione e disattivare la manutenzione;
- provare subito i percorsi critici e tenere d’occhio il log degli errori nelle ore successive.
Il ritorno indietro, se serve, è rapido: si rimette il pool di PHP-FPM precedente e, se l’aggiornamento del database lo richiede, si ripristina la copia fatta al punto 2. Su siti con ordini o registrazioni continue, ripristinare il database significa perdere i dati inseriti nel frattempo: per questo i test sulla copia vanno fatti bene e la finestra di rilascio va scelta in un momento di poco traffico.
Se la scala è troppo lunga
A volte il sito è così indietro, o così personalizzato, che la sequenza richiede settimane. In quel caso conviene separare due problemi: la sicurezza del server oggi e l’aggiornamento dell’applicazione nei tempi necessari. Sul primo si interviene con pacchetti PHP ancora mantenuti, se esistono per la versione in uso, oppure con il backport delle patch di sicurezza sul PHP installato, che non richiede di toccare WordPress. Sul secondo si procede con la scala, senza la pressione di un’urgenza.
Lo stesso ragionamento vale per gli altri CMS: lo descriviamo in generale nell’articolo su come migrare un CMS a PHP 8. Se preferisci affidarci la sequenza, partiamo dalla copia di prova e dall’inventario: scrivici indicando versione di WordPress, versione di PHP e sistema operativo.
Per concludere
Un WordPress resta indietro perché core e plugin alzano la versione minima di PHP e il sito non regge il PHP nuovo. Il blocco si scioglie con una scala: si aggiorna tutto ciò che gira sul PHP attuale, si sale di un gradino con PHP, poi di nuovo con WordPress e i plugin, fino a PHP 8.3 e alla versione corrente del core. Le soglie sono note, PHP 7.0 da WordPress 6.3, 7.2.24 dalla 6.6 e 7.4 dalla 7.0, e permettono di pianificare la sequenza in anticipo. Tutto si prova su una copia con il log degli errori attivo, e in produzione si installa il nuovo PHP-FPM accanto al vecchio, così il cambio richiede pochi minuti e il ritorno indietro ancora meno. Se il percorso è lungo, il backport delle patch protegge il server mentre l’aggiornamento procede.
