Rutin Matikan WP_DEBUG_LOG agar debug.log Tidak Membengkak dan Bocor ke Publik

Kalau kuota disk akun hosting tiba-tiba penuh padahal pemiliknya merasa tidak mengunggah apa-apa, salah satu tersangka yang sering ketemu adalah wp-content/debug.log. File ini muncul saat WP_DEBUG_LOG dinyalakan untuk debugging, lalu lupa dimatikan setelah masalahnya selesai. Ukuran file yang terus bertambah baru sebagian masalahnya. Kalau tidak diblokir, file ini juga bisa dibuka siapa saja lewat browser. Artikel ini tidak membahas cara debugging WordPress. Fokusnya ke hal yang lebih membosankan tapi sering terlewat: kapan log ini perlu nyala, bagaimana mengamankannya kalau memang harus nyala, dan bagaimana menjadikan pengecekannya rutinitas. Jangan sampai pengecekan baru dilakukan setelah disk penuh.

Apa yang sebenarnya dilakukan WP_DEBUG_LOG

WordPress punya tiga konstanta debug yang biasanya ditulis di wp-config.php. WP_DEBUG adalah saklar utamanya. Kalau nilainya true, WordPress menaikkan level error reporting PHP, jadi notice, warning, dan pesan deprecated ikut dilaporkan. Pesan deprecated adalah peringatan bahwa sebuah fungsi akan dihapus di versi mendatang. WP_DEBUG_DISPLAY mengatur apakah pesan itu tampil langsung di halaman, sedangkan WP_DEBUG_LOG mengatur apakah pesan itu ditulis ke file. Kalau WP_DEBUG_LOG diisi true, file tujuannya adalah wp-content/debug.log. Di versi WordPress yang lebih baru, nilainya juga bisa diisi path lengkap ke lokasi lain. Satu hal yang sering bikin bingung: WP_DEBUG_LOG hanya berpengaruh kalau WP_DEBUG juga true. Jadi mematikan WP_DEBUG biasanya sudah menghentikan penulisan log dari mekanisme bawaan WordPress. Kata "bawaan" di situ penting. Kalau WP_DEBUG sudah false tapi debug.log masih terus bertambah, berarti ada pihak lain yang menulis ke file itu. Kemungkinannya antara lain plugin yang memanggil fungsi error_log() dengan path tujuan sendiri, setting error_log di php.ini atau .user.ini yang mengarah ke file yang sama, atau plugin debugging yang menyalakan konstanta lewat caranya sendiri. Untuk kasus seperti ini, lihat isi baris-baris terbaru di file dan cari dari plugin atau file mana pesannya berasal. Jangan langsung menyimpulkan wp-config.php salah.

Kenapa debug.log membengkak dan kenapa bocornya berbahaya

File ini terus membesar karena WordPress tidak merotasinya. Rotasi artinya memotong atau mengarsipkan log lama secara berkala, dan WordPress tidak melakukannya. Setiap request yang memicu notice menambah baris baru. Di situs dengan plugin lama, atau setelah upgrade versi PHP, pesan deprecated bisa muncul di hampir setiap page load. Kalau dikalikan dengan traffic normal plus bot, file yang awalnya beberapa KB bisa membesar jauh lebih cepat dari perkiraan. Di shared hosting, pertumbuhan ini langsung memakan kuota disk akun. Efek sampingnya terasa juga di backup, karena file log besar ikut dicadangkan setiap kali backup jalan. Dari sisi support, pola yang cukup umum adalah keluhan kuota penuh atau email gagal masuk karena disk habis. Begitu dicek, penyumbang terbesarnya ternyata satu file debug.log yang tidak pernah dibaca siapa pun. Soal kebocoran, risikonya lebih serius. Folder wp-content memang bisa diakses publik karena di situ tema, plugin, dan file upload disajikan. Kalau tidak ada aturan yang memblokir, /wp-content/debug.log bisa dibuka seperti file teks biasa. Isinya bisa mencakup path absolut di server (sering kali termasuk username akun hosting), nama dan lokasi plugin yang error, potongan query database, sampai data yang tidak sengaja di-log oleh plugin, seperti alamat email atau parameter request. Semua ini memudahkan orang memetakan target. Path debug.log juga termasuk lokasi yang umum dicoba oleh scanner otomatis, jadi jangan berasumsi file itu aman hanya karena tidak ada yang tahu letaknya.

Tiga pilihan saat log masih dibutuhkan

Kalau debugging sudah selesai, jawabannya sederhana: matikan. Tapi ada situasi di mana log memang perlu tetap jalan, misalnya bug yang hanya muncul sesekali di production, atau saat kamu memantau efek upgrade PHP selama beberapa hari. Di situasi seperti itu ada tiga pilihan, dan dua yang terakhir bisa digabung.

Pertanyaan	Matikan	Pindahkan ke luar web root	Blokir lewat web server
Masih butuh log?	Tidak	Ya, untuk beberapa hari atau lebih	Ya, untuk sementara
Risiko file dibuka publik	Hilang	Sangat kecil, file tidak disajikan web server	Tergantung aturannya benar-benar aktif
Risiko disk penuh	Hilang	Tetap ada tanpa rotasi	Tetap ada tanpa rotasi
Yang perlu diubah	wp-config.php	wp-config.php dan folder yang bisa ditulis PHP	.htaccess atau konfigurasi Nginx

Mematikan berarti mengubah WP_DEBUG dan WP_DEBUG_LOG jadi false, atau menghapus barisnya. File debug.log yang sudah ada tidak hilang sendiri. Kalau isinya masih dibutuhkan untuk analisis, unduh dulu, baru hapus atau kosongkan.

Peringatan: menghapus atau mengosongkan file log tidak bisa dibatalkan. Pastikan tidak ada orang yang masih membutuhkan isinya sebelum kamu melakukannya.

Memindahkan berarti mengisi WP_DEBUG_LOG dengan path absolut ke folder yang tidak berada di bawah document root, misalnya folder logs di home direktori akun. Dari sisi keamanan, ini cara paling bersih karena web server tidak menyajikan file di luar document root. Syaratnya, folder itu harus bisa ditulis oleh user yang menjalankan PHP. Di setup cPanel di mana PHP berjalan sebagai user akun, membuat folder di home biasanya sudah cukup. Di setup lain izinnya bisa berbeda, tergantung PHP handler yang dipakai. Setelah mengubah, picu satu error kecil dan pastikan file baru benar-benar muncul di lokasi tujuan. Pastikan juga WP_DEBUG_DISPLAY diset false supaya error tidak ikut tampil di halaman pengunjung. Memblokir dipakai kalau path tidak bisa diubah, misalnya karena ada plugin yang memaksa lokasi default. Caranya, tambahkan aturan di web server. Di Apache 2.4, umumnya pakai blok Files yang menargetkan debug.log dengan isi Require all denied, ditaruh di .htaccess di root situs atau di dalam wp-content. Apache 2.2 yang lama memakai sintaks Order dan Deny, jadi sesuaikan dengan versinya. LiteSpeed biasanya membaca .htaccess yang sama, tapi tetap perlu diuji. Nginx sama sekali tidak membaca .htaccess. Di Nginx, aturannya harus berupa blok location yang cocok dengan debug.log dan berisi deny all di server block situs, lalu Nginx di-reload. Kelemahan opsi ini, perlindungannya hanya sebaik aturannya. Migrasi server atau ganti web server bisa menghilangkan aturan itu tanpa ada yang sadar. Sebagai pegangan kasar: kalau log perlu jalan lebih dari satu atau dua hari, pindahkan ke luar web root. Kalau hanya beberapa jam, blokir sudah cukup, asal kamu ingat mematikannya. Opsi pindah maupun blokir sama-sama tidak menyelesaikan soal ukuran. Di VPS, kamu bisa menambahkan path log itu ke logrotate. Di shared hosting yang tidak memberi akses ke situ, cukup pantau ukurannya secara berkala.

Cara mengecek log masih nyala dan bisa dibuka

Tiga pengecekan di bawah ini read-only, jadi aman dijalankan kapan saja. Perintah pertama bisa dijalankan dari mesin mana pun. Dua perintah berikutnya mengasumsikan akses root di server cPanel.

BASH

# 1. Apakah debug.log bisa diakses dari luar? Ganti example.com dengan domain kamu.
#    403 berarti diblokir, 404 berarti file tidak ditemukan, 200 berarti file bisa diunduh.
curl -sI 'https://example.com/wp-content/debug.log' | head -n 1

# 2. Cari debug.log berukuran besar di semua akun (100M hanya angka contoh).
find /home/*/public_html -type f -name 'debug.log' -size +100M -exec ls -lh {} \;

# 3. Lihat situs mana yang masih menulis konstanta debug di wp-config.php.
grep -H -E 'WP_DEBUG(_LOG|_DISPLAY)?' /home/*/public_html/wp-config.php

Kalau hasil pertama 200, buka URL-nya di browser untuk memastikan yang tampil memang isi log. Hasil 404 hanya berarti file tidak ada di lokasi default. Bisa jadi lognya sudah dipindah, bisa juga memang tidak pernah dibuat. Untuk perintah ketiga, perhatikan nilainya, bukan sekadar keberadaan barisnya. Baris yang berisi false tidak masalah. Path di atas mengasumsikan layout cPanel yang umum. Addon domain dan subdomain sering punya document root sendiri, dan wp-config.php kadang ditaruh satu level di atas folder WordPress. Sesuaikan path-nya dengan setup kamu. Di server tanpa control panel, lokasi document root tergantung konfigurasi web server masing-masing.

Menjadikan pengecekannya kebiasaan

Masalah debug.log jarang soal teknis. Hampir selalu soal lupa. Debugging selesai, ticket ditutup, dan konstanta di wp-config.php tetap true selama berbulan-bulan. Karena itu, solusinya lebih banyak berupa kebiasaan daripada konfigurasi. Kebiasaan paling sederhana adalah memperlakukan debug log seperti akses sementara. Setiap kali menyalakannya, tulis kapan harus dimatikan, baik di catatan ticket maupun sebagai komentar di samping konstanta di wp-config.php. Untuk tim support, masukkan langkah ini ke checklist penutupan ticket. Ticket yang melibatkan debug tidak boleh ditutup sebelum log dimatikan dan file lamanya diurus. Dengan begitu, tanggung jawabnya jelas dan tidak bergantung pada ingatan satu orang. Di level server, perintah find di atas bisa dijadwalkan lewat cron, misalnya seminggu sekali, dengan hasil dikirim ke email admin. Tidak perlu skrip rumit. Daftar file debug.log yang melewati batas ukuran tertentu sudah cukup sebagai pengingat. Tes curl sebaiknya diulang setiap kali ada migrasi, ganti web server, atau perubahan besar di konfigurasi virtual host, karena di momen-momen itulah aturan blokir paling sering hilang. Kalau memungkinkan, lakukan debugging di staging. Log yang tidak pernah dinyalakan di production tidak perlu diingat untuk dimatikan. Intinya, WP_DEBUG_LOG adalah alat sementara, bukan setting permanen. Nyalakan saat perlu, simpan lognya di luar web root kalau harus jalan lebih lama, blokir aksesnya kalau tidak bisa dipindah, dan pasang satu pengecekan terjadwal untuk menangkap yang terlupa. Ketiga langkah ini murah, dan jauh lebih ringan daripada membersihkan disk penuh atau menjelaskan kenapa path server dan data pengguna bisa dibaca dari browser.