La richiesta arriva quasi sempre nella stessa forma: “dobbiamo passare a PHP 8, ci serve solo cambiare la versione sul server”. Il sito è un WordPress, un PrestaShop o un Joomla installato anni fa, con un tema acquistato, una ventina di estensioni e qualche modifica fatta da un fornitore che non c’è più. Sul server di prova si seleziona PHP 8.3, si apre la home e compare una pagina bianca, oppure un errore fatale in un file di un plugin che nessuno ricordava di avere.
In questo articolo spieghiamo perché migrare un CMS a PHP 8 significa quasi sempre aggiornare tutto lo stack, dal core alle estensioni al tema, quali sono oggi i requisiti dei CMS più diffusi, in che ordine conviene procedere e come stimare il lavoro prima di cominciare. Chiudiamo con il modo di proteggere la produzione mentre la migrazione è in corso.
Lo stack di un CMS, strato per strato
Un sito costruito su un CMS è una pila di componenti che dipendono l’uno dall’altro. Alla base ci sono il sistema operativo, il server web e l’interprete PHP con le sue estensioni. Sopra c’è il core del CMS, che dichiara quali versioni di PHP supporta. Sopra ancora ci sono le estensioni (plugin, moduli, componenti), il tema con i suoi template e, in cima, il codice scritto su misura: un modulo per il gestionale, un override di un template, una funzione aggiunta al tema.
Ogni strato dichiara, in modo esplicito o implicito, i requisiti di quello sottostante. Il core di WordPress indica la versione minima di PHP, un plugin indica nel suo file principale la versione minima di WordPress e di PHP, un tema per WooCommerce contiene copie dei template del negozio legate a una specifica versione. Quando si cambia il primo strato, l’effetto risale fino all’ultimo.
Perché non basta cambiare la versione di PHP
Tra PHP 5.6 o 7.x e PHP 8.x ci sono rimozioni di funzioni, comportamenti più rigidi e nuovi avvisi. Il codice che le ignora smette di funzionare o riempie i log di errori. Le differenze che incontriamo più spesso nei CMS sono queste:
- funzioni rimosse: le estensioni
mysql_*ederegsono state eliminate in PHP 7.0;create_function(),each()emoney_format()in PHP 8.0. Un plugin che le usa genera un errore fatale al primo caricamento; - errori più severi: in PHP 8.0 molte situazioni che prima producevano un semplice avviso sollevano un’eccezione, per esempio passare un tipo sbagliato a una funzione interna o fare operazioni aritmetiche su un array;
- confronti diversi: dalla 8.0 il confronto tra una stringa non numerica e un numero segue regole nuove, e un controllo come
0 == "abc"cambia risultato; - deprecazioni a catena: PHP 8.1 segnala il passaggio di
nulla parametri delle funzioni interne che non lo accettano, PHP 8.2 le proprietà dinamiche create al volo sugli oggetti. Non bloccano il sito, ma annunciano errori nelle versioni successive e rendono illeggibili i log.
Il core dei CMS principali è stato adeguato da tempo, a condizione di usarne una versione recente. Il problema sta quasi sempre negli strati superiori: un’estensione ferma da anni, un tema mai aggiornato, un modulo scritto per una versione del CMS che oggi non installa nemmeno su PHP 8. Per questo cambiare solo l’interprete non funziona, e aggiornare solo il core nemmeno: le estensioni compatibili con PHP 8 di solito richiedono anche una versione recente del CMS.
I requisiti dei CMS più diffusi
La tabella riassume i requisiti di PHP pubblicati dai progetti a novembre 2026. Per WordPress fanno fede la pagina dei requisiti e il chiarimento sul supporto di PHP pubblicato su Make WordPress a maggio 2026; per PrestaShop la pagina dei requisiti di sistema della documentazione per sviluppatori.
| CMS e versione | PHP supportato | PHP raccomandato |
|---|---|---|
| WordPress 7.0 | dalla 7.4 | 8.3 o superiore |
| WooCommerce (versioni correnti) | dalla 7.4, solo in ambienti legacy | 8.3 o superiore |
| PrestaShop 1.6.1.x | dalla 5.2 alla 7.1 | 7.1 |
| PrestaShop 1.7.8 | dalla 7.1 alla 7.4 | 7.4 |
| PrestaShop 8.0 – 8.2 | dalla 7.2 alla 8.1 | 8.1 |
| PrestaShop 9.0 | dalla 8.1 alla 8.4 | versioni recenti |
| Joomla 5 | dalla 8.1 | versioni recenti |
| Drupal 11 | dalla 8.3 | versioni recenti |
Due osservazioni. La prima: per alcuni CMS il passaggio a PHP 8 coincide con un cambio di versione principale del CMS stesso. Un PrestaShop 1.6 non gira su PHP 8 in nessuna configurazione supportata, e la strada passa da PrestaShop 8 o 9, come spieghiamo nell’articolo su come migrare da PrestaShop 1.6 a PrestaShop 8. La seconda: la versione minima è una soglia sotto la quale il core non si aggiorna più, e da sola non garantisce un sito sicuro. WordPress 7.0 si installa su PHP 7.4, ma PHP 7.4 è fuori supporto dalla fine del 2022.
L’ordine giusto degli aggiornamenti
Quando lo stack è molto indietro, gli strati vanno aggiornati in un ordine che mantenga il sito funzionante a ogni passo. Lo schema che seguiamo, sempre in un ambiente di prova, è questo:
- Inventario. Versione del CMS, elenco delle estensioni attive con versione e data dell’ultimo aggiornamento, tema e tema figlio, modifiche al core, operazioni pianificate, integrazioni esterne.
- Copia completa in prova. Database, file e configurazione, sulla stessa versione di PHP della produzione, per avere un punto di partenza che funziona.
- Aggiornamenti compatibili con il PHP attuale. Estensioni e tema all’ultima versione che supporta ancora l’interprete in uso, poi il core fino alla versione più alta installabile.
- Cambio della versione di PHP, con il log degli errori attivo e i percorsi principali del sito provati uno per uno.
- Ultimo giro di aggiornamenti: core ed estensioni alle versioni correnti, che richiedono il PHP nuovo.
- Correzione o sostituzione di ciò che resta incompatibile: estensioni abbandonate, template personalizzati, codice su misura.
- Test e rilascio in produzione, con una copia di sicurezza e un piano per tornare indietro.
Il passo 3 è quello che fa risparmiare più tempo. Molti problemi di compatibilità con PHP 8 sono già risolti nelle versioni recenti delle estensioni, e aggiornarle prima di cambiare interprete riduce l’elenco degli errori a ciò che richiede davvero un intervento sul codice. Per WordPress descriviamo la sequenza nel dettaglio nell’articolo su come aggiornare WordPress su un PHP vecchio senza fermare il sito.
Trovare le incompatibilità prima che le trovino i clienti
Provare il sito a mano trova gli errori sulle pagine che si visitano, e lascia scoperti i percorsi rari: il pagamento con un metodo poco usato, un’esportazione mensile, un’operazione pianificata. Prima dei test manuali conviene un controllo automatico su tutto il codice delle estensioni e del tema, con l’interprete di destinazione e con un analizzatore statico come PHPCompatibility.
# Controllo della sintassi con l’interprete di destinazione (qui PHP 8.3)
# su tutti i file di estensioni e tema; mostra solo i file con errori
find wp-content/plugins wp-content/themes -name '*.php' -print0 \
| xargs -0 -n1 -P4 php8.3 -l 2>&1 | grep -v '^No syntax errors'
# Analisi statica con PHPCompatibility, in una cartella di lavoro separata
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/php-compatibility:"^10.0@dev"
vendor/bin/phpcs -p --standard=PHPCompatibility --runtime-set testVersion 8.3 \
--extensions=php /percorso/del/sito/wp-content/pluginsIl controllo della sintassi trova solo gli errori di analisi, per esempio le parentesi graffe usate per accedere ai caratteri di una stringa, rimosse in PHP 8.0. L’analisi statica trova anche le funzioni rimosse e i costrutti deprecati. Per WordPress esiste il set di regole PHPCompatibilityWP, che esclude le funzioni che il core fornisce già in sostituzione. Nessuno dei due strumenti vede i problemi che dipendono dai dati, come un null che arriva da un campo vuoto del database: per quelli servono il log degli errori e i test dei percorsi critici.
Come stimare il lavoro
Due siti con lo stesso CMS e la stessa versione di PHP possono richiedere tempi molto diversi. Quello che sposta la stima è la distanza tra lo stato attuale e quello di destinazione, misurata su alcuni punti precisi:
- quante versioni principali del CMS separano l’installazione da quella corrente, e se il salto richiede passaggi intermedi obbligati;
- quante estensioni sono ancora mantenute e quante vanno adattate, sostituite o riscritte, un tema che affrontiamo nell’articolo sui plugin abbandonati;
- quanto è personalizzato il tema, se esiste un tema figlio o se le modifiche sono state fatte direttamente nei file del tema principale;
- quanto codice su misura c’è e se qualcuno ne conosce ancora il funzionamento;
- quali integrazioni scambiano dati con il sito: gestionale, magazzino, corrieri, pagamenti, fatturazione;
- se il sistema operativo va cambiato anch’esso per avere un PHP 8 mantenuto dalla distribuzione.
Le prime voci si misurano in un giorno di analisi, con l’inventario e i controlli automatici del paragrafo precedente. Il risultato è un elenco di interventi con una priorità e una stima per ciascuno, che permette di decidere se migrare tutto in una volta o in più fasi, e cosa sostituire invece di correggere.
Il tema e le personalizzazioni
Il tema merita un capitolo a parte, perché è lo strato in cui si concentrano le modifiche fatte negli anni. Se le personalizzazioni sono in un tema figlio o in un modulo dedicato, si possono rileggere e adattare una per una. Se invece sono state scritte nei file del tema principale, il primo aggiornamento le cancella, e la migrazione inizia con un lavoro di confronto tra i file modificati e quelli originali per ricostruire cosa è stato cambiato.
Lo stesso vale per i template sovrascritti dalle estensioni di e-commerce, come i file della cartella woocommerce dentro un tema WordPress o i template Smarty di PrestaShop. Ogni override è una copia di un file originale a una certa versione: quando l’estensione cambia, la copia resta indietro e va riallineata. Nei passaggi di versione principale, come da PrestaShop 1.6 alla 1.7 e successive, il sistema dei temi è cambiato e il tema va rifatto o sostituito.
Proteggere la produzione mentre si migra
Una migrazione completa richiede settimane, a volte mesi quando il salto è grande o le integrazioni sono molte. Nel frattempo il sito resta in produzione sulla versione di PHP attuale, che spesso è già fuori supporto. Le opzioni per quel periodo sono le stesse che valgono per qualsiasi applicazione PHP legacy:
- usare pacchetti PHP ancora mantenuti dalla distribuzione o da un fornitore, se esistono per la versione in uso;
- applicare il backport delle patch di sicurezza al PHP installato, ricostruendo i pacchetti RPM o DEB in uso, senza toccare il CMS;
- ridurre l’esposizione: accesso limitato all’area amministrativa, estensioni non usate disattivate, un firewall applicativo davanti al sito.
Il backport non rende la versione supportata e non sostituisce la migrazione: serve a tenere chiuse le vulnerabilità note mentre il lavoro sullo stack procede senza fretta. Ne parliamo nell’articolo su quando scegliere il backport e quando la migrazione. Se vuoi impostare il percorso per il tuo sito, partiamo dall’inventario: trovi come lavoriamo nella sezione sulla migrazione applicativa.
Riassumendo
Un CMS è una pila di componenti che dipendono l’uno dall’altro, e cambiare la versione di PHP alla base si propaga fino al tema e al codice su misura. Le funzioni rimosse in PHP 7.0 e 8.0 e i comportamenti più rigidi di PHP 8 colpiscono soprattutto estensioni e template rimasti indietro, mentre il core dei CMS principali è pronto da tempo nelle versioni recenti. L’ordine che funziona è inventario, copia in prova, aggiornamenti compatibili con il PHP attuale, cambio di interprete, aggiornamenti finali, correzioni e rilascio con un piano di rollback. Controlli automatici e log degli errori trovano le incompatibilità prima dei clienti, la stima si basa sulla distanza reale dello stack dalla versione corrente, e durante il lavoro la produzione si protegge con pacchetti mantenuti, backport delle patch e mitigazioni.
