Error Koneksi Database di WordPress: Cara Memperbaikinya

Anda membuka situs dan setiap halaman — baik tampilan depan maupun wp-admin — berganti jadi satu kalimat abu-abu: Error saat membuat koneksi ke database. Tidak ada yang tampil, karena memang tidak bisa. WordPress bahkan tidak sampai ke tahap membangun halaman.

Ini model berpikir yang membuatnya cepat diperbaiki. WordPress menyimpan seluruh konten Anda — pos, halaman, pengaturan, pengguna — di database MySQL, bukan di file. Pada setiap request, WordPress membaca empat detail login dari wp-config.php, menyambung ke database itu, dan menarik apa yang dibutuhkan. Error ini berarti koneksi tersebut dicoba dan ditolak. Perbaikannya adalah mencari tahu mengapa ditolak, dan hanya ada tiga kemungkinan.

Tiga penyebab, diurutkan dari yang paling mungkin

1. Kredensial yang salah di wp-config.php — biasanya akibat pindah hosting.
2. Server database mati atau kelebihan beban — biasanya akibat tidak ada yang berubah di sisi Anda.
3. Database rusak — lebih jarang, dan gejalanya berbeda.

Kerjakan berurutan seperti itu.

Langkah 1: periksa keempat kredensial

Buka wp-config.php di root situs Anda lewat SFTP atau File Manager hosting. Empat baris mendefinisikan koneksinya:

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

Setiap nilai ini harus sama persis dengan yang ditetapkan hosting Anda. Buka bagian database di control panel hosting (di cPanel namanya “MySQL Databases”) dan bandingkan karakter per karakter:

• DB_NAME — hosting sering menambahkan prefiks nama akun di depannya, seperti cpaneluser_wpdb. Prefiks itu bagian dari nama.
• DB_USER — aturan prefiks yang sama berlaku, dan user itu harus ditugaskan ke database tersebut, bukan sekadar ada.
• DB_PASSWORD — biang kerok paling umum. Kalau ragu, reset di control panel dan tempel nilai barunya. Awasi spasi di belakang atau smart quote.
• DB_HOST — jangan asumsikan localhost. Banyak hosting memakai server database khusus dengan alamat seperti mysql.yourhost.com, kadang dengan :port. Control panel menunjukkan nilai yang benar.

Karena file inilah tempat keempat nilai tersebut berada, cara teraman untuk membuat ulang wp-config.php yang bersih dan tanda kutipnya benar adalah generator wp-config.php — isi empat kolom database dan tempel hasilnya menimpa blok lama.

Langkah ini saja sudah memperbaiki error setelah hampir setiap migrasi, karena kredensial yang benar di hosting lama menjadi salah di hosting baru.

Langkah 2: pastikan server database benar-benar menyala

Kalau kredensialnya benar dan error tetap ada — apalagi kalau muncul sendiri tanpa perubahan dari Anda — server database-nya sendiri yang dicurigai.

Di hosting shared ini umum dan biasanya sementara: layanan MySQL kewalahan saat lonjakan trafik atau mentok di batas koneksi per akun lalu mulai menolak koneksi baru. Biasanya pulih dalam beberapa menit. Muat ulang setelah menunggu sebentar sebelum mengambil tindakan drastis.

Untuk menguji apakah kredensialnya valid terlepas dari WordPress, letakkan skrip kecil di samping 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.';

Pakai DB_HOST, DB_USER, dan DB_PASSWORD asli Anda. Kalau muncul Connected, detail login Anda berfungsi dan masalahnya ada di tempat lain (database rusak, Langkah 3). Kalau muncul error koneksi, pesannya memberitahu yang mana: “Access denied” berarti user atau password salah; “Can’t connect to MySQL server” berarti host salah atau layanan yang benar-benar mati — saatnya menghubungi hosting Anda. Hapus skripnya begitu selesai.

Langkah 3: perbaiki database yang rusak

Ada satu ciri yang membedakan kerusakan data dari masalah koneksi: tampilan depan terbuka tapi wp-admin menampilkan error, atau sebaliknya. Kalau koneksinya benar-benar ditolak, keduanya pasti mati. Pemisahan seperti itu menunjuk ke tabel yang rusak.

WordPress punya alat perbaikan bawaan. Tambahkan satu baris ke wp-config.php, di atas komentar “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Lalu buka URL ini langsung di browser Anda:

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

Halaman ini terbuka tanpa login — memang itu maksudnya, karena bisa saja Anda terkunci di luar — dan menawarkan “Repair Database” serta “Repair and Optimize Database.” Jalankan.

Lalu segera hapus baris itu dari wp-config.php. Selama baris itu ada, siapa pun di internet bisa membuka URL tersebut dan menjalankan perbaikan pada database Anda. Ini bukan pembersihan opsional; ini menutup celah yang baru saja Anda buka.

Langkah 4: ketika perbaikan pun tidak bisa terhubung

Kalau halaman perbaikannya sendiri menampilkan error koneksi, tidak ada yang bisa diperbaiki — database sama sekali tidak bisa dijangkau, jadi Anda kembali ke Langkah 1 atau Langkah 2. Pada titik itu langkah yang paling andal adalah memulihkan database dari backup terbaru milik hosting Anda. Sebagian besar control panel menyimpan snapshot database harian otomatis; memulihkan dari tadi malam hampir selalu lebih cepat dan lebih aman daripada mengejar kerusakan yang bahkan tidak bisa Anda sambungi.

Saran yang aman Anda abaikan

“Instal ulang WordPress saja.” Error ini soal koneksi database, bukan file core. Menginstal ulang justru mengganti file yang baik-baik saja dan tidak menyentuh apa pun yang rusak.

“Naikkan PHP memory limit Anda.” Memori habis itu error yang berbeda dengan pesan yang berbeda. Menaikkan batasnya tidak berpengaruh pada koneksi database yang ditolak dan hanya menutupi fakta bahwa Anda belum pernah memeriksa kredensialnya.

“Bersihkan cache Anda.” Kegagalan terjadi di PHP sebelum cache mana pun sempat menyajikan halaman. Membersihkan cache tidak mengubah apa pun selama koneksinya ditolak; itu baru layak dilakukan setelah situs kembali normal.

“Edit langsung database-nya untuk memperbaiki.” Buru-buru memakai phpMyAdmin untuk menyunting tabel secara manual sebelum memastikan koneksinya benar-benar berfungsi adalah cara sebuah gangguan sementara berubah jadi kehilangan data permanen. Pastikan koneksinya dulu; sentuh datanya paling akhir, dan hanya dari backup.

Masih buntu?

Kalau kredensial terbukti benar lewat skrip uji, server menyala, dan perbaikan bisa terhubung serta tidak melaporkan error, tapi situs tetap menampilkan pesan itu, tersangka yang tersisa adalah plugin yang berbicara ke database lewat koneksinya sendiri — plugin caching atau database yang menyimpan alamat host usang. Ganti nama wp-content/plugins menjadi plugins-off lewat SFTP untuk menyingkirkannya. Kalau error-nya hilang, aktifkan lagi plugin satu per satu sampai error itu kembali.