Cara Membuat dan Mengakses Log Error untuk WordPress (3 Metode)

Log kesalahan WordPress adalah catatan diagnostik yang merekam kesalahan PHP, pengecualian fatal, kegagalan database, konflik plugin, dan ketidakcocokan tema saat terjadi di server Anda. Mengakses dan menginterpretasikan log ini adalah cara tercepat untuk mengidentifikasi akar penyebab halaman yang rusak, layar putih kematian, atau regresi performa yang tidak terlihat — tanpa menebak-nebak atau menonaktifkan plugin satu per satu.

Panduan ini mencakup tiga metode yang telah diuji di produksi untuk mengaktifkan, menemukan, dan membaca log kesalahan WordPress: tumpukan WP_DEBUG bawaan, log tingkat server melalui panel kontrol hosting Anda, dan penampil log berbasis plugin. Setiap metode cocok untuk tingkat akses dan kasus penggunaan yang berbeda, dan ketiganya dijelaskan dengan jalur file yang tepat, sintaks konfigurasi, dan pertimbangan keamanan.

Mengapa Log Kesalahan WordPress Penting

WordPress berjalan di PHP, yang menghasilkan beberapa kelas pesan runtime: kesalahan fatal (eksekusi berhenti), peringatan (eksekusi berlanjut tetapi ada yang salah), pemberitahuan (informasional, sering menunjukkan kode yang sudah usang), dan pesan deprecated (fungsi yang dijadwalkan untuk dihapus). Secara default, tidak ada yang ditulis ke log persisten pada sebagian besar konfigurasi produksi — semuanya ditekan atau ditampilkan ke browser, yang merupakan risiko keamanan.

Tanpa log, pembaruan plugin yang memperkenalkan kesalahan fatal hanya menghasilkan layar kosong. Pustaka SMTP yang salah dikonfigurasi secara diam-diam menggagalkan pengiriman email. Pelanggaran batas memori mematikan pemuatan halaman tanpa jejak yang terlihat. Log kesalahan mengubah kegagalan tak terlihat ini menjadi entri bertanda waktu, bereferensi file, dan bernomor baris yang dapat segera Anda tindaklanjuti.

Metode 1: Aktifkan Mode Debug WordPress melalui wp-config.php

WordPress dilengkapi dengan subsistem debugging bawaan yang dikendalikan oleh sekumpulan konstanta PHP yang didefinisikan dalam wp-config.php. Ini adalah metode paling tepat karena menangkap kesalahan khusus WordPress, termasuk yang dilempar oleh API plugin, pemuat tema, dan lapisan abstraksi database (wpdb).

Langkah 1: Temukan dan Buka wp-config.php

Hubungkan ke server Anda melalui SFTP (lebih disukai daripada FTP biasa untuk keamanan) menggunakan klien seperti FileZilla atau Cyberduck, atau buka File Manager penyedia hosting Anda. Navigasikan ke direktori root WordPress, biasanya /public_html/ atau /var/www/html/. File wp-config.php berada di root direktori ini.

Jika Anda memiliki akses SSH, Anda dapat mengeditnya langsung:

nano /var/www/html/wp-config.php

Langkah 2: Konfigurasi Konstanta Debug

Temukan baris yang ada:

define( 'WP_DEBUG', false );

Ganti seluruh blok dengan konfigurasi berikut, yang mengaktifkan logging tanpa mengekspos kesalahan kepada pengunjung situs:

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

Apa yang dilakukan setiap konstanta:

• WP_DEBUG — mengaktifkan mesin debugging WordPress dan mengaktifkan pelaporan kesalahan PHP pada level E_ALL.
• WP_DEBUG_LOG — menulis semua kesalahan yang ditangkap ke file log alih-alih (atau selain) ke layar.
• WP_DEBUG_DISPLAY — ketika diatur ke false, menekan output di layar. Ini sangat penting pada situs produksi; tanpanya, pemberitahuan PHP membocorkan jalur file internal dan nama variabel kepada pengunjung.
• display_errors — direktif PHP yang mendasarinya; mengaturnya ke 0 melalui ini_set memberikan lapisan penekanan kedua jika plugin atau tema mengganti WP_DEBUG_DISPLAY.

Langkah 3: Temukan File Log Debug

Dengan WP_DEBUG_LOG diatur ke true, WordPress menulis kesalahan ke:

/wp-content/debug.log

File ini dibuat secara otomatis pada kesalahan pertama yang dicatat. Anda dapat melihatnya melalui SFTP atau SSH:

tail -f /var/www/html/wp-content/debug.log

Flag tail -f mengalirkan entri baru secara real time, yang sangat berharga saat mereproduksi kesalahan tertentu secara interaktif.

Langkah 4: Gunakan Jalur Log Kustom (Direkomendasikan untuk Keamanan)

Jalur debug.log default dapat diakses secara publik jika server web Anda tidak memblokirnya secara eksplisit. Server yang salah dikonfigurasi akan menyajikan https://yourdomain.com/wp-content/debug.log kepada semua pengunjung, mengekspos jalur internal, awalan tabel database, dan nama kelas.

Opsi A — Pindahkan file log ke luar web root:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Buat direktori target dan atur izin:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Opsi B — Blokir jalur default melalui .htaccess (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Opsi C — Setara Nginx di blok server Anda:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Langkah 5: Nonaktifkan Mode Debug Setelah Pemecahan Masalah

Jangan pernah membiarkan WP_DEBUG diatur ke true pada situs langsung lebih lama dari yang diperlukan. Setelah masalah teratasi:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Membiarkan mode debug aktif pada situs produksi menurunkan performa (PHP memproses setiap pemberitahuan E_ALL) dan dapat mengekspos jejak tumpukan yang sensitif jika WP_DEBUG_DISPLAY secara tidak sengaja diatur ke true.

Metode 2: Akses Log Kesalahan Tingkat Server melalui Panel Kontrol Hosting Anda

Kesalahan WordPress yang terjadi sebelum bootstrap WordPress selesai — seperti wp-config.php yang rusak, ketidakcocokan versi PHP, atau koneksi database yang gagal — tidak akan pernah muncul di debug.log karena WordPress itu sendiri tidak pernah dimuat. Untuk ini, Anda memerlukan log kesalahan PHP server atau log kesalahan Apache/Nginx.

Hosting Berbasis cPanel

Jika lingkungan hosting Anda menggunakan VPS dengan cPanel, log kesalahan dapat diakses melalui antarmuka panel kontrol:

1. Masuk ke cPanel.
2. Navigasikan ke Metrics > Errors.
3. Panel menampilkan 300 baris terakhir dari log kesalahan Apache untuk akun Anda.

Untuk file log lengkap, gunakan File Manager cPanel atau hubungkan melalui SFTP dan navigasikan ke:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Nama file yang tepat bervariasi berdasarkan konfigurasi server, tetapi polanya konsisten di sebagian besar instalasi cPanel.

Hosting Berbasis Plesk

Di Plesk, navigasikan ke Websites & Domains > pilih domain Anda > Logs. Anda dapat memfilter berdasarkan jenis log (akses, kesalahan, PHP) dan mengunduh file log lengkap.

Akses Server Langsung (VPS atau Dedicated)

Pada lingkungan VPS Hosting atau Dedicated Server di mana Anda memiliki akses root, lokasi log bergantung pada tumpukan Anda:

Untuk memantau log PHP-FPM secara real time:

tail -f /var/log/php8.2-fpm.log

Untuk mencari kesalahan fatal khusus WordPress di seluruh log Apache:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Mengonfigurasi Logging Kesalahan PHP di Tingkat Server

Jika kesalahan PHP tidak ditulis ke log, periksa konfigurasi php.ini Anda:

php --ini | grep "Loaded Configuration"

Buka file php.ini yang teridentifikasi dan verifikasi atau atur:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Mulai ulang PHP-FPM setelah perubahan:

systemctl restart php8.2-fpm

Atau, ganti pengaturan PHP per situs menggunakan file .htaccess (hanya Apache):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Metode 3: Gunakan Plugin Logging Kesalahan WordPress

Untuk lingkungan di mana akses server langsung dibatasi — seperti Shared Web Hosting — atau untuk tim di mana administrator non-teknis perlu meninjau kesalahan tanpa akses SSH, plugin WordPress menyediakan alternatif yang layak.

Plugin yang Direkomendasikan

• WP Log Viewer — membaca file debug.log yang ada dan menampilkannya di admin WordPress dengan pemfilteran dan pencarian.
• Error Log Monitor — menambahkan widget dasbor yang menampilkan kesalahan terbaru dan dapat mengirim peringatan email saat kesalahan baru dicatat.
• Query Monitor — melampaui logging kesalahan untuk memprofilkan kueri database, panggilan HTTP API, hook, dan tag kondisional. Penting untuk debugging performa.
• Health Check & Troubleshooting — plugin resmi WordPress.org; mengaktifkan mode pemecahan masalah yang mengaktifkan tema default dan menonaktifkan semua plugin hanya untuk sesi Anda, tanpa memengaruhi pengunjung lain.

Menginstal dan Mengonfigurasi Error Log Monitor

1. Di admin WordPress, buka Plugins > Add New.
2. Cari Error Log Monitor dan klik Install Now, lalu Activate.
3. Navigasikan ke Settings > Error Log Monitor.
4. Atur jalur file log. Jika Anda telah memindahkan debug.log ke luar web root, masukkan jalur server absolut di sini.
5. Konfigurasikan frekuensi peringatan email jika Anda ingin notifikasi untuk jenis kesalahan baru.

Plugin membaca file debug.log yang sama yang ditulis oleh WP_DEBUG_LOG. Plugin ini tidak membuat mekanisme logging terpisah — ini adalah penampil. Artinya WP_DEBUG dan WP_DEBUG_LOG masih harus diaktifkan di wp-config.php agar plugin dapat menampilkan sesuatu.

Keterbatasan kritis: Plugin dimuat setelah WordPress melakukan bootstrap. Kesalahan apa pun yang mencegah WordPress dimuat (kegagalan koneksi database, file inti yang rusak, versi PHP yang tidak kompatibel) tidak akan terlihat di penampil log berbasis plugin mana pun. Untuk skenario tersebut, Metode 2 adalah satu-satunya pilihan.

Perbandingan: Tiga Metode Logging Kesalahan WordPress

Membaca dan Menginterpretasikan Entri Log Kesalahan WordPress

Entri debug.log mentah terlihat seperti ini:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Cara membacanya:

• Stempel waktu dalam UTC — konversi ke zona waktu lokal server Anda jika diperlukan.
• PHP Fatal error berarti eksekusi terhenti. Halaman yang memicu ini mengembalikan kesalahan 500 atau layar kosong.
• Call to undefined function get_field() berarti plugin Advanced Custom Fields dinonaktifkan atau dimuat setelah functions.php tema mencoba memanggilnya.
• Jejak tumpukan menunjukkan file dan nomor baris yang tepat. Mulai debugging di baris 47 dari functions.php.

Pola kesalahan umum dan penyebabnya:

• PHP Warning: require(): Failed opening required — jalur file salah atau file hilang. Sering disebabkan oleh plugin yang mereferensikan file yang telah dihapus.
• PHP Deprecated: Function _register_controls is deprecated — plugin atau tema menggunakan API yang sudah usang. Tidak fatal, tetapi menunjukkan plugin yang belum diperbarui untuk versi WordPress/Elementor saat ini.
• WordPress database error ... for query — kueri wpdb gagal. Periksa ketidakcocokan awalan tabel atau tabel yang rusak.
• Maximum execution time of 30 seconds exceeded — skrip berjalan terlalu lama. Umum terjadi dengan impor besar, kueri yang tidak dioptimalkan, atau panggilan API eksternal yang habis waktu.
• Allowed memory size of X bytes exhausted — PHP mencapai batas memori. Tingkatkan memory_limit di php.ini atau identifikasi plugin yang bocor memori.

Praktik Terbaik untuk Mengelola Log Kesalahan WordPress

Rotasi log untuk mencegah kehabisan disk. Situs WordPress yang sibuk diserang atau dengan kesalahan berulang dapat menghasilkan ratusan megabyte data log per hari. Di server Linux, konfigurasikan logrotate:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Jangan pernah melakukan commit debug.log ke version control. Tambahkan ke .gitignore:

wp-content/debug.log

Audit wp-config.php Anda setelah setiap migrasi server. Migrasi hosting sering mereset WP_DEBUG ke false atau memperkenalkan template wp-config.php baru yang menimpa konstanta Anda.

Gunakan SAVEQUERIES untuk debugging tingkat database. Tambahkan konstanta ini bersama WP_DEBUG untuk mencatat setiap kueri SQL yang dieksekusi WordPress:

define( 'SAVEQUERIES', true );

Kemudian periksa $wpdb->queries di template kustom atau melalui Query Monitor. Nonaktifkan segera setelah digunakan — ini menyimpan setiap kueri di memori dan secara signifikan meningkatkan konsumsi RAM.

Korelasikan stempel waktu log dengan peristiwa deployment. Jika jenis kesalahan baru muncul, periksa apakah itu bertepatan dengan pembaruan plugin, pembaruan inti WordPress, atau perubahan versi PHP di server. Sebagian besar panel kontrol hosting mencatat perubahan versi PHP dalam jejak audit terpisah.

Matriks Keputusan: Metode Mana yang Digunakan

Daftar Periksa Poin Penting Teknis

• Atur WP_DEBUG_DISPLAY ke false sebelum mengaktifkan WP_DEBUG_LOG pada situs mana pun dengan lalu lintas langsung.
• Pindahkan debug.log ke luar web root atau blokir melalui aturan server — jalur default dapat diakses secara publik.
• Gunakan tail -f pada file log saat mereproduksi kesalahan secara interaktif; ini menghilangkan kebutuhan untuk me-refresh file secara manual.
• Log PHP dan Apache/Nginx tingkat server adalah satu-satunya sumber kebenaran untuk kesalahan yang terjadi sebelum WordPress dimuat.
• Penampil log berbasis plugin memerlukan WP_DEBUG_LOG untuk aktif — mereka adalah pembaca, bukan penulis.
• Terapkan rotasi log pada server mana pun di mana WP_DEBUG_LOG diaktifkan lebih dari beberapa jam.
• Jangan pernah membiarkan SAVEQUERIES diaktifkan di produksi; ini adalah beban memori dan performa.
• Setelah menyelesaikan masalah, atur semua konstanta debug kembali ke false dan verifikasi dengan permintaan browser bahwa tidak ada pemberitahuan PHP yang muncul di sumber halaman.

—

Pertanyaan yang Sering Diajukan

Di mana file log debug WordPress berada secara default?

WordPress menulis log debug ke /wp-content/debug.log relatif terhadap direktori root WordPress Anda. Jalur ini hanya dibuat setelah kesalahan pertama dicatat dan hanya ketika WP_DEBUG dan WP_DEBUG_LOG diatur ke true di wp-config.php. Anda dapat mengganti jalur dengan memberikan string jalur file absolut sebagai nilai WP_DEBUG_LOG alih-alih true.

Apakah aman mengaktifkan WP_DEBUG pada situs produksi langsung?

Ini aman hanya jika WP_DEBUG_DISPLAY secara eksplisit diatur ke false dan display_errors diatur ke 0. Tanpa dua pengaturan ini, kesalahan PHP — termasuk jalur file internal dan nama tabel database — dirender langsung di sumber HTML setiap halaman. Selalu pasangkan WP_DEBUG true dengan WP_DEBUG_DISPLAY false pada situs mana pun dengan lalu lintas publik.

Mengapa file debug.log saya kosong meskipun WP_DEBUG diaktifkan?

Penyebab paling umum adalah: proses server web tidak memiliki izin tulis ke direktori /wp-content/; WP_DEBUG_LOG diatur ke false atau tidak ada di wp-config.php; atau kesalahan terjadi di tingkat server sebelum WordPress dimuat, artinya akan muncul di log Apache atau PHP-FPM daripada debug.log. Periksa izin direktori dengan ls -la wp-content/ dan verifikasi konstanta didefinisikan dalam urutan yang benar di wp-config.php.

Apa perbedaan antara WP_DEBUG_LOG dan log kesalahan PHP server?

WP_DEBUG_LOG adalah konstanta tingkat WordPress yang merutekan kesalahan yang ditangkap oleh penangan kesalahan kustom WordPress ke debug.log. Log kesalahan PHP server (dikonfigurasi melalui error_log di php.ini) menangkap semua kesalahan PHP di tingkat interpreter, termasuk yang terjadi sebelum WordPress diinisialisasi. Pada server yang dikonfigurasi dengan benar, kedua log aktif secara bersamaan dan saling melengkapi.

Bisakah saya mengaktifkan logging kesalahan pada shared hosting tanpa akses SSH?

Ya. Anda dapat mengedit wp-config.php melalui File Manager penyedia hosting Anda di cPanel atau Plesk, mengaktifkan WP_DEBUG dan WP_DEBUG_LOG, lalu membaca debug.log melalui antarmuka File Manager yang sama. Untuk log tingkat server pada Shared Web Hosting, gunakan bagian Errors di bawah Metrics di cPanel. Jika Anda memerlukan kontrol lebih granular atas konfigurasi PHP dan jalur log, meningkatkan ke paket VPS Hosting memberi Anda akses langsung ke php.ini dan akses SSH penuh ke semua file log.