In breve: WordPress failed to open stream: No such file or directory: WordPress failed to open stream indica che PHP non riesce ad aprire un file, una directory o una risorsa richiesta dal codice.
Indice dei contenuti
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.
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.
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.
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.
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.
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.
Diagnosi passo per passo
- Leggere il messaggio completo con file e numero di riga.
- Verificare l’esistenza del percorso indicato.
- Confrontare maiuscole e minuscole di file e directory.
- Controllare proprietario e permessi senza usare 777.
- Confrontare la versione del componente con una copia integra.
- Verificare path assoluti dopo migrazione o clonazione.
- Controllare include, autoload Composer e file vendor.
- Riprodurre separatamente da browser, cron e WP-CLI.
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.
Procedura di risoluzione
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Domande frequenti
Che cosa significa “failed to open stream: No such file or directory” in WordPress?
PHP sta tentando di leggere o includere una risorsa che non trova nel percorso risolto. Il file può essere assente, il percorso può essere rimasto da una vecchia installazione oppure possono esserci differenze di maiuscole/minuscole o directory mancanti.
Quali controlli fare per individuare il file mancante?
Leggi percorso e riga nel log, verifica l’esistenza di file e directory, confronta maiuscole e minuscole e controlla aggiornamenti incompleti, autoload, permessi e vecchi percorsi assoluti dopo una migrazione.
Guide Xlogic correlate
- WordPress Fatal error Class not found
- WordPress errore connessione sicura a WordPress.org
- WooCommerce nonce verification failed nel checkout