Aggiornare PHP su molti siti WordPress richiede un inventario per applicazione, non soltanto una nuova versione installata sul server. Ogni dominio può usare un pool FPM diverso, mentre cron, WP-CLI e worker possono avviarsi con un altro eseguibile.
Nelle nostre note operative compaiono versioni miste e applicazioni legacy che hanno richiesto valutazioni separate. È il contesto da cui parto: un aggiornamento di flotta non coincide con un interruttore che rende tutti i siti compatibili nello stesso momento.
Scegliere la destinazione prima della finestra di lavoro
Controllerei la tabella ufficiale delle versioni PHP supportate e la compatibilità dichiarata da WordPress, tema, plugin e dipendenze custom. Il numero più recente disponibile non è, da solo, una prova che l’applicazione sia pronta.
Per ogni dominio registrerei runtime web, estensioni, configurazioni rilevanti e lavori pianificati. Le eccezioni devono avere un motivo e un piano: lasciare un sito su una versione fuori supporto non diventa una soluzione definitiva perché continua ad aprirsi.
Provare i percorsi che possono rompersi
Una copia di collaudo deve permettere di verificare login, modifica di contenuti, upload, ricerca e integrazioni. Per un negozio aggiungerei il percorso di acquisto in modalità di test.
La copia deve essere protetta e configurata per evitare invii, pagamenti o sincronizzazioni reali non desiderati. Replicare i dati senza disattivare gli effetti esterni può creare problemi prima ancora di iniziare il test.
Leggerei le guide di migrazione per tutte le versioni attraversate. Per esempio, il passaggio a PHP 8.0 trasforma in TypeError l’uso di count con valori non conteggiabili: non è una novità introdotta soltanto da PHP 8.4.
Controllare il runtime realmente usato
La versione mostrata da un comando nella shell descrive quel comando. Non dimostra quale versione esegua il sito tramite FPM, né quale venga usata da un cron con un percorso esplicito.
Verificherei ciascun punto di ingresso e le estensioni necessarie. Anche configurazioni di memoria, upload e OPcache devono essere controllate nell’ambiente pertinente, senza presumere che cambiare il valore predefinito del pannello aggiorni ogni processo.
Procedere per gruppi con criteri di arresto
Inizierei da siti rappresentativi e con un recupero ben preparato. Dopo ogni gruppo controllerei errori, tempi di risposta e funzioni principali prima di estendere il cambiamento.
Il piano deve indicare cosa fa fermare il rollout e chi può decidere il ritorno alla configurazione precedente. La sola assenza di errori nella homepage è una verifica troppo stretta per un’applicazione con area riservata o pubblicazione pianificata.
Preparare un recupero che includa i dati
Rimettere il vecchio runtime può aiutare quando il problema riguarda la compatibilità del codice. Non annulla una migrazione del database o una modifica effettuata nel frattempo da un plugin.
Per questo distinguerei rollback del runtime, ripristino del codice e recupero dei dati. Il risultato utile è un inventario aggiornato con verifiche per sito e motivi delle eventuali eccezioni, su cui costruire il prossimo aggiornamento con meno incertezza.