errore database wordpress
Identificare rapidamente ciò che vedete (e cosa implica)
Quando WordPress visualizza Errore durante la connessione al database , significa che PHP (WordPress) non riesce a stabilire una sessione valida con MySQL/MariaDB. In pratica, il sito non può più leggere i suoi contenuti (articoli, pagine, impostazioni, utenti), poiché tutto è memorizzato nel database.
Questo messaggio è volutamente generico. Le cause più frequenti si suddividono in alcune famiglie: credenziali errate in wp-config.php, server del database non disponibile, database corrotto, limiti di risorse raggiunti o incidente lato hosting. L’obiettivo è quindi determinare dove la catena si interrompe: WordPress → rete → server DB → autenticazione → tabelle.
Passo 1: verificare l’accesso al sito e al back-office (indizio prezioso)
Primo riflesso: testate sia la home page sia /wp-admin/. Se il front-end è KO ma l’admin si apre, il problema può essere parziale (cache, tabella specifica, sovraccarico). Se è tutto KO, orientatevi piuttosto verso un problema di connessione globale (credenziali, server DB down, guasto dell’hosting).
Altro indizio: alcuni host mostrano una pagina di errore diversa o un messaggio del tipo Error establishing a database connection più grezzo. Annotate l’ora, il contesto (aggiornamento, picco di traffico, migrazione) e qualsiasi cambiamento recente (plugin, tema, manipolazione DNS, ripristino di backup).
Passo 2: controllare i parametri di connessione in wp-config.php
Nella maggior parte dei casi, l’errore deriva da un parametro errato in wp-config.php. Le costanti da verificare sono:
DB_NAME (nome del database), DB_USER (utente), DB_PASSWORD (password), DB_HOST (host del server del database).
Punti di attenzione su DB_HOST (spesso sottovalutato)
Su molti hosting, DB_HOST vale localhost. Ma non è universale: può trattarsi di un IP, di un hostname interno (es. mysqlXX), o di un socket specifico. Dopo una migrazione, un cambio di offerta o il passaggio a un ambiente gestito, questo valore può cambiare.
Verificare senza sbagliare
Confrontate i valori di wp-config.php con quelli indicati nel pannello di controllo dell’host (database, utente, password, host). Se avete recentemente rigenerato una password MySQL, non dimenticate di riportarla qui. Basta un solo refuso.
Se avete bisogno di una guida passo-passo lato hosting, potete consultare Risolvere l’Errore Errore durante la connessione al database di … che dettaglia le verifiche tipiche e i percorsi più comuni nelle interfacce degli host.
Passo 3: testare la connessione MySQL al di fuori di WordPress
L’idea è semplice: determinare se il problema proviene da WordPress o dal database stesso. Se riuscite a connettervi a MySQL con le stesse credenziali, allora WordPress fallisce per una ragione secondaria (risorse, corruzione, plugin, ecc.). Se la connessione fallisce, il problema è proprio a livello di accessi/server.
Metodi possibili a seconda del vostro accesso:
1) Tramite phpMyAdmin: provate ad aprire il database e a scorrere le tabelle.
2) Via SSH : un comando del tipo mysql -h HOST -u USER -p (se l’host lo permette).
3) Tramite l’interfaccia dell’host: alcuni propongono un test di connessione o una pagina di stato MySQL.
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Se phpMyAdmin mostra un errore di autenticazione, siete di fronte a una coppia user/password errata, a un user senza permessi, o a un database inesistente. Se phpMyAdmin non si carica o impiega moltissimo tempo, il servizio potrebbe essere guasto o saturo.
Fase 4: verificare lo stato del server (guasto, sovraccarico, limiti)
Quando le credenziali sono corrette, l’errore appare spesso durante un’indisponibilità temporanea: riavvio di MySQL, manutenzione, sovraccarico CPU/RAM, troppe connessioni simultanee, disco pieno, o limite di processi raggiunto su un hosting condiviso.
Segni indicativi:
– Il problema si verifica all’improvviso senza modifiche recenti.
– Il sito torna da solo dopo alcuni minuti, poi ricade.
– Anche altri siti sullo stesso hosting sono coinvolti.
– Le pagine impiegano molto tempo e poi finiscono in errore.
In questo scenario, verificate lo stato dell’host, gli incidenti in corso e le metriche se avete accesso (CPU, RAM, I/O, numero di connessioni). Un’ottimizzazione o il passaggio a un’offerta più robusta può essere necessario se l’errore si ripresenta regolarmente.
Fase 5: attivare una diagnosi corretta (senza aggravare il guasto)
Se potete modificare wp-config.php, potete attivare temporaneamente il debug per ottenere indizi (da usare con cautela in produzione). L’obiettivo non è mostrare dettagli ai visitatori, ma registrare gli errori.
In pratica, si preferisce attivare un log (file) piuttosto che la visualizzazione. Una volta raccolte le informazioni, ripristinate i parametri iniziali per evitare qualsiasi fuga di informazioni.
Oltre al debug, pensate anche ai log del server (error_log, log PHP-FPM, log MySQL se disponibili). Un errore Too many connections o Access denied orienterà immediatamente la diagnosi.
Fase 6: riparare un database potenzialmente corrotto
Una corruzione delle tabelle (spesso dopo un crash, un disco saturo, un’interruzione, o un problema hardware) può provocare errori di connessione o comportamenti simili. WordPress propone una modalità di riparazione, e MySQL propone anche strumenti (a seconda dell’accesso).
Riparazione tramite WordPress (opzione integrata)
WordPress può avviare una riparazione delle tabelle se si attiva un parametro specifico in wp-config.php. Questo può risolvere tabelle contrassegnate come crashed . Importante: disattivate questa opzione non appena la riparazione è terminata.
Riparazione tramite phpMyAdmin
In phpMyAdmin, potete selezionare tutte le tabelle e avviare Ripara la tabella . Se più tabelle sono danneggiate, questo può essere sufficiente per rimettere il sito online.
Per un approccio più ampio (e scenari avanzati), questa guida è utile: Correggere Errore di connessione al database ? Esplora le cause comuni, i controlli lato server e le piste quando le soluzioni semplici non bastano.
Passaggio 7: isolare un conflitto plugin/tema (quando il server DB sembra OK)
Un plugin o un tema può scatenare una tempesta di query, aprire troppe connessioni o provocare errori fatali che sembrano un problema DB (ad esempio, timeout ripetuti che finiscono per far cadere MySQL su un piccolo server). Anche se il messaggio parla di database, la causa iniziale può essere applicativa.
Testare senza rompere: metodo consigliato
Se avete un ambiente di staging, riproducete il problema e disattivate gli elementi uno a uno. In produzione, fatelo solo se siete sicuri di poter tornare indietro rapidamente (backup, accesso FTP/SSH, ecc.).
Per un approccio prudente prima di aggiungere o modificare estensioni, potete basarvi su un protocollo di test prima della messa in produzione, per ridurre drasticamente gli incidenti che finiscono per impattare il database.
Eliminare o sostituire le estensioni a rischio
I plugin obsoleti o abbandonati possono generare query inefficienti, errori SQL o incompatibilità con una versione recente di PHP/MySQL. Col tempo, questo indebolisce l’insieme, soprattutto se il vostro server ha risorse limitate.
Se dovete fare pulizia, seguite una procedura controllata: backup, disattivazione, verifica delle dipendenze, rimozione, poi osservazione. A questo proposito, ecco una risorsa interna utile: un metodo per rimuovere correttamente estensioni vecchie.
Passaggio 8: verificare i prefissi delle tabelle e la coerenza dopo la migrazione
Dopo una migrazione o un ripristino, può capitare che il prefisso delle tabelle non corrisponda più a quello dichiarato in wp-config.php. WordPress cerca quindi tabelle che non esistono, il che può essere interpretato come un problema del database (o portare a errori correlati).
In wp-config.php, la variabile $table_prefix deve corrispondere esattamente alle tabelle presenti (ad esempio wp_, wp123_, ecc.). Verificate in phpMyAdmin: se le vostre tabelle iniziano con wpabc_ ma il file indica wp_, correggete uno dei due (in genere si corregge il file, salvo strategia specifica).
Passo 9: assicurarsi che il database esista e che l’utente abbia i diritti
A volte il database è stato eliminato (errore umano), rinominato o ripristinato con un altro nome. Altre volte, l’utente MySQL esiste, ma non ha i privilegi sul database (GRANT mancante, utente ricreato, diritti reimpostati dall’host, ecc.).
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
In phpMyAdmin o nel pannello dell’host, controllate:
– che il database elencato corrisponda a DB_NAME ;
– che l’utente DB_USER sia effettivamente associato a questo database;
– che disponga dei diritti necessari (al minimo SELECT/INSERT/UPDATE/DELETE/CREATE/ALTER a seconda delle operazioni di WordPress).
Passo 10: distinguere l’incidente puntuale dal problema strutturale
Se l’errore si verifica una volta e poi scompare, è plausibile una manutenzione o un riavvio del DB lato hosting. Al contrario, se torna (soprattutto durante i picchi di traffico), bisogna affrontare la causa strutturale: server sottodimensionato, query pesanti, assenza di cache, cron che impazzisce, ricerca interna costosa, o estensione troppo esigente.
Un piano d’azione pragmatico:
– Implementare una strategia di cache adeguata (page cache, object cache a seconda del contesto).
– Ridurre le query costose (plugin di statistiche pesanti, ricerca, filtri complessi).
– Verificare le attività pianificate (WP-Cron) e le automazioni esterne.
– Ottimizzare il database (pulizia revisioni, transients, tabelle dei plugin).
– Aumentare le risorse se necessario.
Per evitare di correggere alla cieca, potete anche analizzare le cause ricorrenti di lentezza che finiscono per mandare in crash MySQL sulle configurazioni piccole: Gli Errori di Performance più Frequenti.
Passaggio 11: prendere in considerazione la sicurezza (intrusione, iniezione, account compromessi)
Un database inaccessibile può anche essere la conseguenza di un incidente di sicurezza: password del DB modificata, file alterati, creazione di backdoor, o query malevole che saturano il server. Non è lo scenario più comune, ma diventa probabile se osservate anche: reindirizzamenti sconosciuti, nuovi account admin, file modificati di recente, o avvisi dell’host.
In caso di dubbio, adottate un approccio da incidente: cambio delle password (FTP/SSH, database, WordPress), verifica dell’integrità dei file, scan, audit degli account, ispezione dei log. Una checklist strutturata aiuta a non dimenticare nulla: Audit di Sicurezza Cosa Verificare Assolutamente.
Passaggio 12: quando chiedere aiuto (e a chi)
Se avete verificato wp-config.php, testato l’accesso MySQL e controllato i permessi senza risultato, è il momento di coinvolgere l’host o un team tecnico. L’host potrà confermare: guasto MySQL, limite di connessioni, incidente disco, ripristino necessario, o cambio di endpoint.
In aggiunta, la comunità WordPress francofona può aiutare a interpretare i sintomi e proporre piste in base al vostro contesto: Problema « errore durante la connessione al database ».
Prevenire la ricaduta: backup, aggiornamenti, monitoraggio
Riparare è una cosa, evitare che torni è un’altra. Le migliori protezioni contro questo tipo di guasto sono generalmente poco glamour, ma molto efficaci: backup automatici testati, aggiornamenti regolari, monitoraggio dell’uptime e controllo delle risorse (CPU/RAM/IO) per anticipare la saturazione.
È anche utile mettere in atto delle routine: verificare lo stato del database, pulire le tabelle lasciate dai plugin, monitorare i log degli errori e mantenere una tracciabilità delle modifiche (chi ha fatto cosa, quando).
Per arbitrarsi tra il costo di un approccio preventivo e quello di un guasto (perdita di fatturato, SEO, fiducia), questa analisi aiuta a inquadrare la decisione: Manutenzione Costo vs Rischi.
Piano d’azione express (riepilogo)
1) Confermare l’estensione: front + admin, e annotare il contesto (aggiornamento, migrazione, picco).
2) Verificare DB_NAME/DB_USER/DB_PASSWORD/DB_HOST in wp-config.php.
3) Testare la connessione MySQL tramite phpMyAdmin/SSH, e controllare l’esistenza del database.
4) Verificare i diritti dell’utente sul database.
5) Controllare lo stato del server (guasto, limiti, too many connections , disco).
6) Valutare una riparazione delle tabelle se si sospetta corruzione.
7) Isolare un plugin/tema esigente se il database è OK ma il sito crolla sotto carico.
8) Rafforzare la prevenzione: backup, supervisione, ottimizzazione, sicurezza.
Quando esternalizzare: risparmiare tempo senza correre rischi
Se il vostro sito è critico (e-commerce, generazione di lead, media), ogni minuto di indisponibilità conta. In questo caso, delegare la diagnosi e la prevenzione a un team abituato a gestire questo tipo di incidente evita correzioni azzardate e riduce il tempo di ripristino.
Per una presa in carico ricorrente (aggiornamenti, backup, monitoraggio, correzioni), potete consultare Per saperne di più sui nostri servizi di manutenzione del sito.
