Errore nello stabilire una connessione al database in WordPress: come risolverlo

Carichi il tuo sito e ogni pagina — sia la parte pubblica sia wp-admin — viene sostituita da una sola frase grigia: Errore nello stabilire una connessione con il database. Non viene visualizzato nulla, perché nulla può esserlo. WordPress non è nemmeno arrivato a costruire una pagina.

Ecco il modello mentale che rende la correzione rapida. WordPress conserva tutti i tuoi contenuti — articoli, pagine, impostazioni, utenti — in un database MySQL, non in file. A ogni richiesta legge quattro credenziali da wp-config.php, si connette a quel database ed estrae ciò che gli serve. Questo errore significa che quella connessione è stata tentata e rifiutata. La soluzione consiste nel capire perché è stata rifiutata, e ci sono solo tre possibilità.

Le tre cause, in ordine di probabilità

1. Una credenziale sbagliata in wp-config.php: il risultato tipico di un cambio di hosting.
2. Il server del database è offline o sovraccarico: il risultato tipico del fatto che non hai cambiato nulla dalla tua parte.
3. Il database è danneggiato: meno comune, e si manifesta in modo diverso.

Affrontale in quest’ordine.

Passaggio 1: controlla le quattro credenziali

Apri wp-config.php nella radice del tuo sito via SFTP o con il gestore file del tuo hosting. Quattro righe definiscono la connessione:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Ognuna di queste deve corrispondere esattamente a ciò che ti ha assegnato il tuo hosting. Apri la sezione database del pannello di controllo del tuo hosting (in cPanel è “MySQL Databases”) e confronta carattere per carattere:

• DB_NAME: gli hosting spesso antepongono al nome quello del tuo account, come cpaneluser_wpdb. Il prefisso fa parte del nome.
• DB_USER: si applica lo stesso prefisso, e l’utente deve essere assegnato a quel database, non solo esistere.
• DB_PASSWORD: il colpevole più comune in assoluto. In caso di dubbio, reimpostala nel pannello di controllo e incolla il nuovo valore. Attenzione a uno spazio finale o a una virgoletta tipografica.
• DB_HOST: non dare per scontato localhost. Molti hosting usano un server di database dedicato con un indirizzo come mysql.yourhost.com, a volte con un :port. Il pannello di controllo mostra il valore corretto.

Poiché questo file è proprio dove risiedono questi quattro valori, il modo più sicuro per rigenerare un wp-config.php pulito e con le virgolette corrette è il generatore di wp-config.php: compila i quattro campi del database e incolla il risultato sul vecchio blocco.

Questo passaggio da solo corregge l’errore dopo quasi ogni migrazione, perché credenziali che erano corrette sul vecchio hosting sono sbagliate su quello nuovo.

Passaggio 2: verifica che il server del database sia davvero attivo

Se le credenziali sono corrette e l’errore persiste — soprattutto se è comparso da solo, senza alcun cambiamento da parte tua — il sospettato è il server del database stesso.

Sull’hosting condiviso questo è comune e di solito temporaneo: il servizio MySQL viene sovraccaricato durante un picco di traffico o raggiunge il limite di connessioni per account e inizia a rifiutare le nuove connessioni. Di norma si riprende nel giro di pochi minuti. Ricarica dopo una breve attesa prima di fare qualcosa di drastico.

Per verificare se le credenziali sono valide indipendentemente da WordPress, lascia un piccolo script accanto a wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Usa i tuoi veri DB_HOST, DB_USER e DB_PASSWORD. Se stampa Connected, le tue credenziali funzionano e il problema è altrove (un database danneggiato, passaggio 3). Se stampa un errore di connessione, il messaggio ti dice quale: “Access denied” significa utente o password sbagliati; “Can’t connect to MySQL server” significa host sbagliato o servizio davvero offline — è il momento di contattare il tuo hosting. Elimina lo script nel momento in cui hai finito.

Passaggio 3: ripara un database danneggiato

Un indizio distingue il danneggiamento da un problema di connessione: la parte pubblica si carica ma wp-admin mostra l’errore, o viceversa. Se la connessione fosse davvero rifiutata, entrambe sarebbero fuori uso. Una differenza del genere indica tabelle danneggiate.

WordPress dispone di uno strumento di riparazione integrato. Aggiungi una riga a wp-config.php, sopra il commento “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Poi visita direttamente questa URL nel tuo browser:

https://yoursite.com/wp-admin/maint/repair.php

Si carica senza login — è proprio questo il punto, dato che potresti essere bloccato fuori — e offre “Repair Database” e “Repair and Optimize Database”. Eseguila.

Poi elimina immediatamente quella riga da wp-config.php. Finché è presente, chiunque su internet può raggiungere quella URL ed eseguire una riparazione del tuo database. Questa non è una pulizia facoltativa; è chiudere una falla che hai appena aperto.

Passaggio 4: quando la riparazione non riesce nemmeno a connettersi

Se la pagina di riparazione stessa mostra l’errore di connessione, non c’è nulla da riparare — il database non è raggiungibile affatto, quindi sei di nuovo al passaggio 1 o al passaggio 2. A quel punto la mossa affidabile è ripristinare il database dal backup più recente del tuo hosting. La maggior parte dei pannelli di controllo conserva istantanee giornaliere automatiche del database; un ripristino di ieri sera è quasi sempre più rapido e sicuro che rincorrere un danneggiamento a cui non riesci a connetterti.

Consigli che puoi tranquillamente ignorare

“Reinstalla e basta WordPress”. Questo errore riguarda la connessione al database, non i file del core. Reinstallare sostituisce proprio i file che funzionano bene e non tocca nulla di ciò che è rotto.

“Aumenta il limite di memoria di PHP”. L’esaurimento della memoria è un errore diverso, con un messaggio diverso. Aumentare il limite non fa nulla per una connessione al database rifiutata e serve solo a nascondere il fatto che non hai mai controllato le credenziali.

“Svuota la cache”. L’errore si verifica in PHP prima che una qualsiasi cache possa servire una pagina. Svuotare la cache non cambia nulla finché la connessione è rifiutata; vale la pena farlo solo dopo che il sito è tornato online.

“Modifica direttamente il database per sistemarlo”. Ricorrere a phpMyAdmin per modificare le tabelle a mano prima di aver confermato che la connessione funziona è il modo in cui un’interruzione temporanea diventa una perdita di dati permanente. Conferma prima la connessione; tocca i dati per ultimo, e solo da un backup.

Ancora bloccato?

Se le credenziali si verificano con lo script di prova, il server è attivo, e la riparazione si connette e non segnala errori, ma il sito mostra ancora il messaggio, il sospettato che resta è un plugin che parla al database tramite una propria connessione — un plugin di cache o di database che ha memorizzato un host obsoleto. Rinomina wp-content/plugins in plugins-off via SFTP per escluderlo. Se l’errore sparisce, reintroduci i plugin uno alla volta finché non ritorna.