Guida completa Drupal
Email, attività pianificate e integrazioni in Drupal
In breve: Invio email, processi pianificati, code, API e servizi esterni. 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.
Sintomi ed evidenze da raccogliere
| Sintomo | Prima evidenza utile |
|---|---|
| Attività non eseguite | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Dati incompleti | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Errore di autenticazione | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Interruzioni intermittenti | Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log. |
| Operazioni accumulate in coda | 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.
Cron
Nel contesto di Drupal, cron 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.
Attività non eseguite
Quando cron non esegue le attività previste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Dati incompleti
Quando cron invia dati incompleti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Errore di autenticazione
Quando cron restituisce errori di autenticazione, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Interruzioni intermittenti
Quando cron si interrompe in modo intermittente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Operazioni accumulate in coda
Quando cron accumula operazioni in coda, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Le code
Nel contesto di Drupal, le code 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.
Attività non eseguite
Quando le code non esegue le attività previste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Dati incompleti
Quando le code invia dati incompleti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Errore di autenticazione
Quando le code restituisce errori di autenticazione, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Interruzioni intermittenti
Quando le code si interrompe in modo intermittente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Operazioni accumulate in coda
Quando le code accumula operazioni in coda, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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’invio email
Nel contesto di Drupal, l’invio email 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.
Attività non eseguite
Quando l’invio email non esegue le attività previste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Dati incompleti
Quando l’invio email invia dati incompleti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Errore di autenticazione
Quando l’invio email restituisce errori di autenticazione, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Interruzioni intermittenti
Quando l’invio email si interrompe in modo intermittente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Operazioni accumulate in coda
Quando l’invio email accumula operazioni in coda, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
REST e JSON:API
Nel contesto di Drupal, REST e JSON:API 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.
Attività non eseguite
Quando REST e JSON:API non esegue le attività previste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Dati incompleti
Quando REST e JSON:API invia dati incompleti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Errore di autenticazione
Quando REST e JSON:API restituisce errori di autenticazione, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Interruzioni intermittenti
Quando REST e JSON:API si interrompe in modo intermittente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Operazioni accumulate in coda
Quando REST e JSON:API accumula operazioni in coda, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Webform
Nel contesto di Drupal, Webform 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.
Attività non eseguite
Quando Webform non esegue le attività previste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Dati incompleti
Quando Webform invia dati incompleti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Errore di autenticazione
Quando Webform restituisce errori di autenticazione, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Interruzioni intermittenti
Quando Webform si interrompe in modo intermittente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Operazioni accumulate in coda
Quando Webform accumula operazioni in coda, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Un servizio esterno
Nel contesto di Drupal, un servizio esterno 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.
Attività non eseguite
Quando un servizio esterno non esegue le attività previste, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Dati incompleti
Quando un servizio esterno invia dati incompleti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Errore di autenticazione
Quando un servizio esterno restituisce errori di autenticazione, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Interruzioni intermittenti
Quando un servizio esterno si interrompe in modo intermittente, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
Operazioni accumulate in coda
Quando un servizio esterno accumula operazioni in coda, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima seguire il flusso dalla generazione dell’evento fino alla sua esecuzione, consegna o conferma da parte del servizio esterno. 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.
-
Identificare evento, payload, destinatario e timestamp
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 l’attività sia stata creata e poi eseguita
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 e risposta del servizio esterno
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.
-
Validare credenziali, token, firma e scadenza
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.
-
Testare DNS, rete e firewall dal server
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.
-
Simulare un caso controllato senza coinvolgere dati reali
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.
- cron 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 email, attività pianificate e integrazioni 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.