C’è una categoria di aggiornamenti che tendiamo a rimandare perché tutto, apparentemente, funziona. Il sito risponde, WordPress non protesta, WooCommerce continua a vendere e nessuno ha ancora aperto un ticket con oggetto “URGENTE!!!” scritto rigorosamente in maiuscolo.
PHP 8.2 potrebbe rientrare esattamente in questa categoria.
Il 31 dicembre 2026 PHP 8.2 raggiungerà l’End of Life, cioè la fine del periodo di supporto ufficiale. Non significa che allo scoccare della mezzanotte milioni di server inizieranno a emettere fumo né che WordPress presenterà improvvisamente una schermata con scritto Game Over. Significa qualcosa di molto meno spettacolare e, proprio per questo, più importante: PHP 8.2 non riceverà più gli aggiornamenti di sicurezza previsti dal suo ciclo ufficiale.
Per developer, webmaster e soprattutto agenzie che gestiscono decine di installazioni WordPress, settembre è quindi un momento decisamente migliore di dicembre per iniziare a occuparsene.
Cosa succede a PHP 8.2 dopo il 31 dicembre 2026?
PHP utilizza un ciclo di supporto abbastanza prevedibile: ogni release principale attraversa una fase di supporto attivo, una fase dedicata alle correzioni di sicurezza e infine raggiunge l’End of Life (EOL). Per PHP 8.2 quest’ultimo passaggio arriverà il 31 dicembre 2026.
La distinzione fondamentale è tra software funzionante e software supportato.
Un’applicazione basata su PHP 8.2 potrebbe continuare a funzionare perfettamente anche nel 2027. Il problema è che, una volta terminato il supporto ufficiale, eventuali nuove vulnerabilità individuate nella versione non rientreranno più nel normale ciclo di correzione del progetto PHP.
In altre parole, il server potrebbe continuare tranquillamente a dire 200 OK mentre il developer dovrebbe iniziare a sentirsi un po’ meno OK.
Ed è proprio per questo che non conviene aspettare l’ultimo momento.
Quale versione PHP usare con WordPress nel 2026?
Qui arriva la domanda che probabilmente porterà parecchie persone su Google nei prossimi mesi: “A quale versione PHP devo aggiornare WordPress?”
La tentazione naturale del developer è scegliere semplicemente il numero più alto disponibile. Se esiste PHP 8.5, allora PHP 8.5 deve necessariamente essere meglio di PHP 8.4.
Matematicamente ineccepibile.
Sistemisticamente, un po’ meno.
La versione PHP corretta non è semplicemente l’ultima disponibile, ma la versione più recente compatibile e stabile con l’intero stack applicativo.
E in un progetto WordPress lo stack non è soltanto WordPress. È qualcosa di più simile a:
- PHP + WordPress + tema + plugin + WooCommerce + codice custom + API + database + hosting
Basta che uno degli elementi decida di vivere ancora felicemente nel 2021 e l’upgrade può diventare interessante.
WordPress raccomanda oggi PHP 8.3 o superiore, mentre le release più recenti hanno progressivamente esteso la piena compatibilità alle nuove generazioni PHP. Prima di cambiare versione è comunque opportuno verificare la matrice di compatibilità della specifica versione WordPress utilizzata e, soprattutto, dei componenti installati.
Perché “supportato da WordPress” non significa automaticamente “supportato dai 37 plugin installati sul WordPress del cliente”.
PHP 8.2 funziona ancora? Sì. Ed è proprio questo il problema
Quando una tecnologia arriva vicino all’End of Life nasce un piccolo paradosso: se qualcosa smettesse immediatamente di funzionare, tutti la aggiornerebbero.
Invece continua a funzionare.
E quindi viene rimandata.
Il sito risponde velocemente, il backend si apre, il checkout funziona e PHP 8.2 continua serenamente a elaborare richieste. L’EOL non è infatti una data di spegnimento, ma una data di cessazione del supporto ufficiale.
Per questo settembre 2026 è il momento giusto per controllare il proprio stack. Non perché PHP 8.2 sia improvvisamente diventato inutilizzabile, ma perché ci sono ancora tre mesi per pianificare l’aggiornamento senza trasformarlo nell’ennesima emergenza di fine anno.
Aggiornare PHP può rompere WordPress?
Sì. Ma sarebbe più corretto dire che cambiare PHP può far emergere incompatibilità già presenti nel progetto.
Un WordPress aggiornato, con tema recente e plugin mantenuti attivamente, generalmente rende la migrazione molto più semplice. I problemi iniziano quando sotto la carrozzeria troviamo plugin abbandonati, funzioni deprecate, vecchie librerie, snippet aggiunti anni prima in functions.php oppure quel plugin custom chiamato plugin-definitivo-FINAL-v3.php che nessuno osa più aprire.
Per questo cambiare PHP direttamente in produzione per vedere cosa succede non è propriamente una metodologia DevOps.
È più vicino a un esperimento sociale.
La procedura sensata rimane quella classica: controllare lo stato dell’installazione, aggiornare WordPress e i componenti compatibili, effettuare un backup completo di file e database, testare la nuova versione PHP possibilmente in staging e soltanto dopo portare la configurazione in produzione.
Particolare attenzione va riservata a WooCommerce e alle applicazioni business critical. Non basta aprire la homepage e constatare soddisfatti che il logo è ancora lì. Bisogna verificare autenticazione, form, ricerca, carrello, checkout, gateway di pagamento, email transazionali, API e integrazioni esterne.
E poi guardare i log.
Sempre i log.
Perché il frontend può sorridere mentre error_log sta scrivendo un romanzo russo.
Come controllare quale versione PHP utilizza WordPress
La verifica è semplice. Dal backend WordPress è possibile andare in Strumenti → Salute del sito → Informazioni → Server e controllare la versione PHP utilizzata dall’installazione.
Se trovi PHP 8.2, non significa che il sito sia improvvisamente in pericolo. Significa semplicemente che hai una deadline tecnica da inserire nel calendario.
Se trovi una versione ancora precedente, invece, potrebbe essere il momento di allontanare lentamente la tazza di caffè dalla tastiera e approfondire la situazione.
Per un’agenzia questo controllo può diventare un piccolo PHP audit dell’intero portfolio clienti. I siti possono essere classificati rapidamente tra quelli aggiornabili, quelli da testare, quelli con dipendenze da verificare e i gloriosi progetti legacy nei quali anche modificare il footer richiede un backup, due sviluppatori senior e probabilmente un sacerdote.
PHP 8.4 su Tophost: la versione si gestisce dal pannello
La possibilità di scegliere la versione PHP lato hosting diventa naturalmente una parte importante del processo.
Tophost gestisce attualmente sui propri server versioni PHP fino alla 8.4 per tutti i piani hosting. Dal pannello di controllo è possibile selezionare la versione PHP disponibile per il proprio spazio web, come mostrato anche nell’interfaccia dei pannelli Topweb e Topweb Plus.
Questo significa che il passaggio da una versione PHP precedente alla 8.4 può essere gestito direttamente a livello di configurazione hosting, fermo restando il punto più importante di tutta questa storia: prima si verifica la compatibilità dell’applicazione, poi si cambia versione.
L’hosting può metterti a disposizione il runtime aggiornato. Non può convincere un plugin scritto dodici anni fa che è arrivato il momento di accettare il futuro.
Ed è una distinzione piuttosto importante.
PHP 8.3 o PHP 8.4: cosa scegliere?
Se l’infrastruttura permette entrambe le versioni, non sceglierei automaticamente sulla base del numero.
Per un nuovo progetto si può ragionare sulla versione più recente compatibile con lo stack scelto. Per un sito esistente, invece, è preferibile partire da un audit delle dipendenze.
PHP 8.4 offre un ciclo di supporto più lungo rispetto alle versioni precedenti e rappresenta quindi una destinazione interessante per i progetti compatibili. Ma l’upgrade deve essere considerato come un intervento sull’intero stack e non come una semplice impostazione da cambiare nel pannello.
La domanda corretta, quindi, non è:
“Qual è il PHP più nuovo?”
È:
“Qual è la versione PHP più recente che posso utilizzare stabilmente con il mio progetto?”
Sembra una sfumatura semantica.
Può essere la differenza tra andare a cena e passare la serata dentro wp_debug.log.
Perché le web agency dovrebbero controllare PHP adesso
Per chi gestisce un singolo sito, tre mesi sono parecchio tempo. Per un’agenzia che gestisce cinquanta o cento installazioni, improvvisamente non lo sono più.
Il vero lavoro non consiste nel cambiare un selettore da 8.2 a 8.4, ma nell’individuare quali progetti possono essere aggiornati immediatamente e quali richiedono interventi preliminari.
Settembre e ottobre sono quindi mesi ideali per censire le installazioni, verificare le versioni PHP, individuare plugin obsoleti e pianificare progressivamente le migrazioni.
È anche una buona occasione per eliminare un po’ di technical debt accumulato.
Perché il debito tecnico ha una caratteristica curiosa: non manda solleciti di pagamento.
Aspetta semplicemente il venerdì alle 17:43.
FAQ: PHP 8.2, WordPress e aggiornamento
- Quando termina il supporto di PHP 8.2? Il supporto di sicurezza ufficiale di PHP 8.2 terminerà il 31 dicembre 2026. Dopo questa data PHP 8.2 sarà considerato End of Life.
- PHP 8.2 smetterà di funzionare nel 2027? No. Un server può continuare tecnicamente a eseguire PHP 8.2, ma la versione non riceverà più il normale supporto ufficiale di sicurezza del progetto PHP.
- Posso passare direttamente da PHP 8.2 a PHP 8.4? È possibile quando WordPress, tema, plugin, librerie e codice personalizzato risultano compatibili con PHP 8.4. È consigliabile effettuare backup e test prima di applicare la modifica al sito in produzione.
- Tophost supporta PHP 8.4? Sì. Tophost mette attualmente a disposizione sui propri server versioni PHP fino alla 8.4 per tutti i piani hosting, con gestione della versione PHP attraverso il pannello di controllo.
- Devo aggiornare PHP prima di dicembre? Non esiste uno spegnimento automatico di PHP 8.2 il 31 dicembre. Pianificare l’upgrade prima dell’End of Life permette però di evitare di entrare nel 2027 con una versione PHP che ha terminato il proprio ciclo ufficiale di sicurezza.
Il tuo sito continuerà probabilmente a funzionare. Ma questo non è un piano di manutenzione
PHP 8.2 non sta per autodistruggersi e il 1° gennaio 2027 Internet non collasserà sotto il peso dei WordPress dimenticati.
La questione è molto più semplice: uno stack mantenuto, aggiornato e controllato è più facile da proteggere, diagnosticare e far evolvere rispetto a uno stack lasciato invecchiare finché qualcosa non si rompe.
Chi utilizza Tophost può già gestire sui server versioni PHP fino alla 8.4 su tutti i piani. Questo è quindi un buon momento per controllare la propria versione PHP, verificare la compatibilità del progetto e programmare con calma l’eventuale aggiornamento.
Perché il vero developer non è quello che salva la produzione alle 3:47 del mattino con 14 terminali aperti e la soundtrack di Interstellar in sottofondo.
È quello che aveva aggiornato, testato e fatto il backup tre mesi prima… e alle 3:47 dorme. Come un maledetto genio.
Pubblicato: | Aggiornamento: