Zamiast strony firmowej w przeglądarce widać białą kartę z jednym zdaniem: „Błąd łączenia się z bazą danych”. Nie działa oferta, formularz ani sklep, a pod adresem kokpitu pojawia się ten sam napis. Dla właściciela firmy wygląda to groźnie, ale w zdecydowanej większości przypadków treść strony jest bezpieczna i czeka w bazie, do której WordPress chwilowo nie potrafi się dostać.
Ta instrukcja jest przeznaczona dla osób, które prowadzą firmę i same opiekują się stroną na WordPressie albo chcą rozumieć, co robi ich wykonawca. Opisuję w niej pięć przyczyn tego komunikatu: błędne dane w pliku wp-config.php, niedziałający lub przeciążony serwer bazy danych, przekroczony limit bazy u dostawcy hostingu, uszkodzone tabele oraz włamanie na stronę.
Po lekturze czytelnik będzie umiał ustalić, która przyczyna zachodzi, poprawić dane połączenia, uruchomić wbudowaną w WordPressa naprawę tabel, sformułować zgłoszenie do pomocy technicznej hostingu i sprawdzić, że strona naprawdę wróciła. Nazwy stałych podaję zgodnie z dokumentacją WordPressa, a nazwy z ekranów zgodnie z jego polskim tłumaczeniem.
Jak rozpoznać błąd łączenia się z bazą danych?
WordPress składa się z dwóch części. Pierwsza to pliki na serwerze: sam system, motyw, wtyczki i przesłane zdjęcia. Druga to baza danych, w której zapisane są wpisy, podstrony, produkty, zamówienia, konta użytkowników i ustawienia. Przy każdym otwarciu strony pliki łączą się z bazą i pobierają z niej treść. Gdy połączenie się nie uda, WordPress nie ma czego wyświetlić i pokazuje komunikat.
W aktualnym polskim tłumaczeniu WordPressa komunikat brzmi „Błąd łączenia się z bazą danych”, a na karcie przeglądarki widać tytuł „Błąd bazy danych”. Jeżeli tłumaczenie się nie wczyta, pojawia się wersja angielska: „Error establishing a database connection”. W starszych wydaniach i w opisach w sieci spotyka się nieco inne brzmienia polskiego zdania, ale chodzi o tę samą awarię.
Charakterystyczny jest wygląd: biała strona, szara ramka i jedno zdanie, bez menu, bez stopki i bez logo. Tym różni się ta awaria od białego ekranu i od komunikatu o błędzie krytycznym, które mają inne przyczyny. Opisałem je osobno w tekście o tym, jak przywrócić stronę, gdy widać biały ekran w WordPressie.
Czy błąd widać wszędzie, czy tylko czasami?
To pierwsze pytanie, na które trzeba odpowiedzieć, bo od razu zawęża listę przyczyn. Stronę należy otworzyć w oknie prywatnym przeglądarki, potem na drugim urządzeniu przez sieć komórkową, a na końcu wpisać adres kokpitu, czyli adres strony z dopiskiem /wp-admin.
Jeżeli komunikat widać stale, na stronie i w kokpicie, najbardziej prawdopodobne są błędne dane połączenia albo niedziałający serwer bazy. Jeżeli strona raz działa, a raz pokazuje błąd, zwykle winne jest przeciążenie serwera bazy. Jeżeli strona pokazuje błąd, a kokpit wyświetla zdanie o niedostępnych tabelach i odnośnik do naprawy, przyczyną są uszkodzone tabele.
Jakie są przyczyny błędu łączenia się z bazą danych?
Dokumentacja WordPressa wymienia przy tym komunikacie trzy grupy przyczyn: nieprawidłowe informacje w pliku wp-config.php, problemy po stronie dostawcy hostingu oraz włamanie na stronę. W grupie hostingowej podaje dwa przypadki: baza osiągnęła limit i została wyłączona albo serwer nie działa. Osobno dokumentacja opisuje uszkodzone tabele bazy. Razem daje to pięć przyczyn.
- Błędne dane w wp-config.php. WordPress zna cztery informacje o bazie: jej nazwę, nazwę użytkownika, hasło i adres serwera. Wystarczy pomyłka w jednej z nich. Dokumentacja wskazuje tę przyczynę jako najczęstszą.
- Serwer bazy danych nie działa albo jest przeciążony. Dane są poprawne, ale serwer nie odpowiada lub odrzuca kolejne połączenia, bo jest ich zbyt wiele naraz.
- Baza przekroczyła limit u dostawcy. Część dostawców blokuje bazę, która urosła ponad rozmiar przewidziany w pakiecie.
- Uszkodzone tabele. Połączenie działa, ale WordPress nie może odczytać tabeli z ustawieniami. Zdarza się to po awarii serwera, zapełnieniu dysku albo przerwanym zapisie.
- Włamanie na stronę. Ktoś zmienił plik wp-config.php, dopisał złośliwy kod albo doprowadził do tego, że dostawca zablokował konto.
Kolejność sprawdzania radzę ustawić według tego, co da się zweryfikować najszybciej i bez ryzyka. Najpierw stan usług u dostawcy hostingu, potem cztery dane w pliku wp-config.php, następnie obciążenie i limit bazy, dalej tabele, a na końcu ślady włamania. Każdy z tych etapów ma w tej instrukcji własną sekcję.
Co zmieniło się tuż przed awarią?
Odpowiedź na to pytanie często od razu wskazuje przyczynę. Przeniesienie strony na inny serwer oznacza prawie zawsze inny adres serwera bazy i inne nazwy. Zmiana hasła do bazy w panelu hostingu bez poprawienia go w pliku daje błąd natychmiast. Ręczna edycja wp-config.php, na przykład przy dodawaniu stałych, bywa źródłem literówki lub usuniętego apostrofu.
Co zrobić, zanim zacznie się naprawę?
Przy tej awarii najwięcej szkód powstaje nie z powodu samego błędu, tylko wskutek nerwowych prób naprawy. Usunięcie bazy, ponowna instalacja WordPressa w tym samym katalogu albo przywrócenie starej kopii bez namysłu potrafią zniszczyć dane, które jeszcze przed chwilą były nienaruszone. Dlatego przed jakąkolwiek zmianą trzeba wykonać kilka czynności zabezpieczających.
- Otwarcie strony ze statusem usług dostawcy hostingu albo jego panelu klienta i sprawdzenie, czy nie ma tam informacji o awarii lub pracach serwisowych. Jeżeli jest, naprawa po stronie witryny niczego nie przyspieszy.
- Zalogowanie się do panelu hostingu i sprawdzenie, czy konto nie jest zawieszone, czy usługa jest opłacona i czy nie pojawił się komunikat o przekroczeniu limitów.
- Połączenie się z serwerem przez menedżera plików w panelu albo program do FTP lub SFTP i pobranie na dysk pliku wp-config.php z głównego katalogu witryny. To kopia, do której zawsze da się wrócić.
- Wykonanie kopii bazy danych, jeżeli panel hostingu na to pozwala: przez funkcję kopii zapasowej albo eksport w narzędziu phpMyAdmin. Dokumentacja WordPressa zaleca kopię bazy przed każdą próbą jej naprawy.
- Zapisanie godziny, od której widać błąd, oraz ostatnich zmian na stronie. Te informacje będą potrzebne w zgłoszeniu do pomocy technicznej.
Jeżeli strona nie ma żadnej aktualnej kopii, tym bardziej nie należy niczego usuwać. O tym, jak przygotować kopię, którą da się potem odtworzyć, piszę w tekście o kopii zapasowej WordPressa.
Jak wyświetlić dokładniejszy opis błędu?
Krótki komunikat nie mówi, co dokładnie zawiodło. Dokumentacja WordPressa podaje, że błędy bazy danych są wypisywane tylko wtedy, gdy stała WP_DEBUG ma wartość true. Po jej włączeniu WordPress pokazuje dłuższy opis, który rozróżnia dwie sytuacje.
W pierwszej nagłówek pozostaje ten sam, ale pod nim pojawia się wyjaśnienie, że nazwa użytkownika lub hasło w pliku wp-config.php są niepoprawne albo nie można połączyć się z serwerem bazy pod wskazanym adresem, oraz pytania pomocnicze, między innymi „Czy serwer bazy danych działa?”. W drugiej nagłówek brzmi „Nie można wybrać bazy danych”. Oznacza to, że nazwa użytkownika i hasło są dobre, a problem dotyczy nazwy bazy albo uprawnień użytkownika do tej bazy.
Aby zobaczyć ten opis, w pliku wp-config.php należy odszukać wiersz define( 'WP_DEBUG', false ); i zmienić w nim false na true, a po odczytaniu komunikatu od razu przywrócić false. Dłuższy opis zawiera adres serwera bazy i widzi go każdy odwiedzający, dlatego nie może pozostać włączony na działającej stronie firmowej.
Jak sprawdzić dane połączenia w pliku wp-config.php?
Plik wp-config.php leży w głównym katalogu witryny, obok folderów wp-admin, wp-content i wp-includes. Dokumentacja WordPressa opisuje w nim cztery ustawienia bazy danych. W pliku wyglądają tak:
define( 'DB_NAME', 'nazwa_bazy' );
define( 'DB_USER', 'nazwa_uzytkownika' );
define( 'DB_PASSWORD', 'haslo' );
define( 'DB_HOST', 'localhost' );DB_NAME to nazwa bazy danych, DB_USER to nazwa użytkownika bazy, DB_PASSWORD to jego hasło, a DB_HOST to adres serwera, na którym baza działa. To nie są dane logowania do kokpitu ani do panelu hostingu. Użytkownik bazy jest osobnym kontem, zakładanym w panelu hostingu wyłącznie po to, żeby WordPress mógł czytać i zapisywać dane.
- Otwarcie pliku wp-config.php w edytorze menedżera plików w panelu hostingu. Dokumentacja ostrzega, żeby plików WordPressa nigdy nie edytować w programie do pisania tekstów, takim jak Microsoft Word.
- Odszukanie czterech wierszy zaczynających się od
define( 'DB_i przepisanie ich wartości do notatki, bez poprawiania czegokolwiek w pliku. - Otwarcie w drugiej karcie panelu hostingu, w części poświęconej bazom danych, i porównanie znak po znaku nazwy bazy oraz nazwy użytkownika z tym, co jest w pliku.
- Porównanie adresu serwera bazy z wartością podaną przez dostawcę hostingu w panelu lub w jego pomocy.
- Poprawienie w pliku wyłącznie tej wartości, która się różni, z zachowaniem apostrofów po obu jej stronach.
- Zapisanie pliku i odświeżenie strony w oknie prywatnym.
Hasła nie da się w panelu podejrzeć, więc nie można go porównać wprost. Sprawdza się je pośrednio: nazwę użytkownika i hasło z pliku wpisuje się na ekranie logowania narzędzia phpMyAdmin, jeżeli dostawca udostępnia taki ekran. Udane logowanie oznacza, że para jest poprawna. Odmowa oznacza, że hasło trzeba ustawić na nowo, co opisuję w następnej sekcji.
Jakie pomyłki zdarzają się w tym pliku najczęściej?
Dokumentacja WordPressa każe przed zapisaniem pliku sprawdzić dwie rzeczy: czy przy wartościach nie ma spacji na początku lub na końcu oraz czy nie zostały usunięte pojedyncze apostrofy. Jedna spacja wklejona razem z hasłem wystarcza, żeby serwer bazy odmówił połączenia.
Druga częsta pomyłka to przedrostek w nazwach. U wielu dostawców nazwa bazy i nazwa użytkownika są poprzedzone nazwą konta, na przykład konto_sklep zamiast samego „sklep”. WordPress sam podpowiada tę możliwość w dłuższym opisie błędu. W pliku musi się znaleźć pełna nazwa, dokładnie taka, jaką pokazuje panel.
Trzecia pomyłka dotyczy znaków specjalnych w haśle. Apostrof albo lewy ukośnik w haśle zmienia znaczenie wiersza w pliku i WordPress odczytuje inne hasło niż ustawione. Najprostszym wyjściem jest nowe, długie hasło złożone z liter i cyfr. Czwarta to cudzysłowy drukarskie wklejone z dokumentu tekstowego: w pliku muszą być proste apostrofy.
Co wpisać jako adres serwera bazy?
W przykładowym pliku WordPressa wartością DB_HOST jest „localhost” i dokumentacja zaznacza, że najczęściej nie trzeba jej zmieniać. Dotyczy to serwerów, na których baza działa na tej samej maszynie co strona. Wielu dostawców utrzymuje jednak bazy na osobnych serwerach i wtedy w tym miejscu wpisuje się adres podany w panelu.
Dokumentacja opisuje też dwa szczególne przypadki. Jeżeli dostawca używa innego portu, dopisuje się go po dwukropku, tak jak w przykładzie z dokumentacji: define( 'DB_HOST', 'mysql.example.com:3307' );, przy czym numer portu zastępuje się tym, który podał dostawca. Jeżeli dostawca korzysta z gniazda, po dwukropku wpisuje się ścieżkę wskazaną przez dostawcę. Tych wartości nie należy zgadywać. Jedynym pewnym źródłem jest panel albo pomoc techniczna hostingu.
Kto woli nie zaglądać do plików na serwerze, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: ustalę, dlaczego WordPress nie łączy się z bazą, poprawię dane połączenia lub tabele i przywrócę działanie strony.
Jak ustalić prawidłowe dane w panelu hostingu i zmienić hasło do bazy?
Każdy dostawca hostingu nazywa tę część panelu trochę inaczej, zwykle jest to pozycja ze słowami „Bazy danych” albo „MySQL”. Niezależnie od nazwy znajdują się tam trzy rzeczy: lista baz, lista użytkowników baz oraz informacja, który użytkownik ma dostęp do której bazy. Adres serwera bazy bywa podany na tej samej stronie albo w szczegółach bazy.
Najpierw trzeba sprawdzić, czy baza o nazwie z pliku w ogóle istnieje i czy użytkownik z pliku jest do niej przypisany. Po przeniesieniu strony zdarza się, że baza została zaimportowana, ale użytkownik nie otrzymał do niej uprawnień. WordPress zgłasza wtedy „Nie można wybrać bazy danych” i pyta, czy użytkownik ma uprawnienia do używania tej bazy.
Jeżeli nazwy się zgadzają, a połączenia nadal nie ma, pozostaje hasło. Dokumentacja WordPressa przy tej przyczynie radzi ustawić hasło do bazy na nowo. Robi się to w panelu hostingu, a nie w WordPressie.
- Otwarcie w panelu hostingu listy użytkowników baz danych i odszukanie użytkownika o nazwie z wiersza DB_USER.
- Wybranie przy nim zmiany hasła i ustawienie nowego, długiego hasła z liter i cyfr. Hasło trzeba od razu zapisać w menedżerze haseł.
- Sprawdzenie, czy ten użytkownik jest nadal przypisany do bazy z wiersza DB_NAME i ma do niej pełne uprawnienia. Jeżeli nie, należy go przypisać.
- Otwarcie pliku wp-config.php i wklejenie nowego hasła między apostrofy w wierszu DB_PASSWORD, bez spacji przed hasłem i po nim.
- Zapisanie pliku i otwarcie strony w oknie prywatnym.
Ważne ostrzeżenie: z jednego użytkownika bazy może korzystać więcej niż jedna strona, na przykład sklep i blog albo wersja testowa. Zmiana hasła wyłączy wtedy również tamte witryny, dopóki nowe hasło nie trafi do ich plików. Przed zmianą trzeba więc ustalić, gdzie jeszcze ten użytkownik jest używany.
W panelu nie należy korzystać z przycisków usuwających bazę ani tworzyć nowej, pustej bazy pod tą samą nazwą. Pusta baza usunie komunikat o błędzie, ale WordPress uzna, że nie jest zainstalowany, i zaproponuje instalację od zera. Treść strony zostałaby w ten sposób odcięta, a przy usunięciu starej bazy utracona.
Jak sprawdzić, czy serwer bazy danych działa i nie jest przeciążony?
Gdy dane w pliku są poprawne, a błąd nie znika, przyczyna leży najpewniej poza witryną. Serwer bazy mógł zostać zatrzymany przez awarię, trwają na nim prace serwisowe albo przyjął tyle połączeń, że kolejne odrzuca. Sam WordPress w dłuższym opisie błędu stawia właśnie takie pytania: czy serwer bazy działa i czy nie jest wyjątkowo przeciążony.
Najprostszy sprawdzian to wejście z panelu hostingu do narzędzia phpMyAdmin. Jeżeli narzędzie otwiera się i pokazuje listę tabel, serwer bazy działa, a przyczyny trzeba szukać w danych połączenia albo w tabelach. Jeżeli phpMyAdmin również zgłasza błąd połączenia, serwer bazy jest niedostępny i sprawę może rozwiązać tylko dostawca.
Co oznacza błąd, który pojawia się i znika?
Okresowy błąd przy poprawnych danych wskazuje na przeciążenie, często wywołane importem produktów, wysyłką wiadomości z wtyczki albo kopią zapasową wykonywaną w godzinach największego ruchu. Serwer bazy obsługuje ograniczoną liczbę połączeń jednocześnie, a na kontach współdzielonych dostawca dodatkowo ogranicza je dla każdego klienta. Gdy stronę odwiedza naraz wiele osób albo robotów, a każde wejście wymaga wielu zapytań do bazy, limit się wyczerpuje i część odwiedzających widzi komunikat.
Doraźnie pomaga wyłączenie czynności, która obciąża bazę, oraz włączenie pamięci podręcznej stron, dzięki której większość odwiedzających dostaje gotową stronę bez pytania bazy. Trwałym rozwiązaniem jest uporządkowanie wtyczek i bazy, a przy rosnącym ruchu mocniejszy pakiet hostingu. Jak znaleźć element, który obciąża witrynę, opisuję w tekście o tym, co spowalnia WordPressa.
Co napisać w zgłoszeniu do pomocy technicznej hostingu?
Dokumentacja WordPressa wprost zaleca kontakt z dostawcą, gdy plik wp-config.php jest poprawny. Zgłoszenie powinno być konkretne, bo ogólne zdanie o niedziałającej stronie wydłuża wymianę wiadomości. Poniższą treść można przepisać i uzupełnić własnymi danymi:
Dzień dobry, od godziny [godzina] witryna [adres] wyświetla komunikat WordPressa o błędzie łączenia się z bazą danych. Dane w pliku wp-config.php zostały porównane z panelem i są zgodne: baza [nazwa bazy], użytkownik [nazwa użytkownika], adres serwera [wartość DB_HOST]. Proszę o sprawdzenie, czy serwer bazy danych działa, czy baza nie została zablokowana z powodu limitu rozmiaru albo liczby połączeń oraz czy użytkownik ma uprawnienia do tej bazy. Proszę też o informację, czy tabele bazy nie wymagają naprawy.
W zgłoszeniu nie podaje się hasła do bazy. Pomoc techniczna go nie potrzebuje, a wiadomości e-mail i rozmowy na czacie nie są miejscem na hasła.
Co zrobić, gdy baza danych przekroczyła limit u dostawcy?
Pakiety hostingowe mają określoną pojemność, często osobno dla plików i osobno dla każdej bazy. Dokumentacja WordPressa wymienia sytuację, w której baza osiągnęła swój limit i została wyłączona. W praktyce dostawcy stosują różne rozwiązania: jedni blokują całą bazę, inni tylko zapis do niej. W obu przypadkach strona przestaje działać poprawnie.
Rozmiar bazy i przysługujący limit widać w panelu hostingu, przy liście baz albo w podsumowaniu wykorzystania pakietu. Jeżeli panel pokazuje wartość równą limitowi lub wyższą, przyczyna jest ustalona. Wysokość limitu i sposób postępowania po jego przekroczeniu określa wyłącznie dostawca, dlatego warto od razu zapytać, czy może czasowo odblokować bazę na czas porządków.
Bazę powiększają najczęściej dzienniki zapisywane przez wtyczki, stare wersje robocze wpisów, komentarze oznaczone jako spam i tabele po usuniętych wtyczkach. Radzę jednak nie usuwać tabel ani wierszy na podstawie samej nazwy. Tabela, która wygląda na zbędną, może należeć do sklepu albo formularzy. Bezpieczna kolejność to: kopia bazy, ustalenie, do której wtyczki należy duża tabela, opróżnienie danych z poziomu ustawień tej wtyczki, a dopiero w ostateczności zmiany bezpośrednio w bazie. Jeżeli baza jest duża, bo strona naprawdę ma dużo treści i zamówień, właściwym rozwiązaniem jest większy pakiet.
Jak naprawić uszkodzone tabele bazy danych?
Uszkodzone tabele rozpoznaje się po tym, że serwer bazy działa i dane połączenia są poprawne, a mimo to strona pokazuje błąd. W kokpicie pojawia się wtedy zdanie „Jedna lub więcej tabel w bazie danych jest niedostępnych.” wraz z informacją, że baza może wymagać naprawy. Uszkodzenie jest zwykle skutkiem awarii serwera, zapełnionego dysku albo zapisu przerwanego w połowie.
WordPress ma wbudowany skrypt do naprawy tabel. Dokumentacja opisuje go jako automatyczną naprawę bazy, którą włącza się jednym wierszem w pliku wp-config.php:
define( 'WP_ALLOW_REPAIR', true );Skrypt jest dostępny pod adresem strony z dopiskiem /wp-admin/maint/repair.php. Dokumentacja zaznacza dwie rzeczy. Po pierwsze, wiersz należy dodawać tylko w razie potrzeby i usuwać po rozwiązaniu problemu. Po drugie, przy włączonej naprawie strona skryptu nie wymaga logowania, bo przy uszkodzonej bazie logowanie często nie działa. Oznacza to, że do czasu usunięcia wiersza skrypt może uruchomić każdy, kto zna adres.
- Wykonanie kopii bazy danych w panelu hostingu, o ile nie została zrobiona wcześniej.
- Otwarcie pliku wp-config.php i dopisanie wiersza z WP_ALLOW_REPAIR przed wierszem z komentarzem zaczynającym się od słów „That’s all, stop editing!”. Zapisanie pliku.
- Wpisanie w przeglądarce adresu strony z dopiskiem /wp-admin/maint/repair.php. Powinien się pojawić ekran z dwoma przyciskami.
- Kliknięcie „Napraw bazę danych”. Drugi przycisk, „Napraw i zoptymalizuj bazę danych”, dodatkowo porządkuje tabele, ale według opisu na ekranie trwa dłużej i na ten czas blokuje bazę. Przy awarii wystarcza pierwszy.
- Odczekanie do końca pracy skryptu bez zamykania karty i przeczytanie listy wyników. Przy każdej tabeli widać informację, że nie wymaga naprawy, że została naprawiona albo że naprawa się nie udała.
- Usunięcie dopisanego wiersza z pliku wp-config.php i zapisanie pliku. Skrypt sam o tym przypomina po zakończeniu pracy.
- Otwarcie strony i kokpitu w oknie prywatnym.
Ten skrypt wymaga działającego połączenia z bazą. Jeżeli przyczyną są złe dane w pliku albo wyłączony serwer bazy, ekran naprawy pokaże ten sam błąd i niczego nie zmieni. Naprawa tabel nie zastępuje więc wcześniejszych etapów.
Co zrobić, gdy naprawa się nie powiodła?
Jeżeli przy którejś tabeli widać informację o nieudanej naprawie, listę błędów trzeba skopiować i zachować. Kolejnym krokiem jest prośba do dostawcy hostingu o sprawdzenie i naprawę tabel po jego stronie. Dokumentacja WordPressa zaleca to każdemu, kto nie czuje się pewnie w narzędziu phpMyAdmin, i dodaje, że w takim narzędziu naprawę uruchamia się po zaznaczeniu tabel, zawsze po wcześniejszym wykonaniu kopii.
Gdy tabeli nie da się naprawić, pozostaje przywrócenie bazy z kopii zapasowej. Trzeba mieć świadomość kosztu: przepada wszystko, co zapisano między wykonaniem kopii a awarią. W sklepie są to zamówienia i konta klientów, na stronie firmowej zgłoszenia z formularzy i nowe wpisy. Dlatego przed przywróceniem należy zachować kopię uszkodzonej bazy, z której specjalista może jeszcze odzyskać część danych.
Jak rozpoznać, że przyczyną jest włamanie?
Dokumentacja WordPressa wskazuje włamanie jako możliwość do rozważenia wtedy, gdy plik wp-config.php został sprawdzony, a dostawca wykluczył problemy po swojej stronie. To rzadsza przyczyna niż literówka w haśle, ale nie wolno jej pominąć, bo samo przywrócenie połączenia nie usuwa intruza.
Niepokoić powinny następujące sygnały: data ostatniej zmiany pliku wp-config.php, której nikt nie potrafi wyjaśnić, obce wiersze kodu na początku lub na końcu tego pliku, pliki o przypadkowych nazwach w głównym katalogu witryny, nieznane konta w panelu hostingu oraz wiadomość od dostawcy o zablokowaniu konta za rozsyłanie spamu lub złośliwe oprogramowanie.
W takiej sytuacji nie należy usuwać podejrzanych plików na własną rękę ani przywracać przypadkowej kopii, bo kopia może być już zainfekowana. Najpierw zmienia się hasła do panelu hostingu, FTP, bazy danych i kont administratorów, a potem porządkuje pliki. Kolejne czynności opisałem w tekście o tym, co robić, gdy strona na WordPressie jest zainfekowana.
Po czym poznać, że naprawa zadziałała, i jak zapobiec powtórce?
Powrót strony głównej to dopiero połowa sprawdzianu. Baza danych obsługuje także to, czego na pierwszy rzut oka nie widać: logowanie, zapis formularzy, koszyk i zaplanowane zadania. Po naprawie trzeba przejść przez krótką listę kontrolną.
- Otwarcie w oknie prywatnym strony głównej, podstrony oferty i jednego wpisu.
- Zalogowanie się do kokpitu i zapisanie drobnej zmiany w wersji roboczej dowolnego wpisu. Udany zapis potwierdza, że baza przyjmuje dane.
- Wejście w „Narzędzia” > „Stan witryny”, na kartę „Informacja”, i rozwinięcie sekcji „Baza danych”. Wiersze „Adres serwera bazy danych”, „Nazwa bazy danych” i „Nazwa użytkownika bazy danych” powinny pokazywać wartości zgodne z panelem hostingu.
- Wysłanie próbnego zgłoszenia z formularza kontaktowego, a w sklepie złożenie zamówienia próbnego.
- Upewnienie się, że w pliku wp-config.php stała WP_DEBUG ma wartość false, a wiersz z WP_ALLOW_REPAIR został usunięty.
- Wyczyszczenie pamięci podręcznej we wtyczce, w panelu hostingu i w usłudze CDN, żeby odwiedzający nie otrzymywali zapisanej strony z błędem.
Jeżeli błąd wraca po kilku godzinach lub dniach, naprawa usunęła objaw, a nie przyczynę. Powracający błąd przy poprawnych danych prawie zawsze oznacza przeciążenie albo limit i wymaga rozmowy z dostawcą hostingu, najlepiej z podaniem godzin, w których strona nie działała.
Zapobieganie sprowadza się do kilku stałych zasad. Kopie bazy powinny powstawać automatycznie i trafiać poza serwer, na którym działa strona. Hasło do bazy zmienia się zawsze w dwóch miejscach jednocześnie: w panelu i w pliku. Przed przeniesieniem strony zapisuje się cztery dane połączenia z nowego serwera, zanim cokolwiek zostanie przełączone. Przydaje się też usługa monitorowania dostępności, która powiadamia o awarii wcześniej niż klienci.
Najczęstsze pytania
Czy ten błąd oznacza, że treść strony przepadła?
W typowym przypadku nie. Komunikat mówi tylko tyle, że WordPress nie zdołał połączyć się z bazą, a nie że baza została usunięta. Po poprawieniu danych połączenia albo przywróceniu pracy serwera wpisy, produkty i ustawienia wracają w niezmienionej postaci. Ryzyko utraty danych pojawia się dopiero przy uszkodzonych tabelach, których nie udało się naprawić, oraz przy pochopnym usunięciu bazy.
Dlaczego strona działa, a kokpit pokazuje błąd bazy danych?
Najczęściej odwiedzający oglądają stronę zapisaną w pamięci podręcznej, która nie wymaga połączenia z bazą, a kokpit takiej kopii nie ma. Druga możliwość to uszkodzona tabela potrzebna tylko części witryny. W obu przypadkach postępowanie jest takie samo: sprawdzenie danych w wp-config.php, stanu serwera bazy, a następnie tabel.
Czy ponowna instalacja WordPressa usunie ten błąd?
Nie i jest to jedna z najbardziej ryzykownych prób. Nowe pliki WordPressa nie zmieniają danych połączenia ani stanu serwera bazy, więc komunikat pozostanie. Instalacja wskazująca nową, pustą bazę uruchomi czystą witrynę bez dotychczasowej treści. Pliki systemowe wymienia się tylko wtedy, gdy są uszkodzone, a to daje inne objawy niż błąd bazy.
Czy błąd bazy danych szkodzi pozycjom strony w Google?
Krótka przerwa zwykle nie zostawia śladu. Podczas awarii robot wyszukiwarki otrzymuje odpowiedź z błędem serwera i wraca później. Kłopot zaczyna się wtedy, gdy strona jest niedostępna przez dłuższy czas albo błąd regularnie powraca, bo robot odwiedza ją wtedy rzadziej, a adresy mogą wypadać z wyników. Dlatego powracającego błędu nie należy lekceważyć, nawet jeśli za każdym razem trwa krótko.
Czy można zostawić w pliku wiersz z WP_ALLOW_REPAIR na przyszłość?
Nie. Dokumentacja WordPressa zaleca włączanie tej stałej wyłącznie na czas naprawy, ponieważ ekran naprawy nie wymaga wtedy logowania. Pozostawiony wiersz pozwala każdej osobie znającej adres uruchomić skrypt, który na czas pracy obciąża i blokuje bazę. Po zakończonej naprawie wiersz należy usunąć z pliku.
Co zrobić, gdy dostawca hostingu twierdzi, że po jego stronie wszystko działa?
Trzeba wtedy poprosić o konkretne informacje: adres serwera bazy właściwy dla tego konta, potwierdzenie, że użytkownik ma uprawnienia do bazy, oraz wpisy z dziennika błędów z godzin awarii. Następnie należy jeszcze raz porównać cztery dane w pliku, włączyć na chwilę dokładniejszy opis błędu i sprawdzić tabele. Jeżeli wszystko jest poprawne, a błąd wraca w godzinach dużego ruchu, przyczyną jest zbyt słaby pakiet w stosunku do potrzeb strony.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
To zrozumiałe. Praca na plikach serwera i na bazie danych wymaga spokoju, a strona, która nie działa, tego spokoju nie daje. Mogę zająć się sprawą od początku do końca: zabezpieczę kopię plików i bazy, ustalę, która z pięciu przyczyn zachodzi, poprawię dane połączenia, naprawię tabele albo poprowadzę rozmowę z dostawcą hostingu, a po przywróceniu strony sprawdzę formularze, logowanie i sklep oraz wyjaśnię prostymi słowami, co się stało i jak uniknąć powtórki.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz godzinę, od której widać komunikat. Resztę ustalę sam.
