Błąd połączenia z bazą danych w WordPressie: jak go usunąć

Ładujesz witrynę i każda strona — zarówno front, jak i wp-admin — jest zastąpiona jednym szarym zdaniem: Błąd nawiązywania połączenia z bazą danych. Nic się nie wyświetla, bo nie może. WordPress nie doszedł nawet do budowania strony.

Oto model myślowy, dzięki któremu naprawa idzie szybko. WordPress trzyma całą twoją treść — wpisy, strony, ustawienia, użytkowników — w bazie danych MySQL, a nie w plikach. Przy każdym żądaniu odczytuje cztery dane logowania z wp-config.php, łączy się z tą bazą i pobiera, czego potrzebuje. Ten błąd oznacza, że połączenie zostało podjęte i odrzucone. Naprawa polega na ustaleniu, dlaczego zostało odrzucone, a możliwości są tylko trzy.

Trzy przyczyny, od najbardziej prawdopodobnej

1. Błędne dane logowania w wp-config.php — zwykle skutek przenosin między hostingami.
2. Serwer bazy danych jest wyłączony lub przeciążony — zwykle skutek tego, że nic nie zmieniłeś po swojej stronie.
3. Baza danych jest uszkodzona — rzadziej, i zapowiada się inaczej.

Przejdź przez nie w tej kolejności.

Krok 1: sprawdź cztery dane logowania

Otwórz wp-config.php w katalogu głównym witryny przez SFTP albo menedżer plików hostingu. Połączenie definiują cztery linie:

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

Każda z nich musi dokładnie odpowiadać temu, co przydzielił hosting. Otwórz sekcję bazy danych w panelu hostingu (w cPanel to „Bazy danych MySQL”) i porównaj znak po znaku:

• DB_NAME — hostingi często poprzedzają nazwę twoim kontem, jak cpaneluser_wpdb. Przedrostek jest częścią nazwy.
• DB_USER — obowiązuje ten sam przedrostek, a użytkownik musi być przypisany do tej bazy, nie tylko istnieć.
• DB_PASSWORD — zdecydowanie najczęstszy winowajca. Jeśli nie masz pewności, zresetuj je w panelu i wklej nową wartość. Uważaj na spację na końcu albo na „inteligentny” cudzysłów.
• DB_HOST — nie zakładaj localhost. Wiele hostingów używa dedykowanego serwera bazy z adresem w rodzaju mysql.yourhost.com, czasem z :port. Panel pokazuje właściwą wartość.

Ponieważ to właśnie w tym pliku żyją te cztery wartości, najbezpieczniejszym sposobem na wygenerowanie czystej, poprawnie sformatowanej wp-config.php jest generator wp-config.php — wypełnij cztery pola bazy danych i wklej wynik w miejsce starego bloku.

Sam ten krok naprawia błąd po niemal każdej migracji, bo dane logowania, które były poprawne na starym hostingu, na nowym są błędne.

Krok 2: potwierdź, że serwer bazy danych naprawdę działa

Jeśli dane logowania są poprawne, a błąd nie ustępuje — zwłaszcza gdy pojawił się sam, bez żadnej zmiany z twojej strony — podejrzanym jest sam serwer bazy danych.

Na hostingu współdzielonym to częste i zwykle przejściowe: usługa MySQL zostaje przeciążona przy skoku ruchu albo osiąga limit połączeń na konto i zaczyna odrzucać nowe połączenia. Zwykle wraca do siebie w ciągu kilku minut. Odśwież po krótkiej chwili, zanim zrobisz coś drastycznego.

Żeby sprawdzić, czy dane logowania są w ogóle ważne, niezależnie od WordPressa, połóż maleńki skrypt obok 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.';

Użyj swoich prawdziwych DB_HOST, DB_USER i DB_PASSWORD. Jeśli wypisze Connected, twoje dane logowania działają, a problem jest gdzie indziej (uszkodzona baza, krok 3). Jeśli wypisze błąd połączenia, komunikat mówi który: „Access denied” oznacza błędnego użytkownika lub hasło; „Can’t connect to MySQL server” oznacza błędny host albo faktycznie wyłączoną usługę — czas skontaktować się z hostingiem. Usuń skrypt, gdy tylko skończysz.

Krok 3: napraw uszkodzoną bazę danych

Jeden objaw odróżnia uszkodzenie od problemu z połączeniem: front się ładuje, ale wp-admin pokazuje błąd, albo odwrotnie. Gdyby połączenie było naprawdę odrzucone, oba byłyby martwe. Taki rozdźwięk wskazuje na uszkodzone tabele.

WordPress ma wbudowane narzędzie naprawcze. Dodaj jedną linię do wp-config.php, powyżej komentarza „stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Potem wejdź bezpośrednio pod ten adres w przeglądarce:

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

Ładuje się bez logowania — o to właśnie chodzi, bo możesz być zablokowany — i oferuje „Napraw bazę danych” oraz „Napraw i zoptymalizuj bazę danych”. Uruchom naprawę.

Potem natychmiast usuń tę linię z wp-config.php. Dopóki tam jest, każdy w internecie może wejść pod ten adres i uruchomić naprawę twojej bazy. To nie opcjonalne sprzątanie; to zamknięcie dziury, którą właśnie otworzyłeś.

Krok 4: gdy naprawa w ogóle się nie łączy

Jeśli sama strona naprawy pokazuje błąd połączenia, nie ma czego naprawiać — bazy w ogóle nie da się osiągnąć, więc wracasz do kroku 1 lub 2. W tym momencie pewnym ruchem jest przywrócenie bazy z najnowszej kopii zapasowej u hostingu. Większość paneli trzyma automatyczne codzienne migawki bazy; przywrócenie z wczorajszej nocy jest niemal zawsze szybsze i bezpieczniejsze niż gonienie za uszkodzeniem, z którym nie potrafisz się połączyć.

Rady, które możesz spokojnie zignorować

„Po prostu zainstaluj WordPressa od nowa.” Ten błąd dotyczy połączenia z bazą, nie plików rdzenia. Ponowna instalacja podmienia właśnie te pliki, które działają bez zarzutu, i nie rusza niczego, co jest zepsute.

„Zwiększ limit pamięci PHP.” Wyczerpanie pamięci to inny błąd z innym komunikatem. Podniesienie limitu nic nie da przy odrzuconym połączeniu z bazą i tylko przykrywa fakt, że nigdy nie sprawdziłeś danych logowania.

„Wyczyść pamięć podręczną.” Awaria następuje w PHP, zanim cache zdąży podać jakąkolwiek stronę. Czyszczenie cache nic nie zmienia, dopóki połączenie jest odrzucane; warto to zrobić dopiero po tym, jak witryna wróci.

„Popraw to, edytując bazę wprost.” Sięganie po phpMyAdmin, żeby ręcznie edytować tabele, zanim potwierdzisz, że połączenie w ogóle działa, to sposób, w jaki chwilowa awaria zmienia się w trwałą utratę danych. Najpierw potwierdź połączenie; dane ruszaj na końcu i tylko z kopii zapasowej.

Nadal nie działa?

Jeśli dane logowania potwierdzają się skryptem testowym, serwer działa, a naprawa łączy się i nie zgłasza błędów, ale witryna wciąż pokazuje komunikat, pozostałym podejrzanym jest wtyczka, która rozmawia z bazą po własnym połączeniu — wtyczka cache lub bazodanowa, która zapamiętała nieaktualny host. Zmień nazwę wp-content/plugins na plugins-off przez SFTP, żeby to wykluczyć. Jeśli błąd zniknie, wprowadzaj wtyczki po jednej, aż wróci.