Guida completa Drupal
Errori e sito non raggiungibile in Drupal
In breve: Errori HTTP, pagine bianche, eccezioni e blocchi che impediscono al sito di rispondere. Questa guida riunisce i casi che prima erano distribuiti in trenta URL molto simili e li organizza in un unico percorso diagnostico verificabile.
Ambito e componenti da controllare
Il sintomo visibile è soltanto il punto di partenza. Prima di modificare Drupal, separa applicazione, estensioni, tema, database, cache, web server e servizi esterni. Cambia una variabile per volta e conserva sempre l’evidenza che conferma o esclude un livello.
- Il frontend
- L’area amministrativa
- Una route o un controller
- Twig e il tema
- La connessione al database
- Vendor e bootstrap PHP
Sintomi ed evidenze da raccogliere
| Sintomo | Prima evidenza utile |
|---|---|
| Errore 500 | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Pagina bianca | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Caricamento infinito | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Funzionamento parziale | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Blocco dopo una modifica | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
Diagnosi per componente
Ogni componente può produrre sintomi simili. Le schede seguenti indicano cosa significa ciascun caso e quale prova raccogliere prima della correzione.
Il frontend
Nel contesto di Drupal, il frontend partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.
Errore 500
Quando il frontend presenta un errore 500, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Pagina bianca
Quando il frontend mostra una pagina bianca, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Caricamento infinito
Quando il frontend rimane in caricamento senza completare la risposta, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Funzionamento parziale
Quando il frontend funziona solo per alcune pagine o richieste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Blocco dopo una modifica
Quando il frontend si blocca dopo una modifica recente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
L’area amministrativa
Nel contesto di Drupal, l’area amministrativa partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.
Errore 500
Quando l’area amministrativa presenta un errore 500, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Pagina bianca
Quando l’area amministrativa mostra una pagina bianca, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Caricamento infinito
Quando l’area amministrativa rimane in caricamento senza completare la risposta, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Funzionamento parziale
Quando l’area amministrativa funziona solo per alcune pagine o richieste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Blocco dopo una modifica
Quando l’area amministrativa si blocca dopo una modifica recente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Una route o un controller
Nel contesto di Drupal, una route o un controller partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.
Errore 500
Quando una route o un controller presenta un errore 500, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Pagina bianca
Quando una route o un controller mostra una pagina bianca, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Caricamento infinito
Quando una route o un controller rimane in caricamento senza completare la risposta, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Funzionamento parziale
Quando una route o un controller funziona solo per alcune pagine o richieste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Blocco dopo una modifica
Quando una route o un controller si blocca dopo una modifica recente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Twig e il tema
Nel contesto di Drupal, Twig e il tema partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.
Errore 500
Quando Twig e il tema presenta un errore 500, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Pagina bianca
Quando Twig e il tema mostra una pagina bianca, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Caricamento infinito
Quando Twig e il tema rimane in caricamento senza completare la risposta, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Funzionamento parziale
Quando Twig e il tema funziona solo per alcune pagine o richieste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Blocco dopo una modifica
Quando Twig e il tema si blocca dopo una modifica recente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
La connessione al database
Nel contesto di Drupal, la connessione al database partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.
Errore 500
Quando la connessione al database presenta un errore 500, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Pagina bianca
Quando la connessione al database mostra una pagina bianca, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Caricamento infinito
Quando la connessione al database rimane in caricamento senza completare la risposta, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Funzionamento parziale
Quando la connessione al database funziona solo per alcune pagine o richieste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Blocco dopo una modifica
Quando la connessione al database si blocca dopo una modifica recente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Vendor e bootstrap PHP
Nel contesto di Drupal, vendor e bootstrap PHP partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.
Errore 500
Quando vendor e bootstrap PHP presenta un errore 500, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Pagina bianca
Quando vendor e bootstrap PHP mostra una pagina bianca, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Caricamento infinito
Quando vendor e bootstrap PHP rimane in caricamento senza completare la risposta, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Funzionamento parziale
Quando vendor e bootstrap PHP funziona solo per alcune pagine o richieste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Blocco dopo una modifica
Quando vendor e bootstrap PHP si blocca dopo una modifica recente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima stabilire dove si interrompe la richiesta: DNS, web server, PHP, bootstrap dell’applicazione, database o rendering finale. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.
Percorso diagnostico in ordine
Esegui i controlli dal meno invasivo al più profondo. Un tentativo è utile solo se ha un risultato atteso, produce un’evidenza e può essere annullato.
-
Riprodurre l’errore su un URL preciso e annotare orario e codice HTTP
Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.
-
Controllare log applicativi, PHP e web server cercando la prima eccezione
Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.
-
Verificare spazio, inode, memoria, processi e stato del database
Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.
-
Confrontare i file modificati di recente con una copia affidabile
Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.
-
Disattivare in staging il componente sospetto con un test reversibile
Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.
-
Verificare che il sito risponda anche senza cache e CDN
Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.
Strumenti e percorsi utili in Drupal
- Esegui
vendor/bin/drush statusdalla root corretta per registrare versione, database e percorso dei file. - Controlla i messaggi recenti con gli strumenti di report o
vendor/bin/drush watchdog:show --count=50. - Usa
vendor/bin/drush cache:rebuildsolo come test mirato: una cache ricostruita non corregge codice, dati o dipendenze errati.
Verifica finale e rollback
Il ritorno della pagina non basta a chiudere l’intervento. Ripeti il caso iniziale, un caso di controllo e i flussi collegati; poi verifica che non siano comparsi nuovi errori.
- il frontend nel caso che generava il problema e in un secondo caso di controllo
- frontend e area amministrativa con utenti e permessi differenti
- salvataggio dei dati e assenza di nuovi errori nei log
- email, attività pianificate, API, code o callback coinvolte
- cache e CDN dopo la riattivazione
- prestazioni, consumo risorse e stabilità per un intervallo adeguato
- backup aggiornato e documentazione della modifica
Riferimenti ufficiali
I percorsi e i comandi possono cambiare tra versioni. Prima di intervenire, confronta la procedura con la documentazione della versione installata e conserva un rollback verificato.
Domande frequenti
Da quale controllo partire per errori e sito non raggiungibile in Drupal?
Parti da un caso riproducibile e dal log registrato nello stesso orario. Versioni, ultima modifica, URL, utente e risultato atteso permettono di distinguere un errore applicativo da cache, infrastruttura o servizi esterni.
È sufficiente svuotare la cache?
No. La cache è un livello da verificare, ma non corregge file mancanti, dipendenze incompatibili, dati incoerenti o configurazioni errate. Usala come test e annota quale livello ha restituito la risposta.
Quando serve un ambiente di staging?
Quando la correzione può influire su utenti, ordini, contenuti, permessi o configurazioni. Lo staging deve rappresentare il caso reale senza esporre dati personali e deve avere un piano di riallineamento con la produzione.
Quali informazioni preparare prima di chiedere assistenza?
Prepara URL, messaggio, orario, versione di Drupal, versione PHP e database, modifiche recenti, accessi disponibili e un estratto pertinente dei log. Non inviare password nel primo messaggio.
Quando è preferibile un rollback?
Quando il ripristino del servizio è prioritario e la modifica può essere annullata senza perdere dati recenti. Prima confronta file e database del backup con lo stato corrente e conserva separatamente ordini, utenti o contenuti creati dopo la copia.
Serve una diagnosi sul tuo sito?
Se il problema riguarda un’installazione reale, prepara versione, URL, orario, modifiche recenti e log pertinenti.