Błąd łączenia się z bazą danych WordPress – jak go naprawić?

Błąd łączenia się z bazą danych WordPress oznacza, że aplikacja nie może skomunikować się z serwerem MySQL. Najczęściej winne są nieaktualne dane w pliku wp-config.php, uszkodzona baza albo chwilowa awaria hostingu. Zanim zmienisz pliki, wykonaj kopię zapasową – dzięki temu łatwiej cofniesz błędną modyfikację.

Dlaczego strona nie działa?

WordPress pobiera z bazy danych treści, ustawienia, informacje o użytkownikach i konfigurację witryny. Baza jest więc magazynem, z którego system korzysta przy każdym wyświetleniu strony. Gdy połączenie nie zostanie nawiązane, WordPress nie ma dostępu do danych potrzebnych do wygenerowania witryny ani panelu administracyjnego.

Najczęstsze objawy to biały ekran, komunikat „Błąd łączenia się z bazą danych” albo jego angielski odpowiednik „Error establishing a database connection”. Problem zwykle da się rozwiązać bez zaawansowanej wiedzy, jeśli diagnostykę przeprowadzisz po kolei.

Jeśli widzisz któryś z poniższych objawów, nie edytuj przypadkowych plików. Najpierw ustal, co zmieniło się tuż przed awarią:

• strona główna i podstrony wyświetlają komunikat o błędzie,
• panel administracyjny WordPressa również jest niedostępny,
• pojawia się biały ekran zamiast treści,
• problem wystąpił po zmianie hasła, aktualizacji lub przeniesieniu strony.

Co mogło spowodować błąd?

Ostatnie działanie wykonane na stronie często wskazuje kierunek poszukiwań. Poniższa tabela pomaga wybrać pierwszy krok:

Jak naprawić błąd krok po kroku?

Przed rozpoczęciem pobierz kopię plików strony i bazy danych. Zachowaj też oryginalny plik wp-config.php na komputerze. Edycja bez kopii może utrudnić późniejszy powrót do działającej konfiguracji.

1. Sprawdź dane w wp-config.php – połącz się z serwerem przez FTP lub menedżer plików hostingu. Plik zwykle znajduje się w katalogu instalacji WordPressa, często w lokalizacji public_html. Odnajdź fragment podobny do poniższego:

   define( 'DB_NAME', 'nazwa_bazy_danych' );
   define( 'DB_USER', 'nazwa_uzytkownika' );
   define( 'DB_PASSWORD', 'haslo_do_bazy' );
   define( 'DB_HOST', 'localhost' );

   Porównaj nazwę bazy, użytkownika i hasło z informacjami w panelu hostingu. Zwróć uwagę na wielkość liter, podkreślenia i dodatkowe znaki.

2. Zweryfikuj DB_HOST – localhost jest częstą wartością, ale nie obowiązuje na każdym serwerze. Dostawca może wymagać innego adresu, na przykład nazwy hosta lub adresu z portem. Skopiuj właściwą wartość z panelu bazy danych. Nie wpisuj jej na podstawie domysłu.
3. Sprawdź bazę w phpMyAdmin – spróbuj zalogować się tym samym użytkownikiem i hasłem. Jeśli logowanie nie działa, dane są niepoprawne albo konto nie ma dostępu do bazy. Możesz ustawić nowe hasło w panelu hostingu, a następnie wpisać je w wp-config.php. Jeśli phpMyAdmin działa, serwer MySQL najpewniej odpowiada, więc skup się na konfiguracji WordPressa lub stanie tabel.
4. Włącz narzędzie naprawcze WordPressa – po wykonaniu kopii zapasowej dodaj w wp-config.php, przed komentarzem kończącym edycję pliku, następującą linię:

   define( 'WP_ALLOW_REPAIR', true );

   Otwórz adres https://twojadomena.pl/wp-admin/maint/repair.php i wybierz naprawę bazy. Narzędzie może naprawić uszkodzone tabele, ale nie zastępuje backupu. Po zakończeniu usuń dodaną linię. Pozostawienie strony naprawczej aktywnej umożliwia dostęp do narzędzia bez standardowego logowania.

5. Wyłącz ostatnio zmienione wtyczki – przez FTP przejdź do katalogu wp-content/plugins i zmień nazwę folderu podejrzanej wtyczki, na przykład z nazwa-wtyczki na nazwa-wtyczki.old. WordPress przestanie ją ładować. Jeśli nie znasz winowajcy, możesz tymczasowo zmienić nazwę całego katalogu plugins, a potem przywracać wtyczki pojedynczo.

Przykładowy fragment konfiguracji powinien zawierać wyłącznie rzeczywiste dane z panelu hostingu. Nie kopiuj bezpośrednio wartości pokazanych w przykładzie do swojej witryny.

Jeśli narzędzie naprawcze nie pomoże, a problem pojawił się po modyfikacji plików, przywróć działającą kopię zapasową plików oraz bazy. Przywrócenie tylko jednej części może pozostawić niespójność między kodem strony a zapisanymi danymi.

Co zrobić, gdy podstawowe kroki nie pomogły?

Jeżeli dane w wp-config.php są poprawne, a phpMyAdmin nie działa lub zwraca komunikat serwera, przyczyna może leżeć po stronie hostingu. Sprawdź komunikaty o awarii, przerwie technicznej i przekroczeniu limitów. Współdzielone serwery mogą odrzucać nowe połączenia przy dużym obciążeniu.

W logach mogą pojawić się komunikaty ułatwiające diagnozę:

1. Access denied for user oznacza zwykle błędne dane logowania albo brak uprawnień użytkownika.
2. Can’t connect to MySQL server wskazuje na niedostępny serwer, niepoprawny host lub blokadę połączenia.
3. Too many connections sugeruje przekroczenie limitu jednoczesnych połączeń.
4. Timeout może oznaczać przeciążenie serwera lub zbyt długi czas odpowiedzi bazy.

Jeśli hosting potwierdza, że MySQL działa, poproś o sprawdzenie logów, uprawnień użytkownika, limitów połączeń i stanu konkretnej bazy. Gdy awaria zaczęła się po aktualizacji, przetestuj także motyw i wtyczki. Nie twórz publicznego pliku PHP do testowania połączenia, jeśli nie potrafisz go później usunąć, ponieważ mógłby ujawnić wrażliwe informacje.

Co sprawdzić po naprawie?

Po przywróceniu strony wykonaj krótką kontrolę bezpieczeństwa:

• usuń z wp-config.php linię define( 'WP_ALLOW_REPAIR', true );,
• przywróć prawidłowe nazwy katalogów wtyczek i motywów, jeśli zmieniałeś je przez FTP,
• sprawdź i przywróć właściwe uprawnienia plików oraz katalogów,
• wykonaj nową kopię zapasową plików i bazy danych,
• sprawdź stronę, panel administracyjny i najważniejsze formularze.

Najpierw sprawdź wp-config.php, potem dostęp do bazy w phpMyAdmin, a dopiero później uruchamiaj naprawę tabel. Jeśli żaden etap nie przyniesie rezultatu, dalsze działania powinien przeprowadzić hosting lub administrator mający dostęp do logów serwera.