In breve: le vecchie versioni di PHP si disattivano nel modo più sicuro in tre fasi: rilevare l'uso, bloccare la versione e osservare, solo poi disinstallare. In Plesk un handler può dapprima essere disattivato, così che non possa più essere scelto, e in seguito rimosso in Aggiornamenti e componenti. Ogni versione rimossa è una in meno da aggiornare e riavviare alla prossima vulnerabilità come PHP2Shell.
Perché fare pulizia proprio ora?
La settimana dopo PHP2Shell ha mostrato a molti amministratori quante versioni di PHP siano installate sui loro server. Ognuna doveva essere verificata, ognuna richiedeva un aggiornamento o misure transitorie, ogni servizio un riavvio. Per PHP 8.1 e precedenti esistono solo backport minimi del sorgente, per PHP 8.2 il supporto termina il 31 dicembre 2026.
Con questa esperienza ancora fresca è il momento giusto per fare ordine. Come trovare tutte le installazioni lo descrive l'articolo Più versioni PHP su un server. Qui si tratta del passo successivo: la disattivazione controllata.
Fase 1: rilevare l'uso
Prima di disattivare qualcosa deve sapere chi usa una versione. I siti web sono la parte ovvia. Meno visibili sono sottodomini, installazioni di test, cron job, script e componenti del pannello.
In Plesk il comando plesk bin php_handler --list elenca tutti gli handler registrati. Con --get-usage, secondo la documentazione, Plesk mostra quali domini usano un determinato handler. Entrambi i comandi non modificano nulla.
# Plesk: tutti gli handler e i domini che usano un handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# In generale: cron job che richiamano una determinata versione di PHP
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Verifichi inoltre i log di accesso dei siti interessati: un'installazione di test che da mesi non riceve richieste è una candidata alla rimozione, non alla migrazione. Annoti per ogni vecchia versione chi la usa e perché.
Chieda anche alle persone che lavorano con i siti. Redazioni, agenzie e reparti conoscono spesso processi che non compaiono in nessun elenco: l'esportazione annuale per la contabilità, il modulo per una fiera, l'interfaccia con il gestionale. Ciò che dipende da una vecchia versione, altrimenti, si nota solo quando manca.
Fase 2: bloccare e osservare
Il passo intermedio impedisce che una versione venga riassegnata, senza cancellarla subito. In Plesk esiste la possibilità di disattivare singoli handler. Secondo la documentazione di Plesk, un handler disattivato non può più essere selezionato nelle impostazioni PHP di un sito; la versione resta installata. Dalla riga di comando si fa con plesk bin php_handler --disable -id <handler-id>.
I domini che usano ancora la vecchia versione li porti prima, d'intesa con i responsabili, a una versione supportata. Come ciò appaia dal punto di vista del gestore del sito lo descrive l'articolo Cambiare la versione di PHP nell'area clienti dell'hosting. La scelta dell'handler adatto la spiega l'articolo Plesk: capire gli handler PHP.
Durante il periodo di osservazione faccia attenzione a messaggi di errore nei log, risultati mancanti dei cron job e segnalazioni degli utenti. Negli altri pannelli le funzioni hanno nomi diversi; consulti lì la documentazione del produttore.
Fissi come scadenza la fine del periodo di osservazione e indichi chi, dopo, autorizza la disinstallazione. Altrimenti il passo intermedio diventa uno stato permanente e la vecchia versione resta comunque sul server.
Fase 3: disinstallare
Solo quando il periodo di osservazione è trascorso senza anomalie rimuova completamente la versione. In Plesk, secondo la documentazione, ciò avviene in Tools & Settings, Updates, Add/Remove Components, nella sezione Web hosting presso le versioni dell'interprete PHP. Le versioni installate vi sono contrassegnate e si possono selezionare per la rimozione.
Sui server senza pannello se ne occupa la gestione dei pacchetti. Prima faccia un backup della configurazione della versione, ad esempio /etc/php/7.4/ su Debian e Ubuntu, per poter ricostruire in caso di emergenza quali impostazioni valessero.
# Salvare la configurazione, poi rimuovere i pacchetti di un ramo (esempio Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
Dopo la rimozione vale la pena fare un controllo. In Plesk la documentazione raccomanda plesk bin php_handler --reread per rileggere le informazioni sugli handler dopo modifiche ai binari PHP. Verifichi inoltre se i piani di servizio rimandano ancora alla versione rimossa.
Ostacoli tipici
| Ostacolo | Come lo riconosce | Cosa aiuta |
|---|---|---|
| Un componente del pannello dipende dalla versione | Il pannello segnala una dipendenza durante la rimozione | Prima adattare il componente oppure mantenere la versione |
| Il piano di servizio rimanda alla vecchia versione | I nuovi siti ricevono la vecchia versione o un messaggio di errore | Adattare il piano, poi rimuovere la versione |
| Un cron job richiama un percorso fisso | Lo script fallisce dopo la rimozione | Cambiare il percorso su una versione supportata |
| L'applicazione non gira sulla nuova versione | Errore dopo il passaggio nel log degli errori | Aggiornare o migrare l'applicazione |
Se un'applicazione non può essere portata a una versione supportata, disattivare la vecchia versione non è più una questione di configurazione, ma un progetto di migrazione. I rischi dei rami obsoleti li descrive la guida PHP end of life: i rischi delle versioni obsolete.
Il prossimo candidato è già deciso
Fare pulizia non è un'azione una tantum. Già il 31 dicembre 2026 PHP 8.2 esce dal supporto del progetto PHP. Chi ora rimuove le versioni fino alla 8.1 dovrebbe stabilire contestualmente come proseguire con la 8.2. Altrimenti lo stesso gioco ricomincia nel giro di poche settimane.
Per il server si è rivelata valida una regola semplice: vengono offerti solo i rami supportati dal progetto PHP. Ogni ramo riceve, al momento della configurazione, una data in cui verrà nuovamente verificato, orientata alla fine del supporto su php.net. Il contesto di questo ciclo lo spiega la pagina Versioni di PHP e ciclo di rilascio.
Chi come hoster o agenzia ha clienti sul server dovrebbe informarli per tempo. Un annuncio con una data, la richiesta di passare a una versione supportata e un'offerta di assistenza evitano che alla scadenza dei siti smettano di funzionare. I clienti la cui applicazione non tiene il passo riconoscono così in tempo che è in arrivo un aggiornamento o una migrazione e possono pianificarla.
Come aiuta concretamente PHP SOS?
- Rileviamo quali siti, cron job e componenti del pannello usano quale versione di PHP.
- Portiamo i domini, d'intesa con Lei, a versioni supportate e blocchiamo i vecchi handler.
- Dopo il periodo di osservazione rimuoviamo le vecchie versioni in modo controllato e verifichiamo il risultato.
- Dove le applicazioni non tengono il passo, pianifichiamo la migrazione da PHP 8.1 e precedenti.
Domande frequenti
Perché dovrei rimuovere le versioni di PHP inutilizzate?
Ogni versione installata deve essere verificata, aggiornata e riavviata a ogni vulnerabilità. I rami vecchi come PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP. Le versioni inutilizzate portano solo rischio e lavoro.
Qual è la differenza tra disattivare e disinstallare?
Disattivando, la versione resta installata ma non può più essere selezionata di nuovo. Disinstallando, viene rimossa dal server. Disattivare è il passo intermedio sicuro per vedere se qualcosa manca.
La rimozione di una versione di PHP può disturbare le funzioni del pannello?
Sì. Alcuni componenti di un pannello, ad esempio la webmail o gli strumenti di amministrazione, dipendono da una determinata versione di PHP. Chiarisca queste dipendenze prima della rimozione; di norma il pannello le segnala.
Quanto dovrebbe durare il periodo di osservazione?
Abbastanza da far girare almeno una volta tutti i processi regolari, quindi anche i cron job mensili e le esportazioni. Stabilisca la durata con i reparti interessati.