Vai al contenuto

Guida completa Drupal

Database, dati e contenuti in Drupal

In breve: Integrità dei dati, salvataggi, relazioni, indici e ripristini. 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
Dati mancanti Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Record duplicati o incoerenti Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Modifiche non salvate Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Query lente o errori SQL Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Incoerenza dopo un ripristino 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.

Nodi ed entità

Nel contesto di Drupal, nodi ed entità 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.

Dati mancanti

Quando nodi ed entità mostra dati mancanti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Record duplicati o incoerenti

Quando nodi ed entità crea record duplicati o incoerenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Modifiche non salvate

Quando nodi ed entità non salva le modifiche, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Query lente o errori SQL

Quando nodi ed entità restituisce query lente o errori SQL, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Incoerenza dopo un ripristino

Quando nodi ed entità perde coerenza dopo un ripristino, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Campi

Nel contesto di Drupal, campi 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.

Dati mancanti

Quando campi mostra dati mancanti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Record duplicati o incoerenti

Quando campi crea record duplicati o incoerenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Modifiche non salvate

Quando campi non salva le modifiche, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Query lente o errori SQL

Quando campi restituisce query lente o errori SQL, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Incoerenza dopo un ripristino

Quando campi perde coerenza dopo un ripristino, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Views

Nel contesto di Drupal, Views 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.

Dati mancanti

Quando Views mostra dati mancanti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Record duplicati o incoerenti

Quando Views crea record duplicati o incoerenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Modifiche non salvate

Quando Views non salva le modifiche, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Query lente o errori SQL

Quando Views restituisce query lente o errori SQL, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Incoerenza dopo un ripristino

Quando Views perde coerenza dopo un ripristino, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Tassonomie

Nel contesto di Drupal, tassonomie 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.

Dati mancanti

Quando tassonomie mostra dati mancanti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Record duplicati o incoerenti

Quando tassonomie crea record duplicati o incoerenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Modifiche non salvate

Quando tassonomie non salva le modifiche, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Query lente o errori SQL

Quando tassonomie restituisce query lente o errori SQL, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Incoerenza dopo un ripristino

Quando tassonomie perde coerenza dopo un ripristino, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Configurazione

Nel contesto di Drupal, configurazione 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.

Dati mancanti

Quando configurazione mostra dati mancanti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Record duplicati o incoerenti

Quando configurazione crea record duplicati o incoerenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Modifiche non salvate

Quando configurazione non salva le modifiche, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Query lente o errori SQL

Quando configurazione restituisce query lente o errori SQL, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Incoerenza dopo un ripristino

Quando configurazione perde coerenza dopo un ripristino, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Utenti e file

Nel contesto di Drupal, utenti e file 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.

Dati mancanti

Quando utenti e file mostra dati mancanti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Record duplicati o incoerenti

Quando utenti e file crea record duplicati o incoerenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Modifiche non salvate

Quando utenti e file non salva le modifiche, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Query lente o errori SQL

Quando utenti e file restituisce query lente o errori SQL, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

Incoerenza dopo un ripristino

Quando utenti e file perde coerenza dopo un ripristino, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima distinguere un problema di interfaccia da un errore di persistenza, integrità referenziale, indicizzazione o ripristino incoerente. 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.

  1. Creare una copia del database prima di qualsiasi correzione

    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.

  2. Individuare tabelle e record coinvolti senza modifiche manuali immediate

    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.

  3. Confrontare i dati con log, ordini, contenuti o esportazioni affidabili

    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.

  4. Verificare indici, vincoli e stato delle tabelle

    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.

  5. Riprodurre il salvataggio con un caso minimo

    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.

  6. Usare le API del CMS per la correzione quando disponibili

    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 status dalla 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:rebuild solo come test mirato: una cache ricostruita non corregge codice, dati o dipendenze errati.
Attenzione: comandi, percorsi e nomi dei menu cambiano tra versioni e ambienti. Verifica sempre la documentazione della versione installata e non eseguire comandi distruttivi senza backup.

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.

  • nodi ed entità 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 database, dati e contenuti 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.

Assistenza Drupal Invia i dettagli del problema