WordPress: błąd łączenia się z bazą danych

„Błąd łączenia się z bazą danych” oznacza, że WordPress nie może skomunikować się z serwerem MySQL. Najczęściej przyczyną są nieprawidłowe dane w pliku wp-config.php albo chwilowa awaria lub przeciążenie hostingu. Strona zwykle nie jest stracona, a podstawową diagnozę można przeprowadzić w kilka–kilkanaście minut.

Jak szybko rozpoznać przyczynę?

Dobierz pierwsze działanie do momentu, w którym pojawił się błąd. Jeśli wystąpił zaraz po zmianie hasła, migracji albo edycji plików, najpierw sprawdź konfigurację. Gdy strona przestała działać nagle, bez żadnych zmian, bardziej prawdopodobna jest awaria lub przeciążenie serwera.

Objaw lub sytuacja	Prawdopodobna przyczyna	Priorytet
Błąd pojawił się po zmianie hasła do bazy	Stare hasło w pliku wp-config.php	Sprawdź konfigurację
Błąd pojawił się po migracji strony	Nieaktualny DB_NAME, DB_USER lub DB_HOST	Sprawdź wszystkie dane
Strona przestała działać bez zmian	Awaria, przeciążenie albo przerwa techniczna hostingu	Sprawdź status usług
Nie można zalogować się do phpMyAdmin	Błędne dane, brak dostępu albo niedostępny serwer MySQL	Skontaktuj się z hostingiem
Problem występuje przy dużym ruchu	Przekroczony limit połączeń lub zapytań	Poproś hosting o analizę limitów

Krok 1: sprawdź plik wp-config.php

Plik wp-config.php znajduje się w głównym katalogu instalacji WordPressa, zwykle obok folderów wp-admin, wp-content i wp-includes. Możesz otworzyć go przez FTP albo menedżer plików w panelu hostingowym.

Przed edycją pobierz kopię pliku na komputer. Ręczna zmiana konfiguracji jest szybka, ale literówka lub błąd składni może spowodować kolejny problem.

Po wykonaniu kopii sprawdź kolejno cztery parametry:

DB_NAME – nazwa bazy danych utworzonej na serwerze.
DB_USER – nazwa użytkownika przypisanego do tej bazy.
DB_PASSWORD – aktualne hasło użytkownika bazy danych.
DB_HOST – adres serwera MySQL.

Fragment konfiguracji może wyglądać tak:

define( 'DB_NAME', 'nazwa_bazy' );
define( 'DB_USER', 'uzytkownik_bazy' );
define( 'DB_PASSWORD', 'haslo_bazy' );
define( 'DB_HOST', 'localhost' );

Porównaj te wartości z informacjami w panelu hostingu. Szczególną uwagę zwróć na podkreślenia, wielkość liter, dodatkowe spacje i znaki znajdujące się wewnątrz cudzysłowów. Jeśli niedawno zmieniano hasło użytkownika MySQL, wpisz do pliku nowe hasło. Samo ustawienie go w panelu hostingowym nie aktualizuje automatycznie wartości w WordPressie.

Wartość localhost często jest prawidłowa, ale nie działa na każdym serwerze. Niektórzy dostawcy wymagają konkretnego adresu, na przykład mysql.domena.pl, czasem wraz z portem. Właściwą wartość znajdziesz w szczegółach bazy danych albo uzyskasz od supportu.

Po zapisaniu pliku sprawdź, czy edytor nie zamienił zwykłych cudzysłowów na „inteligentne”. W kodzie PHP powinny pozostać zwykłe znaki cudzysłowu, a każda funkcja define() musi mieć poprawnie zamknięte nawiasy i średnik. Następnie prześlij plik na serwer i odśwież stronę.

Krok 2: sprawdź stan serwera MySQL

Jeśli dane w wp-config.php są poprawne, sprawdź, czy sama baza działa. Zaloguj się do phpMyAdmin przy użyciu danych przypisanych do bazy. Panele hostingowe mogą wyglądać różnie, dlatego nazwy sekcji zależą między innymi od tego, czy używasz cPanelu, DirectAdmin czy autorskiego panelu.

Zwróć uwagę na następujące sygnały:

Panel klienta pokazuje awarię lub przerwę techniczną usługi MySQL.
Logowanie do phpMyAdmin kończy się błędem dostępu.
Baza danych nie pojawia się na liście lub użytkownik nie jest do niej przypisany.
Hosting zgłasza przekroczenie limitu połączeń, zapytań albo zasobów.

Jeżeli phpMyAdmin również nie działa, nie zaczynaj od przypadkowej edycji plików WordPressa. Zgłoś hostingowi nazwę domeny, godzinę pojawienia się problemu oraz informację o ostatnich zmianach. Gdy dostawca potwierdzi awarię lub przeciążenie serwera, dalsze modyfikacje mogą tylko utrudnić diagnozę.

W instalacji lokalnej, na przykład w XAMPP, sprawdź osobno usługę MySQL. Uruchomienie samego Apache lub PHP nie wystarczy. W panelu XAMPP usługa MySQL powinna mieć status aktywny.

Krok 3: włącz tryb debugowania

Jeśli podstawowe testy nie wskazały przyczyny, włącz tymczasowo logowanie błędów w pliku wp-config.php. Wpisy dodaj przed komentarzem kończącym edycję pliku, jeśli taki znajduje się w konfiguracji:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WordPress zapisze szczegóły w pliku wp-content/debug.log. Komunikat taki jak „Access denied for user” zwykle wskazuje na błędne dane logowania. Informacja o przekroczeniu limitu połączeń lub zapytań sugeruje problem z zasobami hostingu. Log może też ujawnić błąd wtyczki albo motywu, który pojawił się po ostatniej aktualizacji.

Notatka ekspercka: po zakończeniu diagnozy wyłącz tryb debugowania albo pozostaw wyświetlanie błędów wyłączone. Szczegóły techniczne nie powinny być widoczne odwiedzającym stronę.

Co zrobić, gdy błąd nadal występuje?

Jeśli problem zaczął się po zmianie plików, instalacji wtyczki lub migracji, przywróć ostatnią działającą kopię zapasową. Odtworzenie powinno obejmować bazę danych i pliki, a nie tylko jeden przypadkowy element. Przed przywracaniem zachowaj kopię aktualnego stanu, aby można było wrócić do niego podczas dalszej analizy.

Możesz też tymczasowo wyłączyć ostatnio dodaną wtyczkę przez FTP, zmieniając nazwę jej katalogu w wp-content/plugins. Ta metoda ma sens tylko wtedy, gdy błąd pojawił się po konkretnej zmianie. Nie zastępuje sprawdzenia danych dostępowych ani stanu serwera.

Gdy wartości w konfiguracji są poprawne, phpMyAdmin działa, a strona nadal nie odpowiada, poproś hosting o sprawdzenie logów MySQL, uprawnień użytkownika i limitów konta. Dotyczy to szczególnie sytuacji, w której problem pojawia się tylko przy większym ruchu. Sam komunikat WordPressa nie rozróżnia błędnego hasła, niedostępnego serwera i przekroczenia limitu, dlatego potrzebne mogą być logi po stronie usługodawcy.

Lista kontrolna przed kontaktem z hostingiem

Przed zgłoszeniem problemu sprawdź, czy masz wykonane wszystkie podstawowe czynności:

Utworzyłeś kopię pliku wp-config.php przed edycją.
Porównałeś wartości DB_NAME, DB_USER, DB_PASSWORD i DB_HOST z panelem hostingu.
Sprawdziłeś, czy zwykłe cudzysłowy i składnia PHP pozostały bez zmian.
Przetestowałeś logowanie do bazy przez phpMyAdmin.
Sprawdziłeś status usługi MySQL i komunikaty o limitach.
Przypomniałeś sobie ostatnie zmiany oraz przygotowałeś godzinę wystąpienia błędu.
Wyłączyłeś tryb debugowania po zakończeniu diagnozy albo ukryłeś błędy przed użytkownikami.

Najczęściej rozwiązanie sprowadza się do poprawienia jednego parametru w wp-config.php albo potwierdzenia awarii po stronie hostingu. Jeśli konfiguracja jest poprawna, phpMyAdmin działa, a support nie wykrywa awarii, potrzebna będzie dokładniejsza analiza logów, uprawnień i ostatnich zmian w instalacji.