Eroare la conectarea bazei de date în WordPress: cum o rezolvi

Îți încarci situl și fiecare pagină — și partea publică, și wp-admin — este înlocuită de o singură propoziție gri: Eroare la stabilirea conexiunii cu baza de date. Nu se afișează nimic, pentru că nu se poate. WordPress nici măcar nu a ajuns până la construirea unei pagini.

Iată modelul mental care face reparația rapidă. WordPress ține tot conținutul tău — articole, pagini, setări, utilizatori — într-o bază de date MySQL, nu în fișiere. La fiecare cerere citește patru date de acces din wp-config.php, se conectează la acea bază și extrage ce îi trebuie. Această eroare înseamnă că acea conexiune a fost încercată și refuzată. Rezolvarea este să afli de ce a fost refuzată, iar posibilitățile sunt doar trei.

Cele trei cauze, în ordinea probabilității

1. O dată de acces greșită în wp-config.php — de obicei rezultatul unei mutări între găzduiri.
2. Serverul bazei de date este picat sau supraîncărcat — de obicei rezultatul faptului că nu s-a schimbat nimic la tine.
3. Baza de date este coruptă — mai rar, și se anunță altfel.

Parcurge-le în această ordine.

Pasul 1: verifică cele patru date de acces

Deschide wp-config.php în rădăcina sitului prin SFTP sau prin managerul de fișiere al găzduirii. Patru linii definesc conexiunea:

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

Fiecare dintre acestea trebuie să corespundă exact cu ce ți-a alocat găzduirea. Deschide secțiunea de baze de date din panoul de găzduire (în cPanel se numește „Baze de date MySQL”) și compară caracter cu caracter:

• DB_NAME — găzduirile pun adesea contul tău ca prefix la nume, precum cpaneluser_wpdb. Prefixul face parte din nume.
• DB_USER — se aplică același prefix, iar utilizatorul trebuie să fie atribuit acelei baze, nu doar să existe.
• DB_PASSWORD — de departe cel mai frecvent vinovat. Dacă nu ești sigur, resetează-l în panou și lipește noua valoare. Fii atent la un spațiu la final sau la o ghilimea tipografică.
• DB_HOST — nu presupune localhost. Multe găzduiri folosesc un server de baze de date dedicat, cu o adresă precum mysql.yourhost.com, uneori cu :port. Panoul arată valoarea corectă.

Fiindcă exact în acest fișier trăiesc aceste patru valori, cea mai sigură cale de a regenera un wp-config.php curat și corect încadrat în ghilimele este generatorul wp-config.php — completează cele patru câmpuri ale bazei de date și lipește rezultatul peste blocul vechi.

Numai acest pas rezolvă eroarea după aproape orice migrare, fiindcă datele de acces care erau corecte pe vechea găzduire sunt greșite pe cea nouă.

Pasul 2: confirmă că serverul bazei de date chiar funcționează

Dacă datele de acces sunt corecte și eroarea persistă — mai ales dacă a apărut de la sine, fără vreo schimbare din partea ta — suspectul este chiar serverul bazei de date.

Pe găzduirea partajată acest lucru e frecvent și de obicei temporar: serviciul MySQL este copleșit într-un vârf de trafic sau își atinge limita de conexiuni pe cont și începe să refuze conexiuni noi. De regulă își revine în câteva minute. Reîncarcă după o scurtă așteptare înainte să faci ceva drastic.

Ca să testezi dacă datele de acces sunt măcar valide, independent de WordPress, pune un script minuscul lângă 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.';

Folosește DB_HOST, DB_USER și DB_PASSWORD reale. Dacă afișează Connected, datele tale de acces funcționează și problema e în altă parte (o bază de date coruptă, pasul 3). Dacă afișează o eroare de conexiune, mesajul îți spune care: „Access denied” înseamnă un utilizator sau o parolă greșită; „Can’t connect to MySQL server” înseamnă un host greșit sau un serviciu chiar picat — e momentul să contactezi găzduirea. Șterge scriptul imediat ce ai terminat.

Pasul 3: repară o bază de date coruptă

Un singur semn desparte corupția de o problemă de conexiune: partea publică se încarcă, dar wp-admin arată eroarea, sau invers. Dacă conexiunea ar fi cu adevărat refuzată, ambele ar fi moarte. Un astfel de decalaj indică tabele deteriorate.

WordPress are un instrument de reparare încorporat. Adaugă o linie în wp-config.php, deasupra comentariului „stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Apoi accesează direct această adresă în browser:

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

Se încarcă fără autentificare — asta e ideea, fiindcă s-ar putea să fii blocat afară — și oferă „Repară baza de date” și „Repară și optimizează baza de date”. Rulează reparația.

Apoi șterge imediat acea linie din wp-config.php. Cât timp există, oricine de pe internet poate accesa acea adresă și rula o reparație pe baza ta de date. Nu este o curățenie opțională; este astuparea unei găuri pe care tocmai ai deschis-o.

Pasul 4: când reparația nici măcar nu se conectează

Dacă pagina de reparație însăși arată eroarea de conexiune, nu ai ce repara — baza de date nu poate fi atinsă deloc, așa că te întorci la pasul 1 sau 2. În acel punct, mișcarea sigură este să restaurezi baza din cea mai recentă copie de rezervă a găzduirii. Majoritatea panourilor păstrează instantanee zilnice automate ale bazei; o restaurare de aseară este aproape întotdeauna mai rapidă și mai sigură decât să urmărești o corupție la care nu te poți conecta.

Sfaturi pe care le poți ignora liniștit

„Pur și simplu reinstalează WordPress.” Această eroare ține de conexiunea la baza de date, nu de fișierele de nucleu. Reinstalarea înlocuiește chiar fișierele care funcționează bine și nu atinge nimic din ce este stricat.

„Mărește limita de memorie PHP.” Epuizarea memoriei este o altă eroare, cu alt mesaj. Ridicarea limitei nu face nimic pentru o conexiune la baza de date refuzată și doar ascunde faptul că nu ai verificat niciodată datele de acces.

„Golește memoria cache.” Eșecul se produce în PHP înainte ca vreun cache să poată servi o pagină. Golirea cache-ului nu schimbă nimic cât timp conexiunea este refuzată; merită făcută abia după ce situl revine.

„Editează baza de date direct ca s-o repari.” Să apelezi la phpMyAdmin ca să editezi tabele manual înainte să confirmi că măcar conexiunea funcționează este modul în care o pană temporară devine pierdere permanentă de date. Confirmă întâi conexiunea; atinge datele la final și doar dintr-o copie de rezervă.

Tot blocat?

Dacă datele de acces se confirmă cu scriptul de test, serverul funcționează, iar reparația se conectează și nu raportează erori, dar situl încă arată mesajul, suspectul rămas este un modul care vorbește cu baza pe propria conexiune — un modul de cache sau de baze de date care a stocat un host învechit. Redenumește wp-content/plugins în plugins-off prin SFTP ca să-l excluzi. Dacă eroarea dispare, reintrodu modulele unul câte unul până revine.