Cambiare versione PHP senza bloccare WordPress

Questa guida approfondisce cambiare versione PHP WordPress con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

Ogni versione PHP possiede configurazione, moduli e opzioni proprie. Il passaggio può quindi cambiare memory_limit, estensioni, OPcache e comportamento del codice.

Il fatto che la homepage si apra non dimostra piena compatibilità: checkout, form, API, immagini e cron possono usare percorsi diversi.

Come riconoscere il problema

• Dopo il cambio appare un fatal error.
• Un plugin richiede una estensione mancante.
• Il sito funziona ma checkout o wp-admin no.
• I limiti PHP tornano ai valori predefiniti.
• Una funzione deprecata genera errori.

Cause più frequenti

1. Plugin o tema incompatibile

Il codice usa funzioni rimosse o firme cambiate. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. Estensione non attiva

mysqli, curl, intl, zip, mbstring o imagick non sono selezionate. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

3. Opzioni differenti

Memoria, upload e timeout cambiano con la versione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

4. Cache opcode

Il processo può mantenere codice precedente per breve tempo. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

5. IonCube o software codificato

Il loader o il pacchetto non supporta la versione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

6. Test incompleto

Funzioni non visitate falliscono dopo il passaggio. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

Diagnosi passo per passo

1. Inventaria il sito. Registra WordPress, tema, plugin e applicazioni. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
2. Controlla requisiti ufficiali. Verifica versioni supportate. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
3. Crea backup e staging. Testa prima su una copia quando possibile. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
4. Annota estensioni e opzioni. Confronta la versione attuale e quella nuova. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
5. Attiva log non pubblico. Registra errori senza mostrarli ai visitatori. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
6. Cambia una sola versione. Evita modifiche simultanee a plugin e PHP. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
7. Esegui un piano di test. Homepage, login, form, cron, e-commerce e API. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

Metodo sicuro di diagnosi

Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.

Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.

Procedura di risoluzione

1. Aggiorna componenti prima del passaggio. Usa versioni supportate e backup. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Seleziona PHP da cPanel. In Software → Select PHP Version scegli la versione prevista. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Abilita estensioni necessarie. Non selezionare moduli casuali. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Ripristina opzioni pertinenti. Controlla memory_limit, upload e timeout. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Pulisci cache applicative. Dopo il cambio verifica codice e pagine. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Correggi gli errori. Intervieni sul componente indicato dal log. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Esegui rollback immediato se necessario. Torna alla versione precedente mentre prepari la correzione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Verifica della stabilità dopo l’intervento

Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.

Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.

Controlli finali

• Frontend e wp-admin funzionano.
• Form e posta partono.
• Cron completa gli eventi.
• Checkout e API funzionano.
• Log senza fatal error.

Prevenzione

• Mantieni plugin aggiornati.
• Usa staging.
• Documenta estensioni.
• Controlla versioni supportate.
• Pianifica rollback.

Errori da evitare

• Non cambiare PHP e molti plugin insieme.
• Non usare una versione obsoleta stabilmente.
• Non mostrare errori sul frontend.
• Non dimenticare estensioni.
• Non cancellare il backup dopo il primo test.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:

• dominio
• versione prima e dopo
• errore completo
• plugin o funzione
• estensioni attive

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• CloudLinux PHP Selector UI
• WordPress requirements

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.

Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.

Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.

Domande frequenti su cambiare versione PHP WordPress