WordPress: estensione PHP mancante o non disponibile

Questa guida analizza WordPress estensione PHP mancante con controlli progressivi, verifiche incrociate e modifiche reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa

PHP è composto da un nucleo e da estensioni che aggiungono funzioni per immagini, archivi ZIP, crittografia, XML, internazionalizzazione, database e comunicazioni di rete. WordPress core può funzionare con un insieme di moduli, mentre plugin e temi possono richiederne altri per specifiche funzioni.

Il messaggio relativo a WordPress estensione PHP mancante non dimostra sempre che il pacchetto sia assente dal server. Il modulo può essere installato ma non attivo per la versione PHP del dominio, può essere caricato da CLI ma non dal processo web oppure può fallire durante l’avvio per una dipendenza mancante.

Come riconoscere il problema

• Site Health segnala uno o più moduli PHP mancanti.
• un plugin mostra il messaggio required PHP extension missing.
• compare Call to undefined function dopo un cambio di versione PHP.
• il modulo risulta disponibile da CLI ma non dal sito.
• l’errore interessa un solo dominio o una sola versione PHP.

Registra il nome esatto dell’estensione e il file che genera l’errore. Messaggi generici come “modulo PHP mancante” non sono sufficienti: intl, mbstring, zip, curl, gd, imagick, sodium, soap e xml richiedono controlli differenti.

Cause più frequenti

1. Modulo non attivato per la versione PHP del dominio

Il dominio usa una versione PHP nella quale l’estensione richiesta non è stata abilitata, anche se lo stesso modulo è disponibile in un’altra versione installata sul server. Verifica questa ipotesi confrontando il risultato del processo web con quello della riga di comando e con la configurazione mostrata dal pannello. Non cambiare versione PHP o attivare moduli casualmente: una modifica non necessaria può introdurre incompatibilità aggiuntive.

2. Versione PHP diversa tra sito e riga di comando

WP-CLI, cron e browser possono utilizzare binari o handler differenti. Un controllo eseguito soltanto da shell può quindi mostrare un modulo che il processo web non carica. Verifica questa ipotesi confrontando il risultato del processo web con quello della riga di comando e con la configurazione mostrata dal pannello. Non cambiare versione PHP o attivare moduli casualmente: una modifica non necessaria può introdurre incompatibilità aggiuntive.

3. Plugin o tema con requisiti non soddisfatti

Il componente richiede estensioni come intl, mbstring, zip, soap, gd, imagick, sodium o xml, ma il requisito non è stato verificato prima dell’installazione o dell’aggiornamento. Verifica questa ipotesi confrontando il risultato del processo web con quello della riga di comando e con la configurazione mostrata dal pannello. Non cambiare versione PHP o attivare moduli casualmente: una modifica non necessaria può introdurre incompatibilità aggiuntive.

4. Configurazione per-directory non applicata

File .user.ini, selettori PHP o impostazioni del pannello possono riferirsi alla directory sbagliata, a un handler diverso oppure essere ancora soggetti alla cache della configurazione. Verifica questa ipotesi confrontando il risultato del processo web con quello della riga di comando e con la configurazione mostrata dal pannello. Non cambiare versione PHP o attivare moduli casualmente: una modifica non necessaria può introdurre incompatibilità aggiuntive.

5. Estensione caricata con dipendenze mancanti

Il modulo esiste ma non viene inizializzato perché manca una libreria di sistema, una dipendenza condivisa o una configurazione necessaria; il log PHP può mostrare startup warning. Verifica questa ipotesi confrontando il risultato del processo web con quello della riga di comando e con la configurazione mostrata dal pannello. Non cambiare versione PHP o attivare moduli casualmente: una modifica non necessaria può introdurre incompatibilità aggiuntive.

6. Cambio di handler o aggiornamento incompleto

Un passaggio tra LSAPI, PHP-FPM, CGI o un aggiornamento di pacchetti può lasciare processi attivi con una configurazione precedente o moduli non allineati. Verifica questa ipotesi confrontando il risultato del processo web con quello della riga di comando e con la configurazione mostrata dal pannello. Non cambiare versione PHP o attivare moduli casualmente: una modifica non necessaria può introdurre incompatibilità aggiuntive.

Diagnosi passo per passo

1. Identificare il nome esatto dell’estensione richiesta. Esegui il controllo nell’ambiente che genera l’errore e salva versione PHP, handler, percorso del file ini e lista dei moduli. Confronta il dato con i requisiti ufficiali del componente, quindi passa al punto successivo soltanto se la causa non è ancora confermata.
2. Verificare la versione PHP effettiva usata dal dominio. Esegui il controllo nell’ambiente che genera l’errore e salva versione PHP, handler, percorso del file ini e lista dei moduli. Confronta il dato con i requisiti ufficiali del componente, quindi passa al punto successivo soltanto se la causa non è ancora confermata.
3. Controllare i moduli caricati dal processo web. Esegui il controllo nell’ambiente che genera l’errore e salva versione PHP, handler, percorso del file ini e lista dei moduli. Confronta il dato con i requisiti ufficiali del componente, quindi passa al punto successivo soltanto se la causa non è ancora confermata.
4. Confrontare browser, WP-CLI e cron. Esegui il controllo nell’ambiente che genera l’errore e salva versione PHP, handler, percorso del file ini e lista dei moduli. Confronta il dato con i requisiti ufficiali del componente, quindi passa al punto successivo soltanto se la causa non è ancora confermata.
5. Leggere error log e PHP startup warning. Esegui il controllo nell’ambiente che genera l’errore e salva versione PHP, handler, percorso del file ini e lista dei moduli. Confronta il dato con i requisiti ufficiali del componente, quindi passa al punto successivo soltanto se la causa non è ancora confermata.
6. Controllare i requisiti del plugin o del tema. Esegui il controllo nell’ambiente che genera l’errore e salva versione PHP, handler, percorso del file ini e lista dei moduli. Confronta il dato con i requisiti ufficiali del componente, quindi passa al punto successivo soltanto se la causa non è ancora confermata.
7. Verificare configurazione e cache dell’handler PHP. Esegui il controllo nell’ambiente che genera l’errore e salva versione PHP, handler, percorso del file ini e lista dei moduli. Confronta il dato con i requisiti ufficiali del componente, quindi passa al punto successivo soltanto se la causa non è ancora confermata.

Controllare la versione PHP effettiva

La versione selezionata nel pannello deve coincidere con quella usata dal dominio. Un sottodominio, una directory protetta, un cron o WP-CLI possono seguire configurazioni differenti. Usa strumenti temporanei e rimuovili dopo la diagnosi: una pagina phpinfo pubblica espone dettagli che non devono restare accessibili.

Annota versione, Server API, percorso del file di configurazione caricato e directory aggiuntive analizzate. Questi dati permettono di capire se una modifica eseguita in MultiPHP Manager, PHP Selector o .user.ini raggiunge realmente il processo che esegue WordPress.

Verificare i moduli caricati

Controlla la presenza del modulo nel processo web e non soltanto da shell. Per alcune estensioni è utile verificare anche la funzione o la classe fornita, per esempio class_exists(), extension_loaded() o una funzione specifica. Il test deve essere rimosso appena concluso.

Quando il modulo compare nella configurazione ma non viene caricato, cerca warning di avvio PHP. Messaggi relativi a file condivisi, simboli non trovati o dipendenze mancanti indicano che l’estensione è stata richiesta ma non inizializzata correttamente.

Moduli richiesti più spesso

intl gestisce internazionalizzazione, formati e translitterazione. mbstring lavora con stringhe multibyte. zip è usata da importazioni, backup e pacchetti. gd e imagick elaborano immagini. sodium offre primitive crittografiche. xml, dom e simplexml servono per documenti strutturati e feed.

La presenza di un’alternativa non garantisce compatibilità. Un plugin può supportare GD o Imagick, mentre un altro può richiedere espressamente una classe specifica. Leggi sempre i requisiti del componente e il messaggio completo prima di decidere quale modulo attivare.

Gestione tramite cPanel

Quando disponibile, usa lo strumento previsto dal servizio per selezionare versione ed estensioni PHP. Verifica di operare sul dominio corretto e conserva uno screenshot o un elenco dello stato precedente. Dopo il salvataggio considera l’eventuale cache di .user.ini e dell’handler.

Non aggiungere manualmente righe extension= se il provider gestisce i moduli centralmente: indicare un file non presente o caricare due volte la stessa estensione può produrre warning e blocchi. La modalità corretta dipende dall’handler e dalla piattaforma.

Plugin, temi e compatibilità

Prima di attivare un modulo verifica che plugin e tema siano aggiornati e compatibili con la versione PHP in uso. Un componente obsoleto può segnalare come “mancante” una funzione rimossa o rinominata, oppure richiedere una libreria non disponibile nella versione scelta.

Esegui i test in staging quando il sito è critico. Dopo l’attivazione controlla frontend, wp-admin, cron, REST API, upload, elaborazione immagini, email e procedure di backup interessate dal modulo.

Metodo sicuro di diagnosi

Prima di modificare la configurazione, registra il messaggio completo, la data e l’ora con fuso, l’URL o il servizio coinvolto, l’ultima modifica nota e il risultato ottenuto con un secondo strumento. Conserva request ID, transaction ID, Message-ID, Ray ID, rule ID e codici applicativi quando presenti: questi identificativi collegano la schermata ai log senza richiedere password, cookie, token, chiavi private o codici di autenticazione.

Applica una sola modifica alla volta. Dopo ogni intervento ripeti la stessa operazione con gli stessi dati di test e controlla i log dello stesso intervallo temporale. Cambiare contemporaneamente DNS, cache, PHP, plugin, firewall, database, client e proxy impedisce di capire quale variazione abbia prodotto il risultato e rende più difficile un rollback affidabile.

Controllo incrociato dei livelli

Un errore visibile nel browser o nel client può essere generato da livelli differenti. Per il web confronta browser, curl, CDN, web server, PHP e applicazione. Per WordPress confronta frontend, wp-admin, Site Health, strumenti sviluppatore, WP-CLI e log. Per FTP separa sessione di controllo, canale dati, firewall e account. Per la posta confronta client, Webmail, coda SMTP, Track Delivery, DNS e risposta del destinatario.

Verifica sempre quale sistema ha prodotto il codice. Header, hostname, percorso del log, stack trace e testo esteso aiutano a distinguere un errore dell’edge da uno dell’origine, un rifiuto del proprio server da uno remoto e un problema applicativo da uno di rete. Questa distinzione evita interventi sul componente sbagliato.

Backup e reversibilità

Prima di cambiare file, record DNS, database, plugin o regole di sicurezza crea una copia leggibile e annota il valore precedente. Per DNS registra TTL e nameserver autoritativi. Per firewall e proxy conserva l’espressione originale della regola. Per WordPress salva il componente e le opzioni coinvolte. Una modifica reversibile consente di interrompere il test senza aggiungere un secondo guasto.

Non usare permessi 777, non disattivare globalmente WAF o antispam e non ridurre stabilmente la sicurezza TLS per ottenere una pagina funzionante. Le eccezioni devono essere limitate al percorso, parametro, hostname o sorgente confermati dai log. Quando una prova richiede una misura temporanea, annota il momento di attivazione e ripristinala appena concluso il test.

Come raccogliere prove utili

Esporta testo e dati originali quando possibile: header HTTP, file .eml, bounce completo, output DNS, righe di log, stack trace e codici di risposta sono più utili di uno screenshot ritagliato. Oscura credenziali e dati personali, ma lascia visibili data, server, status, identificativi e descrizione tecnica dell’errore.

Ripeti il controllo con un caso minimo. Per una API usa pochi campi; per WordPress prova una funzione core; per FTP trasferisci un file di testo; per la posta invia un messaggio semplice senza allegati. Aggiungi poi complessità progressivamente fino a individuare il punto nel quale compare il problema.

Cache, sessioni, code e ritardi

Non tutti i cambiamenti diventano visibili immediatamente. DNS, cache CDN, cache LiteSpeed, sessioni PHP, connessioni persistenti, code SMTP, cron e lock possono continuare a mostrare lo stato precedente. Verifica il TTL o la durata della cache, usa un nuovo identificativo di richiesta e controlla se il sistema sta elaborando una copia già accodata.

Un retry riuscito non annulla automaticamente l’errore precedente nei log. Confronta sempre l’identificativo della nuova richiesta con quello vecchio e verifica che il risultato sia relativo alla stessa URL, casella, query o operazione. Questa attenzione evita di dichiarare risolto un problema sulla base di una prova differente.

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Considera cache, TTL DNS, code SMTP, cron, lock, connessioni persistenti e processi pianificati che possono mostrare il vecchio comportamento per un certo periodo.

Conserva temporaneamente backup, valori precedenti ed estratti dei log. Se l’anomalia ricompare, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, picchi di traffico, importazioni e servizi esterni. Documenta infine causa, correzione e prova finale per rendere più rapido un futuro intervento.

Procedura di risoluzione

1. Attivare il modulo nella versione PHP corretta. Applica la correzione soltanto dopo aver identificato versione PHP, handler e requisito del componente. Conserva il valore precedente, ripeti il test originale e controlla nello stesso intervallo eventuali warning, fatal error e regressioni.
2. Allineare PHP web, WP-CLI e cron quando necessario. Applica la correzione soltanto dopo aver identificato versione PHP, handler e requisito del componente. Conserva il valore precedente, ripeti il test originale e controlla nello stesso intervallo eventuali warning, fatal error e regressioni.
3. Installare o ripristinare le dipendenze supportate. Applica la correzione soltanto dopo aver identificato versione PHP, handler e requisito del componente. Conserva il valore precedente, ripeti il test originale e controlla nello stesso intervallo eventuali warning, fatal error e regressioni.
4. Aggiornare o sostituire il componente incompatibile. Applica la correzione soltanto dopo aver identificato versione PHP, handler e requisito del componente. Conserva il valore precedente, ripeti il test originale e controlla nello stesso intervallo eventuali warning, fatal error e regressioni.
5. Correggere .user.ini o selettore PHP del dominio. Applica la correzione soltanto dopo aver identificato versione PHP, handler e requisito del componente. Conserva il valore precedente, ripeti il test originale e controlla nello stesso intervallo eventuali warning, fatal error e regressioni.
6. Riavviare soltanto l’handler interessato dopo la modifica. Applica la correzione soltanto dopo aver identificato versione PHP, handler e requisito del componente. Conserva il valore precedente, ripeti il test originale e controlla nello stesso intervallo eventuali warning, fatal error e regressioni.
7. Ritestare WordPress e controllare i log. Applica la correzione soltanto dopo aver identificato versione PHP, handler e requisito del componente. Conserva il valore precedente, ripeti il test originale e controlla nello stesso intervallo eventuali warning, fatal error e regressioni.

Controlli finali

• La funzione che generava WordPress estensione PHP mancante ora completa correttamente.
• Il modulo risulta caricato dal processo web della versione PHP corretta.
• WP-CLI e cron usano una versione coerente quando richiesto.
• Non compaiono PHP startup warning o nuovi fatal error.
• Il componente e le funzioni collegate sono stati verificati.

Prevenzione

• Controlla i requisiti PHP prima di installare plugin e temi.
• Documenta versione, handler ed estensioni dei siti critici.
• Prova gli aggiornamenti di PHP e componenti in staging.
• Rimuovi moduli e componenti non più necessari solo dopo una verifica.
• Monitora error log e Site Health dopo ogni modifica.

Errori da evitare

• Non attivare tutte le estensioni senza verificarne la necessità.
• Non usare phpinfo come pagina pubblica permanente.
• Non modificare file ini di versioni PHP diverse da quella del dominio.
• Non installare manualmente moduli fuori dal sistema di gestione del server.
• Non considerare il risultato di CLI come prova sufficiente per il processo web.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il modulo risulta selezionato ma il sito non lo carica, quando compaiono startup warning oppure quando browser, WP-CLI e cron usano ambienti differenti. Indica:

• dominio e versione PHP;
• nome esatto dell’estensione;
• data e ora con fuso;
• messaggio completo e file coinvolto;
• controlli già eseguiti.

Non inviare credenziali. Non allegare phpinfo completa se non espressamente richiesta e proteggi sempre i dati sensibili.

Fonti tecniche ufficiali

• WordPress Hosting Handbook: Server Environment
• PHP Manual: Extensions
• cPanel: Select PHP Version

Domande frequenti su WordPress estensione PHP mancante