Lokasi Debug Log WordPress: Di Mana debug.log Berada dan Cara Memindahkannya

WordPress menulis debug log-nya ke wp-content/debug.log secara default — dengan path absolut /path/to/your/site/wp-content/debug.log di disk. File itu belum ada sampai benar-benar ada sesuatu yang tercatat, dan hanya ditulis kalau WP_DEBUG bernilai true serta WP_DEBUG_LOG diaktifkan di wp-config.php. Lokasi default itu sekaligus masalah keamanan yang nyata, karena di sebagian besar hosting siapa pun bisa mengunduhnya lewat browser.

Tiga konstanta dan tugas masing-masing

Ketiganya ditulis di wp-config.php, di atas baris /* That's all, stop editing! Happy blogging. */. Apa pun yang ditambahkan di bawah baris itu dijalankan setelah WordPress selesai booting, jadi diabaikan.

Konstanta	Default	Fungsinya
WP_DEBUG	false	Sakelar utama. Menaikkan level pelaporan error PHP sehingga notice, warning, dan deprecation ikut tampil. Tidak ada satu pun di daftar ini yang jalan tanpanya.
WP_DEBUG_LOG	false	Mengirim error ke sebuah file. true berarti wp-content/debug.log. Kalau diisi string, isinya diperlakukan sebagai path file tujuan.
WP_DEBUG_DISPLAY	true	Mencetak error ke dalam HTML halaman, terlihat oleh setiap pengunjung.

Bagian yang paling sering salah dipahami adalah ketergantungannya. WP_DEBUG_LOG dibaca di dalam cabang WP_DEBUG pada kode startup WordPress. Kalau WP_DEBUG bernilai false, menyetel WP_DEBUG_LOG ke true sama sekali tidak berefek — tidak ada file, tidak ada error, tidak ada peringatan. Kalau Anda sudah menambahkan WP_DEBUG_LOG tapi tidak ada log yang muncul, periksa WP_DEBUG lebih dulu.

Konfigurasi yang aman untuk situs live:

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

Kalau WP_DEBUG sudah didefinisikan di bagian atas file — biasanya memang sudah ada, bernilai false — edit baris yang sudah ada itu, jangan menambahkan define() kedua. Mendefinisikan konstanta yang sama dua kali memicu PHP warning, yang di situs dengan tampilan error menyala akan mendarat tepat di bagian atas halaman Anda.

Kenapa WP_DEBUG_DISPLAY harus false di produksi

Dengan tampilan menyala, error PHP dicetak langsung ke dalam respons HTML. Satu notice deprecation dari sebuah tema saja sudah cukup untuk memamerkan path filesystem absolut server Anda ke setiap pengunjung. Error database akan mencetak nama tabel dan potongan query. Lebih parah lagi, output yang muncul sebelum header dikirim merusak redirect, merusak respons REST dan AJAX yang mengharapkan JSON bersih, dan bisa menghasilkan layar putih yang kemudian orang tuduhkan ke plugin.

Satu detail yang perlu diketahui: menyetel WP_DEBUG_DISPLAY ke null tidak sama dengan false. null menyuruh WordPress membiarkan pengaturan display_errors PHP apa adanya dan mengikuti apa pun yang dikonfigurasi server. false memaksanya mati secara aktif. Di situs produksi, pakai false dan tambahkan baris ini_set di atas sebagai pengaman ganda, karena sebuah plugin bisa saja menyalakan display_errors lagi di tengah request.

Lokasi default bisa diunduh siapa saja

wp-content/debug.log berada di dalam web root. Tidak ada apa pun di instalasi WordPress standar yang memblokir request langsung ke file itu. Di setup Apache atau nginx pada umumnya, https://situsanda.com/wp-content/debug.log mengembalikan isinya sebagai teks biasa. Debug log memuat path server absolut, isi dalaman plugin dan tema, error database dengan teks query asli, dan kadang nilai yang dilewatkan ke fungsi yang gagal. Itu bahan pengintaian gratis untuk siapa pun yang menebak URL-nya — dan URL itu termasuk yang pertama dicoba oleh scanner otomatis.

Ada dua cara menanganinya. Yang lebih baik adalah memindahkan lognya.

Pindahkan log dengan menuliskan path

Sejak WordPress 5.1, WP_DEBUG_LOG bisa menerima path file berupa string, bukan hanya boolean. Arahkan ke lokasi di luar document root:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Ada tiga aturan untuk path itu. Gunakan path absolut — path relatif dihitung dari working directory PHP, yang berbeda-beda tergantung request dan server, jadi Anda akan kehilangan jejak filenya. Foldernya harus sudah ada; PHP tidak akan membuatnya, dan kalau file-nya gagal dibuka, kegagalannya senyap. Dan folder itu harus bisa ditulisi oleh user PHP, yang di shared hosting bukan akun yang sama dengan akun login SFTP Anda.

Kalau hosting Anda mengurung semuanya di dalam web root dan tidak ada tempat di atasnya yang bisa ditulisi, biarkan path default lalu blokir aksesnya di level server. Untuk Apache:

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

Itu ditaruh di file .htaccess di dalam wp-content, bukan yang di root — WordPress menulis ulang .htaccess root setiap kali Anda menyimpan permalink dan bisa menghapus tambahan Anda. Di nginx, .htaccess sama sekali tidak berfungsi; Anda butuh location block di konfigurasi server, yang di managed hosting biasanya berarti minta bantuan tim support.

Jujurlah soal hasil dari pemblokiran itu: filenya tetap ada di disk, di folder yang disajikan web server. Celah path traversal di plugin mana pun masih bisa membacanya. Memindahkannya keluar dari web root tetap solusi yang lebih kuat.

Membaca dan memantau isinya

Lewat SSH, pantau langsung sambil Anda mengulang bug-nya:

tail -f wp-content/debug.log

Picu errornya di tab lain, dan baris baru akan muncul begitu ditulis. Untuk melihat kejadian terbaru saja, atau menyaring satu plugin tertentu:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

PHP menambahkan entri di akhir file, jadi bacalah dari bawah ke atas. Setiap entri diberi stempel waktu UTC, yang tidak akan cocok dengan pengaturan zona waktu WordPress Anda — jangan sampai itu membuat Anda mengira sedang melihat entri lama.

Dengan WP-CLI, Anda bisa mengubah konstantanya tanpa mengedit file secara manual:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Flag --raw itu penting — tanpanya nilainya ditulis sebagai string "true", bukan boolean. Untuk bentuk path, hilangkan --raw supaya ditulis sebagai string berkutip.

Tidak punya SSH? Unduh filenya lewat SFTP atau buka di File Manager hosting. Hindari plugin yang menampilkan isi log di dalam wp-admin kecuali Anda benar-benar memercayainya; Anda sedang memberi sebuah plugin akses baca ke file yang penuh isi dalaman server.

Kalau Anda ingin blok wp-config yang persis sesuai setup Anda, lengkap dengan path aman di luar root dan aturan servernya, generator debug log WordPress akan menyusunkannya untuk Anda.

Matikan lagi kalau sudah selesai

Tidak ada bagian WordPress core yang merotasi atau memangkas debug.log. Di situs yang melempar notice setiap kali halaman dimuat, file itu tumbuh tanpa batas dan bisa memenuhi disk — yang menjatuhkan situs jauh lebih parah daripada bug yang sedang Anda kejar. Nyalakan logging, ulangi masalahnya, baca lognya, lalu kembalikan WP_DEBUG ke false.

Untuk mengosongkan file tanpa menghapusnya:

: > wp-content/debug.log

Kalau lognya tetap kosong

Telusuri urutan berikut. WP_DEBUG bernilai false — penyebab paling umum, dan diam-diam mematikan semua yang lain. Konstantanya ada di bawah baris “stop editing” di wp-config.php. Izin file — PHP tidak bisa menulis ke wp-content, atau ke folder khusus yang Anda tentukan. Fatal error sebelum wp-config selesai dimuat, misalnya syntax error di file konfigurasi itu sendiri, terjadi terlalu awal untuk ditangkap logging WordPress; kejadian seperti itu masuk ke PHP error log milik server. Hosting Anda menimpanya — sebagian platform managed mengunci pengaturan error_log PHP atau mengarahkan logging ke dashboard mereka sendiri, sehingga konfigurasi Anda sebenarnya sudah benar dan outputnya hanya ada di tempat lain. Periksa penampil log milik hosting sebelum menyimpulkan konfigurasi Anda yang rusak.