Ремонт сайтів

WordPress не бачить базу після зміни хостингу: як відновити з’єднання

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

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

Які дані підключення перевірити першими

Основні параметри з’єднання WordPress з базою зберігаються у файлі wp-config.php у кореневій директорії сайту. Перед редагуванням завантажте копію цього файла на комп’ютер. Помилка в конфігурації або випадкове видалення символів може повністю заблокувати сайт.

Перевірте такі рядки:

  • DB_NAME — фактична назва бази даних на новому хостингу;
  • DB_USER — користувач MySQL, якому дозволено працювати з цією базою;
  • DB_PASSWORD — актуальний пароль користувача бази;
  • DB_HOST — адреса сервера бази даних;
  • $table_prefix — префікс таблиць, який має відповідати імпортованій базі.

Не орієнтуйтеся лише на назви зі старого хостингу. На новому сервері база або користувач можуть отримати інший префікс, наприклад назва облікового запису хостингу може автоматично додаватися до назви бази. Точні значення зазвичай вказані в панелі керування хостингом у розділі MySQL-баз.

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

Як перевірити користувача та права MySQL

Навіть правильний пароль не допоможе, якщо користувача не додано до потрібної бази або йому не надано необхідні права. У панелі хостингу відкрийте керування базами даних і перевірте, чи існують:

  • сама база з імпортованими таблицями;
  • користувач MySQL;
  • зв’язок користувача з цією базою;
  • права на читання, запис, зміну структури та виконання запитів, якщо вони потрібні панелі керування.

Для стандартної роботи WordPress користувач повинен мати доступ до всіх таблиць своєї бази. Якщо користувач був створений заново, його пароль потрібно встановити ще раз і без помилок перенести в wp-config.php. Зверніть увагу на пробіли, спеціальні символи та лапки.

Перевірити доступ можна через phpMyAdmin або інший інструмент керування базою. Якщо база відкривається в phpMyAdmin, це ще не доводить, що саме користувач із wp-config.php має потрібні права. У разі сумнівів безпечніше створити окремого користувача, призначити його потрібній базі та оновити конфігурацію, попередньо зберігши резервну копію файла.

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

Якщо після перевірки параметрів залишається повідомлення про помилку, корисною буде ремонт підключення WordPress до бази із повною перевіркою конфігурації, прав і журналів сервера.

Вплив префікса таблиць і адреси сервера

WordPress шукає системні таблиці за префіксом, зазначеним у wp-config.php. Наприклад, якщо в базі є таблиці siteposts, siteoptions і site_users, у конфігурації має бути:

$tableprefix = 'site';

Якщо вказано стандартний префікс wp_, WordPress не знайде потрібні таблиці навіть за умови успішного підключення до самої бази. Це може проявлятися як повідомлення про відсутність таблиць, пропозиція повторно встановити WordPress або порожня адміністративна частина.

Не змінюйте префікс навмання. Спочатку перегляньте список таблиць у phpMyAdmin і порівняйте його з параметром $table_prefix. Якщо таблиці частково відсутні, це може свідчити про неповний імпорт або використання іншої бази.

Окремо перевірте адресу сервера. Значення DB_HOST може бути:

  • localhost — база працює на тому самому сервері;
  • окремим доменним ім’ям або IP-адресою — база розміщена на іншому сервері;
  • адресою з нестандартним портом — якщо це передбачено конфігурацією хостингу.

Не підміняйте адресу сервера значеннями з прикладів в інтернеті. Неправильний DB_HOST може спричинити тайм-аут, відмову в доступі або неможливість встановити мережеве з’єднання. Точні параметри потрібно брати з документації або панелі нового хостингу.

Як імпортувати велику базу без помилок

Якщо після перенесення база створена, але містить не всі таблиці або має нульовий розмір, проблема може бути в неповному імпорті. Великі SQL-файли часто не проходять через phpMyAdmin через обмеження розміру завантаження, часу виконання або пам’яті PHP.

Перед повторним імпортом:

  1. Збережіть копію поточного SQL-файла та, якщо база вже містить дані, зробіть окремий експорт.
  2. Перевірте, чи не пошкоджений файл резервної копії та чи завершується він коректно.
  3. Уточніть, чи існує цільова база і чи має користувач права на створення або зміну таблиць.
  4. Якщо попередній імпорт був неповним, не запускайте повторний процес без розуміння, чи будуть дублюватися таблиці та записи.

Для великої бази можуть знадобитися імпорт через командний рядок MySQL, функція імпорту в панелі хостингу або спеціалізований інструмент перенесення. Команда та її параметри залежать від доступів і налаштувань сервера, тому не варто виконувати випадкові SQL-команди з форумів на робочій базі.

Додатково перевірте кодування, таблиці з помилками та повідомлення журналу імпорту. Перерваний процес може залишити частину таблиць і створити оманливе враження, що база відновлена. Якщо в базі є важливі замовлення, користувачі або інші комерційні дані, краще доручити імпорт спеціалісту, щоб зменшити ризик незворотного перезапису.

Що протестувати після відновлення

Після виправлення параметрів або завершення імпорту не обмежуйтеся перевіркою головної сторінки. Переконайтеся, що WordPress не лише відкривається, а й коректно читає та записує дані.

  • Відкрийте головну сторінку, кілька записів і сторінок.
  • Увійдіть до адміністративної панелі та перевірте користувачів.
  • Створіть тестовий чернетковий запис і збережіть його.
  • Перевірте медіафайли, коментарі, форми та функції, які записують дані в базу.
  • Переконайтеся, що постійні посилання працюють після перенесення.
  • Перевірте налаштування URL сайту, домен, HTTPS і перенаправлення.
  • Перегляньте журнали PHP, вебсервера та WordPress на нові помилки.

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

Спеціаліст потрібен, якщо немає резервної копії, база частково імпортована, доступ до панелі хостингу обмежений, помилки повторюються після перевірки параметрів або сайт містить критично важливі дані. До діагностики не видаляйте таблиці, не запускайте масову заміну URL і не перевстановлюйте WordPress: такі дії можуть ускладнити відновлення та призвести до втрати інформації.

Залишити коментар

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *