WordPress failed to open stream: No such file or directory

Questa guida approfondisce WordPress failed to open stream con una procedura progressiva e reversibile. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa l’errore

Il messaggio PHP failed to open stream viene generato quando una funzione tenta di leggere, includere, scrivere o caricare una risorsa e l’operazione non può essere completata. La parte successiva del messaggio è fondamentale: No such file or directory, Permission denied, Operation failed e altri dettagli indicano cause differenti.

In WordPress l’errore può provenire dal core, da un plugin, dal tema, da una libreria Composer, da un file temporaneo o da codice personalizzato. Per diagnosticare WordPress failed to open stream servono il percorso completo, il numero di riga, lo stack trace e l’azione eseguita.

Come riconoscere il problema

• Il log php contiene failed to open stream.
• Il messaggio prosegue con no such file or directory.
• L’errore compare dopo aggiornamento, migrazione o deploy.
• Il percorso indica un plugin, un tema, vendor o wp-content.
• Frontend, wp-admin, cron o wp-cli mostrano comportamenti diversi.

Non fermarti alla prima riga del log. Un warning può precedere un fatal error come Failed opening required oppure una chiamata a funzione o classe non disponibile. Leggere le righe nello stesso secondo aiuta a ricostruire la sequenza corretta.

Differenza tra No such file e Permission denied

No such file or directory indica normalmente che il percorso risolto da PHP non corrisponde a una risorsa esistente. Il file può essere assente, il nome può avere un case differente oppure una directory intermedia può non esistere.

Permission denied indica invece che la risorsa esiste ma il processo non dispone dei diritti necessari per raggiungerla o leggerla. La soluzione non consiste nell’applicare permessi 777: occorre controllare proprietario, gruppo, permessi delle directory superiori e handler PHP.

Cause più frequenti

1. File realmente assente

Il codice tenta di aprire o includere un file che non esiste più nel percorso indicato. Può trattarsi di un file core, di una libreria del plugin, di un template del tema o di una dipendenza rimossa durante un aggiornamento. Confronta il percorso riportato nel log con il filesystem reale e con una copia integra della stessa versione. Una semplice coincidenza temporale con un aggiornamento non è sufficiente: verifica quale file viene richiesto e perché.

2. Percorso assoluto rimasto dalla vecchia installazione

Dopo una migrazione possono rimanere path riferiti alla precedente home directory, al vecchio document root o a una directory temporanea non più valida. Confronta il percorso riportato nel log con il filesystem reale e con una copia integra della stessa versione. Una semplice coincidenza temporale con un aggiornamento non è sufficiente: verifica quale file viene richiesto e perché.

3. Aggiornamento o deploy incompleto

Un trasferimento interrotto, un archivio estratto parzialmente o un aggiornamento non completato può lasciare il codice nuovo insieme a file mancanti della stessa versione. Confronta il percorso riportato nel log con il filesystem reale e con una copia integra della stessa versione. Una semplice coincidenza temporale con un aggiornamento non è sufficiente: verifica quale file viene richiesto e perché.

4. Permessi o proprietario impediscono la lettura

Il file può esistere ma il processo PHP non riesce ad attraversare una directory o a leggerlo. In questo caso il log può mostrare Permission denied invece di No such file or directory. Confronta il percorso riportato nel log con il filesystem reale e con una copia integra della stessa versione. Una semplice coincidenza temporale con un aggiornamento non è sufficiente: verifica quale file viene richiesto e perché.

5. Nome del file con maiuscole e minuscole diverse

Su filesystem Linux i nomi sono case-sensitive. Un riferimento a Class.php non coincide con class.php, anche se la stessa installazione poteva funzionare in un ambiente differente. Confronta il percorso riportato nel log con il filesystem reale e con una copia integra della stessa versione. Una semplice coincidenza temporale con un aggiornamento non è sufficiente: verifica quale file viene richiesto e perché.

6. Include path o autoloader non inizializzato

Il codice usa require, include o un autoloader prima che la directory corretta sia stata registrata, oppure il file vendor/autoload.php non è presente o non è coerente. Confronta il percorso riportato nel log con il filesystem reale e con una copia integra della stessa versione. Una semplice coincidenza temporale con un aggiornamento non è sufficiente: verifica quale file viene richiesto e perché.

7. File temporaneo, cache o sessione già eliminati

Alcune funzioni lavorano con file temporanei. Pulizie, cache, processi concorrenti o timeout possono rimuovere il file tra la creazione e la lettura. Confronta il percorso riportato nel log con il filesystem reale e con una copia integra della stessa versione. Una semplice coincidenza temporale con un aggiornamento non è sufficiente: verifica quale file viene richiesto e perché.

Diagnosi passo per passo

1. Leggere il messaggio completo con file e numero di riga. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.
2. Verificare l’esistenza del percorso indicato. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.
3. Confrontare maiuscole e minuscole di file e directory. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.
4. Controllare proprietario e permessi senza usare 777. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.
5. Confrontare la versione del componente con una copia integra. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.
6. Verificare path assoluti dopo migrazione o clonazione. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.
7. Controllare include, autoload Composer e file vendor. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.
8. Riprodurre separatamente da browser, cron e WP-CLI. Esegui il controllo in sola lettura quando possibile, annota il risultato e confrontalo con una copia funzionante. Non modificare più file contemporaneamente e conserva sempre un backup recuperabile prima di sostituzioni o reinstallazioni.

1. Leggere correttamente il percorso nel log

Il percorso può mostrare la directory del sito, il plugin o tema responsabile e il file chiamante. Controlla se il nome appartiene al core, a wp-content/plugins, a wp-content/themes, a vendor oppure a una cartella temporanea. Il numero di riga identifica il punto che costruisce o usa il path, non necessariamente il componente che ha cancellato il file.

Quando il percorso contiene una vecchia home directory, un dominio precedente o una cartella locale di sviluppo, la causa è spesso una configurazione serializzata, un file di cache, un percorso assoluto salvato dal plugin o codice personalizzato non portabile.

2. Verificare file e directory senza alterarli

Controlla che ogni segmento del percorso esista. Una directory intermedia mancante produce lo stesso risultato di un file finale assente. Verifica inoltre link simbolici, mount e document root: un link interrotto può far apparire inesistente una risorsa presente altrove.

Confronta dimensione, hash e data del file con una copia integra della stessa versione. Non recuperare un singolo file da una release differente: classi, firme di funzione e dipendenze possono non essere compatibili.

3. Controllare maiuscole e minuscole

Linux distingue Template.php, template.php e TEMPLATE.php. Un progetto sviluppato su un filesystem non case-sensitive può funzionare localmente e fallire dopo il trasferimento sul server. Confronta il nome usato nel codice con quello effettivo.

La correzione deve essere coerente con autoload, namespace e convenzioni del componente. Nei progetti versionati registra anche il cambio di case nel sistema di controllo versione, perché una semplice rinomina può non essere rilevata in tutti gli ambienti.

4. Aggiornamenti WordPress, plugin e temi incompleti

Durante un aggiornamento WordPress sostituisce molti file. Spazio o inode esauriti, timeout, interruzioni del processo, permessi errati e deploy simultanei possono lasciare una struttura parziale. Prima di reinstallare verifica backup, stato di manutenzione e versione esatta.

Per un plugin o tema, disattiva soltanto il componente identificato quando possibile, conserva la cartella e reinstalla la stessa release da una fonte affidabile. Per il core usa una procedura di ripristino che non sovrascriva wp-content o wp-config.php senza controllo.

5. Include, require e autoload Composer

include genera normalmente un warning e può consentire al processo di continuare; require può produrre un fatal error quando la risorsa è indispensabile. Funzioni come plugin_dir_path(), get_stylesheet_directory() e costanti WordPress riducono i percorsi assoluti scritti manualmente.

Nei componenti che usano Composer verifica la presenza di vendor/autoload.php, della directory vendor e dei file generati. In un progetto personalizzato, dopo aver installato dipendenze coerenti con il lock file, può essere necessario rigenerare l’autoload. Non eseguire Composer alla cieca su un plugin distribuito già completo.

6. Permessi, proprietario e handler PHP

Un file leggibile dall’utente SSH può non esserlo dal processo web se proprietario, gruppo o ACL non sono coerenti. Controlla anche le directory superiori: per raggiungere il file il processo deve poter attraversare ciascuna directory.

Evita correzioni ricorsive indiscriminate. Ripristina proprietario e permessi secondo il modello dell’account e confronta con file WordPress funzionanti nella stessa directory. Dopo la modifica ripeti la stessa richiesta e verifica il log.

7. File temporanei, cache e processi concorrenti

Upload, elaborazione immagini, importazioni e backup possono creare file temporanei. Se una pulizia o un secondo processo li elimina prima dell’uso, il log mostra un percorso non più esistente. Controlla ordine delle operazioni, durata, lock e spazio disponibile.

Svuotare ogni cache non è una soluzione universale. Identifica quale cache conserva il percorso errato e invalida soltanto il livello coinvolto. Per i file temporanei correggi il ciclo di vita o il processo concorrente, invece di creare manualmente file vuoti.

8. Migrazioni e percorsi assoluti obsoleti

Dopo una migrazione controlla configurazioni di plugin, backup, cache, directory upload personalizzate e codice che contiene il vecchio document root. Le sostituzioni nel database devono rispettare i dati serializzati e devono essere precedute da un backup.

Un path assoluto può essere corretto in un solo server ma fragile nel tempo. Nel codice personalizzato costruisci i percorsi a partire da costanti e funzioni dell’ambiente, validando con file_exists(), is_readable() e gestione esplicita dell’errore.

9. Differenze tra browser, cron e WP-CLI

Il browser, WP-Cron, un cron reale e WP-CLI possono avere directory corrente, variabili d’ambiente, utente e versione PHP differenti. Un percorso relativo che funziona nel web può fallire da CLI, o viceversa.

Costruisci i path rispetto al file del componente oppure usa le API WordPress. Ripeti la prova nell’esatto contesto che genera l’errore e non considerare sufficiente un test eseguito con un altro interprete.

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. Ripristinare il file mancante dalla stessa versione del componente. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.
2. Correggere il percorso obsoleto o costruirlo con funzioni WordPress. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.
3. Completare nuovamente aggiornamento o deploy in modo atomico. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.
4. Ripristinare proprietario e permessi coerenti. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.
5. Correggere il case del nome nel codice o nel filesystem. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.
6. Rigenerare l’autoload Composer quando previsto dal progetto. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.
7. Correggere la gestione dei file temporanei. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.
8. Ritestare tutte le modalità che eseguono il codice. Applica la correzione soltanto dopo aver confermato la causa tramite percorso, log e confronto con una copia integra. Conserva il valore precedente, ripeti l’azione originale e verifica che non compaiano nuovi warning, fatal error o regressioni.

Controlli finali

• L’azione originale viene completata senza failed to open stream.
• Il percorso nel codice corrisponde al filesystem reale.
• File, versione e dipendenze sono coerenti tra loro.
• Proprietario e permessi rispettano il modello sicuro dell’account.
• Browser, cron e WP-CLI sono stati verificati quando coinvolti.

Prevenzione

• Esegui aggiornamenti e deploy con backup e verifica di integrità.
• Evita percorsi assoluti scritti manualmente nel codice.
• Controlla spazio e inode prima di estrazioni o aggiornamenti importanti.
• Testa le migrazioni in staging e verifica cron, CLI e processi asincroni.
• Monitora i log dopo ogni modifica e conserva hash o manifest dei file distribuiti.

Errori da evitare

• Non impostare permessi 777.
• Non creare file vuoti per eliminare il messaggio.
• Non copiare file da versioni differenti del componente.
• Non sostituire ricorsivamente tutti i path senza gestire dati serializzati.
• Non nascondere i warning prima di aver risolto la causa.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il percorso corretto esiste ma PHP continua a non leggerlo, quando il problema compare dopo un’operazione server-side oppure quando browser, cron e WP-CLI mostrano risultati differenti. Indica:

• dominio e URL o comando coinvolto;
• data e ora con fuso;
• messaggio completo con percorso e numero di riga;
• plugin, tema o procedura eseguita;
• controlli già effettuati.

Non inviare credenziali. Oscura dati personali e segreti, ma lascia visibili percorso tecnico, orario, tipo di errore e identificativi utili alla correlazione con i log.

Fonti tecniche ufficiali

• PHP Manual: include
• PHP Manual: require
• WordPress: File Permissions
• WordPress: plugin_dir_path()

Domande frequenti su WordPress failed to open stream