Mengenal WordPress White Screen of Death

White screen of death adalah PHP fatal error yang tidak bisa Anda lihat. WordPress mengalami error fatal di tengah proses render, PHP berhenti, dan karena tampilan error dimatikan di server produksi, halaman malah tampil kosong tanpa memberi tahu penyebabnya. Cara memperbaikinya hampir tidak pernah dengan menebak-nebak: aktifkan debug log, buka wp-content/debug.log, lalu baca baris fatal terakhir. Baris itu menyebut file persisnya — hampir selalu sebuah plugin atau theme — dan satu baris itulah kunci seluruh perbaikannya.

Kenapa layarnya kosong

PHP punya pengaturan bernama display_errors. Di mesin pengembangan biasanya aktif, jadi error fatal akan menampilkan stack trace ke layar. Di server sungguhan pengaturan ini mati secara default, karena membocorkan path file dan pesan error ke pengunjung adalah masalah keamanan. Jadi ketika sesuatu memicu error fatal — memanggil fungsi yang sudah tidak ada, class yang tidak termuat, syntax error di update plugin — PHP mati dan tidak mengirim apa pun. Browser Anda merender dokumen kosong. Itulah “layar putih” tersebut.

Sejak WordPress 5.2 ada fatal error handler (WP_Fatal_Error_Handler) yang berusaha menangkap error semacam ini. Ketika berhasil, Anda tidak mendapat halaman kosong — melainkan pesan “There has been a critical error on this website,” plus email ke alamat admin yang sering kali memuat error sebenarnya beserta link ke Recovery Mode. Layar yang benar-benar kosong biasanya berarti error terjadi sebelum handler itu sempat berjalan: parse/syntax error (tertangkap saat kompilasi), must-use plugin yang rusak, atau error fatal di functions.php theme yang aktif. Bagaimanapun juga, penyebabnya tercatat di suatu tempat. Anda tinggal mengaktifkan pencatatannya.

Perbaiki, secara berurutan

1. Aktifkan log. Edit wp-config.php lewat SFTP dan tambahkan ini di atas baris /* That's all, stop editing! */:

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

WP_DEBUG_DISPLAY bernilai false menjaga error tetap tersembunyi dari halaman publik, sementara WP_DEBUG_LOG menuliskannya ke wp-content/debug.log. Muat ulang sekali halaman yang error untuk menghasilkan entri baru.

2. Baca fatal terakhir. Buka wp-content/debug.log dan lihat bagian paling bawah:

tail -n 30 wp-content/debug.log

Anda mencari baris seperti ini:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Path-nya menyebut biang keroknya: plugins/some-addon. Itulah jawabannya. Kalau trace-nya panjang atau pesannya membingungkan (Allowed memory size exhausted, Cannot redeclare, nama class yang tidak Anda kenali), tempel ke error log decoder kami — alat ini membuang bagian yang tidak penting, memberi tahu plugin atau theme mana yang ditunjuk path tersebut, dan menjelaskan arti dari jenis error spesifiknya.

3. Nonaktifkan komponen yang disebut. Anda tidak bisa mengakses /wp-admin, jadi lakukan lewat SFTP. Ganti nama folder plugin yang bermasalah, misalnya some-addon → some-addon.off. WordPress tidak bisa memuat folder yang tidak ditemukannya, jadi plugin itu ternonaktifkan dan situs kembali normal. Kalau log menunjuk ke theme Anda, ganti ke theme default dengan mengganti nama folder theme yang aktif — WordPress akan jatuh kembali ke twentytwentysomething bawaan.

4. Kalau log tidak mau menulis, berarti wp-content tidak dapat ditulisi, atau errornya di level server. Cek PHP error log milik host sebagai gantinya:

find . -name "error_log" -newermt "-1 hour"

Informasi yang sama, file yang berbeda. Stack cPanel/Apache sering menaruh error_log di root situs atau di direktori yang bermasalah.

Yang tidak boleh dilakukan

Jangan sekadar menaikkan memory limit. Saran yang paling sering diulang di internet adalah menaikkan WP_MEMORY_LIMIT ke 256M atau 512M. Itu hanya memperbaiki WSOD kalau log memang menyebut Allowed memory size of N bytes exhausted. Kalau errornya Call to undefined function, tambahan memori tidak ada gunanya — Anda mengubah pengaturan secara asal dan layarnya tetap putih. Baca log dulu, baru naikkan memori kalau memang memori yang dinyatakan sebagai masalahnya.

Jangan hapus cache lalu menganggapnya sebagai diagnosis. Layar putih terjadi karena PHP mati di server sebelum ada HTML apa pun. Aset cache yang basi tidak mungkin menyebabkan dokumen kosong. (Sebuah plugin caching yang rusak bisa — tapi log akan menyebutnya, itulah intinya.)

Jangan edit atau instal ulang core WordPress. Fatal itu hampir tidak pernah di wp-includes atau wp-admin; letaknya di plugin atau theme yang ditunjuk log. Menginstal ulang core itu lambat, berisiko, dan mengobati gejala yang belum Anda pastikan.

Jangan nonaktifkan semua plugin lalu aktifkan satu per satu secara buta. Membelah masalah (bisecting) memang berhasil, tapi itu jalan yang lambat. Log memberi tahu Anda folder persisnya dalam satu langkah. Gunakan metode “matikan semuanya” hanya kalau memang tidak ada error yang terbaca sama sekali.

Jangan biarkan display_errors aktif di produksi. Setelah situs kembali normal, hapus define debug tadi (atau kembalikan WP_DEBUG ke false). Error yang tampil ke pengunjung membocorkan path Anda.

Masih buntu?

Kalau log menyebut sebuah plugin tapi menonaktifkannya tidak membersihkan layar, berarti ada fatal kedua di bawah yang pertama — aktifkan kembali log dan baca baris terakhir yang baru; fatal itu bertumpuk. Kalau pesannya sendiri yang jadi tembok, masukkan ke error log decoder dan biarkan alat itu menerjemahkan jenis error dan path file-nya untuk Anda. Layar putih hanya tetap jadi misteri selama log-nya mati.