Cara Mengaktifkan Debug Mode WordPress untuk Cari Error

Website WordPress kamu tiba-tiba putih kosong, muncul pesan "There has been a critical error on this website", atau satu fitur berhenti bekerja tanpa penjelasan? Jawabannya hampir selalu tersimpan di pesan error PHP yang disembunyikan WordPress secara bawaan. Debug mode adalah cara resmi untuk memunculkan pesan itu.

Caranya cukup menambahkan beberapa baris di wp-config.php. Kuncinya, error dicatat ke file log, bukan ditampilkan ke semua pengunjung, dan semuanya dimatikan lagi begitu masalah ketemu.

Apa saja konstanta debug di WordPress?

Sebelum mulai, kenali lima konstanta yang tercantum di dokumentasi resmi WordPress:

WP_DEBUG_LOG dan WP_DEBUG_DISPLAY hanya berpengaruh bila WP_DEBUG bernilai true.

Langkah mengaktifkan debug mode

1. Cadangkan wp-config.php

Buka File Manager di cPanel (atau sambungkan lewat SFTP), masuk ke folder instalasi WordPress, biasanya public_html. Unduh atau salin wp-config.php menjadi wp-config.php.bak. Satu titik koma yang hilang di file ini bisa membuat seluruh situs error, jadi cadangan ini penting. Kalau belum terbiasa dengan File Manager, lihat cara upload dan mengelola file lewat File Manager.

2. Cari baris WP_DEBUG yang sudah ada

Buka wp-config.php dengan editor. Hampir semua instalasi sudah punya baris ini:

define( 'WP_DEBUG', false );

Jangan menambah baris kedua dengan nama yang sama, karena PHP akan memberi peringatan konstanta sudah didefinisikan. Ganti baris yang ada.

3. Ganti dengan konfigurasi debug ke log

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Semua baris ini harus berada di atas komentar /* That's all, stop editing! Happy publishing. */. Baris @ini_set memastikan PHP juga tidak menampilkan error, berjaga-jaga bila pengaturan server berbeda.

4. Ulangi masalahnya

Buka halaman yang error, klik tombol yang gagal, atau jalankan lagi proses yang bermasalah. Setiap error yang muncul sekarang tercatat. Untuk masalah yang jarang terjadi, biarkan debug menyala beberapa jam sambil memantau ukuran file log.

5. Baca wp-content/debug.log

Buka folder wp-content dan cari file debug.log. Isinya kira-kira seperti ini:

[14-Nov-2026 02:15:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function contoh_fungsi() in /home/user/public_html/wp-content/plugins/nama-plugin/inc/core.php:42

Bagian yang paling berguna adalah jenis error dan path file. Path di atas langsung menunjuk folder plugins/nama-plugin, jadi tersangka utamanya plugin itu.

6. Tindak lanjuti sesuai jenis error

• Fatal error menghentikan halaman. Biasanya dari plugin atau tema yang tidak cocok dengan versi PHP atau versi WordPress. Nonaktifkan plugin tersebut dengan mengganti nama foldernya, misalnya nama-plugin-off.
• Warning dan Notice umumnya tidak merusak halaman, tapi bisa memberi petunjuk. Banyak notice dari plugin lama aman diabaikan.
• Deprecated berarti kode memakai fungsi yang akan dihapus. Belum rusak sekarang, tapi tanda plugin perlu diperbarui sebelum kamu menaikkan versi PHP.
• Allowed memory size exhausted artinya batas memori PHP habis. Penyebabnya bisa plugin yang boros atau batas memori yang terlalu kecil.

Untuk gejala layar kosong secara khusus, ada pembahasan lengkap di WordPress layar putih kosong. Kalau error justru muncul sebagai HTTP 500, lihat juga cara melacak error 500 di website PHP, karena log PHP di level server kadang mencatat hal yang tidak tertangkap debug.log.

7. Matikan debug dan hapus log

Begitu penyebab ketemu dan diperbaiki, kembalikan baris menjadi:

define( 'WP_DEBUG', false );

Hapus juga baris WP_DEBUG_LOG dan WP_DEBUG_DISPLAY (atau biarkan, karena tidak berpengaruh saat WP_DEBUG false), lalu hapus file debug.log.

Kenapa debug.log tidak boleh dibiarkan?

Lokasi bawaan wp-content/debug.log berada di folder yang bisa diakses publik. Siapa pun yang menebak alamat contoh.com/wp-content/debug.log bisa membaca path server, nama plugin, dan potongan data yang ikut tercatat. Informasi semacam ini memudahkan penyerang memetakan situsmu.

Ada dua cara mengurangi risikonya. Pertama, sejak WordPress 5.1, WP_DEBUG_LOG boleh diisi path file, sehingga log bisa disimpan di luar folder publik:

define( 'WP_DEBUG_LOG', '/home/user/logs/wp-debug.log' );

Kedua, di server Apache atau LiteSpeed, blokir akses ke file log lewat .htaccess di folder wp-content:

<Files "debug.log">
    Require all denied
</Files>

Tetap saja, cara paling aman adalah mematikan debug setelah selesai.

Bagaimana kalau tidak bisa masuk wp-admin?

Semua langkah di atas dilakukan lewat file, jadi tetap bisa walaupun dashboard tidak terbuka. Selain itu, sejak versi 5.2 WordPress punya fitur perlindungan fatal error: saat situs mengalami fatal error, WordPress mengirim email berisi tautan mode pemulihan ke alamat email admin. Lewat tautan itu kamu bisa masuk dan menonaktifkan plugin atau tema penyebabnya. Periksa folder spam bila email tidak terlihat.

Checklist singkat sebelum menutup sesi debug:

• wp-config.php sudah dicadangkan sebelum diedit.
• Penyebab error tercatat dan sudah diperbaiki.
• WP_DEBUG kembali false.
• File debug.log sudah dihapus atau dipindahkan ke luar folder publik.