Se gestisci un sito WordPress, prima o poi ti arriva l'email dell'hosting: "il tuo sito sta girando su una versione PHP in fine vita, aggiorna". La maggior parte delle persone la archivia. Io la leggo con attenzione, perché dietro quella frase standard ci sono due cose concrete: patch di sicurezza che smettono di arrivare, e prestazioni che restano sul tavolo. E con PHP 8.5 — uscito il 20 novembre 2025 e già raccomandato dalla maggior parte degli hosting gestiti nel 2026 — il tema è più caldo che mai.
Un articolo di Seravo pubblicato nelle scorse settimane — PHP 8.5 and WordPress: When to Upgrade? — riassume bene lo stato dell'arte: WordPress 6.9 supporta PHP 8.5, ma con status ancora "beta" per gli sviluppatori del core, mentre gli hosting stanno spingendo la versione in produzione. In questa guida traduco quell'equilibrio in una procedura pratica, quella che uso ogni volta che porto un sito cliente su una nuova versione di PHP: cosa porta davvero 8.5, cosa si rompe, e in che ordine fare le cose per non ritrovarsi un white screen di venerdì sera.
Contenuto articolo
- Cosa porta davvero PHP 8.5 (e perché ci interessa)
- Dov'è WordPress rispetto a PHP 8.5
- Il vero motivo per non rimandare: la fine del supporto
- Cosa si rompe davvero in un upgrade (esperienza diretta)
- La procedura in 6 step che uso sui siti che gestisco
- Vale la pena farlo da soli?
- E la performance? I numeri onesti
- Cosa fare adesso, in pratica
- Riferimenti utili
Cosa porta davvero PHP 8.5 (e perché ci interessa)
Alcune novità di PHP 8.5 sembrano da manuale accademico, ma almeno quattro hanno un impatto diretto sul codice WordPress che si scrive ogni giorno. Le passo in rassegna senza cerimonie.
Il pipe operator (|>) permette di incatenare funzioni da sinistra a destra senza variabili d'appoggio: dove prima scrivevi tre righe con variabili intermedie, ora scrivi $titolo |> trim(...) |> mb_strtolower(...). Leggibilità reale, non estetica.
L'estensione URI nativa — conforme a RFC 3986 e WHATWG — mette fine all'abitudine di parsare URL con regex fatte in casa. Per chi sviluppa plugin che parlano con API esterne, è un regalo.
La sintassi clone with (clone $obj with ['prop' => 'valore']) semplifica la duplicazione di oggetti readonly, pattern sempre più comune nel codice moderno. E le nuove funzioni WPGUTENBERGBLOCKPLACEHOLDER1X e WPGUTENBERGBLOCKPLACEHOLDER2X eliminano l'oscura $array[array_key_first($array)] che tutti abbiamo scritto mille volte.
Due novità poi riguardano la qualità della vita in produzione: le Persistent cURL Share Handles riducono l'overhead di inizializzazione delle connessioni cURL tra richieste — utile per chi fa molte chiamate esterne, tema di cui ho scritto di recente — e i fatal error ora includono lo stack trace completo, cosa che accorcia sensibilmente il tempo di debug. Chi ha mai visto un "Allowed memory size exhausted" senza indizi sa quanto vale questa cosa.
Dov'è WordPress rispetto a PHP 8.5
La posizione ufficiale è documentata nel post di Make WordPress Core sul supporto di PHP 8.5 in WordPress 6.9: il core viene testato su 8.5 e il supporto viene esteso a ogni nuova versione PHP, ma la baseline di compatibilità resta PHP 7.2.24 e superiori. In pratica: WordPress funziona su 8.5, ma non te lo impone.
Gli hosting gestiti fanno la parte opposta: spingono. Seravo l'ha resa disponibile da gennaio 2026 per i test in staging, e la maggior parte dei provider gestiti del 2026 la segnala come versione raccomandata per nuovi siti. Il risultato è una situazione di transizione tipica: il core supporta, gli host raccomandano, ma i plugin e i temi vivono su tempi propri. Ed è proprio il terreno dove nascono i problemi.
Il vero motivo per non rimandare: la fine del supporto
La performance è l'argomento di marketing; la sicurezza è quello che conta. PHP 8.1 non riceve patch di sicurezza dal 31 dicembre 2025, e PHP 8.2 chiude il suo ciclo il 31 dicembre 2026: siamo letteralmente negli ultimi mesi di copertura. Ogni giorno su una versione EOL è un giorno in cui una vulnerabilità scoperta nel linguaggio resta senza fix ufficiali.
PHP 8.5, come tutte le versioni 8.x, segue il ciclo standard del progetto: due anni di supporto attivo — per 8.5 fino al 31 dicembre 2027 — seguiti da due anni di sole patch di sicurezza. Aggiornare oggi significa comprare tranquillità fino al 2029, e se sei ancora su 8.1 o 8.2, significa uscire da una finestra che si sta chiudendo.
Una nota di onestà: l'update a PHP 8.5 non trasforma un sito lento in un razzo. I guadagni reali rispetto a 8.3 esistono ma sono modesti; la differenza la fa ancora l'architettura di cache. Se il tuo obiettivo è la velocità, partiamo dal diagnosi delle cause di lentezza, non dalla versione del linguaggio.
Cosa si rompe davvero in un upgrade (esperienza diretta)
Dopo aver migrato decine di siti tra versioni 8.x, i problemi si riducono a tre famiglie. Prima fra tutte: deprecation warning su funzioni e pattern dismessi — non rompono nulla a schermo, ma riempiono i log e, se la visualizzazione errori è attiva in produzione, arrivano in pagina. Seconda: proprietà dinamiche, vietate da PHP 8.2: i plugin vecchi che appiccicano proprietà a oggetti al volo su 8.5 vanno dritti in fatal error. Terza: vecchi temi commerciali mai aggiornati, che si trascinano codice del 2019.
Il caso più fastidioso che mi è capitato quest'anno: un plugin per form aggiornato due anni fa che su 8.4 generava warning su una funzione deprecated dentro una libreria vendor — nulla di visibile, ma 40.000 righe di log al mese che seppellivano gli errori veri. La regola è sempre quella: su 8.5, i problemi non vengono quasi mai da WordPress, vengono da plugin e temi. E su un sito che porta anni di plugin non manutenuti, l'audit preventivo non è optional: è il primo intervento che eseguo quando prendo in carico un sito con l'assistenza WordPress.
La procedura in 6 step che uso sui siti che gestisco
Questa è la sequenza completa, lo stesso copione ogni volta. L'ordine non è negoziabile: aggiornare il PHP prima dei plugin è il modo più rapido per farsi male.
1. Backup completo e verificato
File e database, con prova di ripristino. Un backup mai testato è un documento di fantascienza. Se non sai da dove partire, è esattamente il primo step del mio protocollo di ripristino post-hack e gestione backup.
2. Clona il sito in staging
Nessun upgrade PHP si fa in produzione, mai. Su hosting gestiti esiste quasi sempre un ambiente di staging con un click; su altri si clona in una sottocartella o in un sottodominio. Lo staging deve essere una copia reale: stessi plugin, stessi dati, stesso PHP configurabile. Se il tuo hosting non offre staging con un click, chiedi al supporto o valuta con chi ti fa l'assistenza WordPress un ambiente di test dedicato: migrare senza rete di protezione non è un upgrade, è un salto nel buio.
3. Audit di compatibilità del codice
Con PHPCompatibilityWP si scansiona il codice di plugin e temi custom alla ricerca di costrutti incompatibili con 8.5, prima ancora di toccare nulla:
composer require --dev phpcompatibility/phpcompatibility-wp
phpcs -p --standard=PHPCompatibilityWP --runtime-set testVersion 8.5 wp-content/plugins/Per chi non ha ambienti di sviluppo locali, l'alternativa è WP-CLI su staging:
wp plugin list --fields=name,version,update
wp core versionPlugin molto vecchi o mai aggiornati vanno mappati come rischio a parte: su ogni sito trovo almeno uno di questi.
4. Aggiorna plugin e temi PRIMA del PHP
Controintuitivo ma fondamentale: il sito deve essere già tutto all'ultima versione sulla vecchia PHP, così il cambio di versione test-only diventa una variabile sola. Aggiornare PHP e dieci plugin insieme significa non sapere più chi ha rotto cosa.
5. Cambia versione e testa in modo sistematico
Switch a PHP 8.5 in staging, poi test funzionali: form, checkout, login, registrazione, ricerca, upload media, i flussi critici del tuo sito. Io uso una checklist di test per categoria sito — un e-commerce si testa in modo diverso da un magazine. E si guardano i log: warning e deprecation vanno elisi prima del passaggio in produzione, non dopo.
6. Rollback pronto e passaggio in produzione
Il passaggio finale si fa in una finestra a basso traffico, con la versione precedente a un click di distanza. Se qualcosa va storto, si torna indietro in due minuti e si indaga in staging con calma: è questo il vantaggio di aver fatto le cose in ordine.
Vale la pena farlo da soli?
Dipende. Se il tuo sito è semplice, hai staging e un po' di familiarità con WP-CLI, la procedura è fattibile in una serata. Se il sito ha plugin custom, un tema figlio con codice vecchio o un e-commerce attivo, il costo di un errore supera di gran lunga quello di farla fare: la mia assistenza WordPress esegue questi upgrade con procedura completa — audit, staging, test, finestra notturna — e la mia opinione onesta è che per i siti di produzione con fatturato dietro, il fai-da-te sia un risparmio apparente.
Per gli sviluppatori che invece gestiscono portafogli clienti, l'audit di compatibilità si automatizza in pipeline: ne parlo nella guida sui tool AI per il workflow dello sviluppatore WordPress. E la compatibilità incrociata con le nuove versioni di WordPress — il tema si applica anche ai temi, non solo ai plugin — è coperta in dettaglio nella guida alle novità di WordPress 7.1 per compatibilità plugin e temi.
E la performance? I numeri onesti
Parliamoci chiaro, perché su questo giro più di un marketing di hosting è ottimista: il passaggio da 8.3 a 8.5 porta guadagni modesti, spesso sotto il 5% e difficili da misurare su un sito con cache ben configurata. La storia cambia se arrivi da lontano: la migrazione di un sito da PHP 7.4 a 8.5 che ho seguito a giugno ha portato il TTFB da 640 a 470 millisecondi medi, senza toccare nulla se non la versione — un 27% che il cliente ha notato senza che glielo dicessi io.
Il motivo è semplice: gran parte del guadagno delle 8.x viene da OPcache e da una gestione della memoria molto più efficiente, e chi è fermo su 7.x/8.0/8.1 lascia sul tavolo anni di ottimizzazioni. Per chi è già su 8.3, invece, la ragione vera dell'update è la sicurezza, non la velocità — e va venduta così, senza numeri magici.
Se vuoi misurare da solo: baseline prima (TTFB e P95 con k6 o ab), switch in staging, stessa misura dopo, stesso carico. Cinque minuti di test dicono più di dieci articoli di benchmark terzi.
Cosa fare adesso, in pratica
Tre azioni immediate, in ordine di priorità. Prima: verifica su che versione PHP gira il tuo sito oggi — il pannello dell'hosting o php -v via WP-CLI la dicono subito. Seconda: se sei su 8.1 (EOL) o 8.2 (ultimi mesi di supporto), metti l'upgrade nel calendario entro fine anno, non "prima o poi". Terza: segui i sei step sopra, senza scorciatoie — e se il sito è di produzione con fatturato dietro, prenota la finestra con chi lo sa fare: l'assistenza WordPress per questi upgrade prevede audit, staging, test funzionali e rollback, così l'unica cosa che cambia è la versione, non la tua serenità.
Lascia un commento