Помилка підключення до бази даних у WordPress: як її виправити

Ви відкриваєте сайт, і кожна сторінка — і публічна частина, і wp-admin — замінена одним сірим рядком: Помилка встановлення з’єднання з базою даних. Нічого не відображається, бо й не може. WordPress не дійшов навіть до збирання сторінки.

Ось модель, яка робить лагодження швидким. WordPress зберігає весь ваш контент — записи, сторінки, налаштування, користувачів — у базі даних MySQL, а не у файлах. На кожен запит він читає чотири облікові дані з wp-config.php, підключається до цієї бази й бере потрібне. Ця помилка означає, що з’єднання було спробувано і відхилено. Щоб виправити, треба зрозуміти, чому його відхилили, а варіантів лише три.

Три причини, у порядку ймовірності

1. Невірні облікові дані у wp-config.php — звичайний наслідок переїзду на інший хостинг.
2. Сервер бази даних вимкнено чи перевантажено — звичайний наслідок того, що з вашого боку нічого не змінювалося.
3. База даних пошкоджена — рідше, і проявляє себе інакше.

Розбирайтеся з ними саме в цьому порядку.

Крок 1: перевірте чотири облікові дані

Відкрийте wp-config.php у корені сайту через SFTP або файловий менеджер хостингу. З’єднання задають чотири рядки:

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

Кожне з цих значень має точно збігатися з тим, що видав хостинг. Відкрийте розділ баз даних у панелі керування хостингу (у cPanel це «MySQL Databases») і звірте символ за символом:

• DB_NAME — хостинги часто додають до імені префікс з вашим акаунтом, наприклад cpaneluser_wpdb. Префікс — частина імені.
• DB_USER — той самий префікс, і користувач має бути призначений на цю базу даних, а не просто існувати.
• DB_PASSWORD — найчастіший винуватець. Якщо сумніваєтеся, скиньте його в панелі керування і вставте нове значення. Стежте за пробілом у кінці й за «розумною» лапкою.
• DB_HOST — не вважайте, що це localhost. Багато хостингів використовують окремий сервер бази даних з адресою на кшталт mysql.yourhost.com, іноді з :port. Правильне значення показано в панелі керування.

Оскільки саме в цьому файлі й зберігаються чотири значення, найнадійніший спосіб заново отримати чистий і правильно взятий у лапки wp-config.php — генератор wp-config.php: заповніть чотири поля бази даних і вставте результат поверх старого блоку.

Один цей крок усуває помилку майже після кожного переїзду: облікові дані, які були правильні на старому хостингу, на новому вже не годяться.

Крок 2: переконайтеся, що сервер бази даних справді працює

Якщо облікові дані правильні, а помилка не зникає — особливо якщо вона з’явилася сама без жодних змін з вашого боку — під підозрою сам сервер бази даних.

На віртуальному хостингу це часте й зазвичай тимчасове явище: служба MySQL перевантажується під час сплеску трафіку або впирається в ліміт підключень на акаунт і починає відхиляти нові з’єднання. Зазвичай вона відновлюється за кілька хвилин. Перш ніж робити щось радикальне, трохи зачекайте й перезавантажте сторінку.

Щоб перевірити, чи взагалі дійсні облікові дані, незалежно від WordPress, покладіть поруч із 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.';

Підставте свої справжні DB_HOST, DB_USER і DB_PASSWORD. Якщо виводиться Connected, логін працює, а проблема деінде (пошкоджена база даних, Крок 3). Якщо виводиться помилка з’єднання, саме повідомлення підкаже, яка саме: «Access denied» — невірний користувач або пароль; «Can’t connect to MySQL server» — невірний хост або справді недоступна служба, і тоді час писати в хостинг. Видаліть скрипт, щойно завершите.

Крок 3: відновіть пошкоджену базу даних

Пошкодження від проблеми з підключенням відрізняє одна ознака: публічна частина відкривається, а wp-admin показує помилку — або навпаки. Якби з’єднання справді відхилялося, не працювало б ані те, ані інше. Таке розходження вказує на пошкоджені таблиці.

У WordPress є вбудований інструмент відновлення. Додайте до wp-config.php один рядок, вище коментаря про те, що далі редагувати не потрібно:

define( 'WP_ALLOW_REPAIR', true );

Потім відкрийте цей URL прямо в браузері:

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

Вона завантажується без входу — у цьому весь сенс, адже доступ у вас може бути закритий — і пропонує «Відновити базу даних» та «Відновити й оптимізувати базу даних». Запустіть.

Потім одразу видаліть цей рядок з wp-config.php. Доки він на місці, будь-хто в інтернеті може відкрити цей URL і запустити відновлення вашої бази даних. Це не необов’язкове прибирання, а закриття дірки, яку ви щойно відкрили.

Крок 4: коли відновлення навіть не підключається

Якщо сама сторінка відновлення показує помилку з’єднання, відновлювати нічого — база даних взагалі недоступна, і ви повертаєтеся до Кроку 1 або Кроку 2. У цей момент надійний хід — відновити базу даних із найсвіжішої резервної копії хостингу. У більшості панелей керування зберігаються автоматичні щоденні знімки бази даних; відновлення зі вчорашньої копії майже завжди швидше й безпечніше, ніж ганятися за пошкодженням, до якого ви не можете підключитися.

Поради, які можна спокійно ігнорувати

«Просто перевстановіть WordPress». Ця помилка про підключення до бази даних, а не про файли ядра. Перевстановлення замінює саме ті файли, що й так працюють, і не чіпає нічого зламаного.

«Збільште ліміт пам’яті PHP». Вичерпання пам’яті — це інша помилка з іншим повідомленням. Підвищення ліміту нічого не дає при відхиленому підключенні до бази даних і лише маскує те, що ви так і не перевірили облікові дані.

«Очистіть кеш». Збій стається в PHP раніше, ніж кеш встигне віддати сторінку. Доки з’єднання відхиляється, очищення кешу нічого не змінює; його варто робити лише після того, як сайт повернеться до життя.

«Відредагуйте базу даних напряму». Лізти в phpMyAdmin і правити таблиці вручну, не переконавшись навіть, що з’єднання працює, — так тимчасовий збій перетворюється на безповоротну втрату даних. Спершу переконайтеся у з’єднанні; дані чіпайте в останню чергу і лише з резервної копії.

Все ще не виходить?

Якщо тестовий скрипт підтверджує облікові дані, сервер працює, відновлення підключається і не знаходить помилок, а сайт усе одно показує повідомлення, залишається один підозрюваний — плагін, який звертається до бази даних за власним з’єднанням: кешувальний або той, що працює з базою, плагін, який зберіг застарілий хост. Щоб це виключити, перейменуйте wp-content/plugins на plugins-off через SFTP. Якщо помилка зникне, повертайте плагіни по одному, доки вона не з’явиться знову.