Cara Mengatasi White Screen of Death WordPress di VPS

The Last Digital
Update: ... minutes read

Anda membuka situs WordPress dan yang muncul hanya halaman putih kosong. Tidak ada pesan error, tidak ada menu, tidak ada apa-apa. Inilah yang disebut komunitas WordPress sebagai White Screen of Death (WSOD) — dan kabar baiknya, hampir selalu ada penyebab yang bisa ditemukan.

Jawaban Singkat

Layar putih biasanya berarti PHP mengalami fatal error sebelum halaman sempat dirender, dan WordPress sengaja menyembunyikan pesan error itu di situs produksi. Aktifkan pencatatan error ke file log (bukan ke layar), baca wp-content/debug.log, lalu nonaktifkan plugin atau tema yang ditunjuk log tersebut.

Kenapa Layar Menjadi Putih?

WordPress menyembunyikan detail error karena detail itu bisa mengungkap jalur file dan versi perangkat lunak — informasi yang berguna bagi penyerang. Akibatnya, dari browser Anda hanya melihat kekosongan. Penyebab paling umum:

PenyebabTanda yang menyertai
Plugin tidak kompatibel / konflikWSOD muncul setelah instal atau update plugin
Tema rusak (misalnya functions.php error)WSOD muncul setelah ganti/update tema
Memori PHP habisLog menyebut “Allowed memory size exhausted”
File inti WordPress korupWSOD muncul setelah update inti gagal
Database bermasalahDisertai error koneksi database (topik terpisah di situs ini)

Persiapan

  • Buat backup file dan database sebelum mengubah apa pun.
  • Siapkan akses SSH atau SFTP/file manager ke VPS.
  • Catat perubahan terakhir: plugin, tema, atau update apa yang terjadi sebelum WSOD.

Langkah 1: Periksa Email Recovery Mode Terlebih Dahulu

Sejak WordPress 5.2, ketika fatal error terjadi di endpoint yang dilindungi (misalnya wp-login atau area admin), WordPress mengirim email ke admin dengan tautan Recovery Mode. Di mode ini, komponen yang rusak dijeda sehingga Anda bisa masuk dashboard dan menonaktifkannya. Periksa kotak masuk (termasuk spam) sebelum mengutak-atik file. Jika email tidak ada — misalnya error hanya terjadi di halaman depan — lanjut ke langkah berikutnya.

Langkah 2: Aktifkan Log Debug dengan Aman

Buka wp-config.php di root instalasi WordPress dan tambahkan baris berikut sebelum baris That's all, stop editing! Happy publishing.:

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

Kombinasi ini penting: WP_DEBUG_LOG hanya berpengaruh bila WP_DEBUG bernilai true, dan WP_DEBUG_DISPLAY bernilai false menjaga error tidak tampil ke pengunjung. Jangan pernah mengaktifkan tampilan error di situs live.

Muat ulang halaman yang bermasalah, lalu buka wp-content/debug.log. Baris terakhir biasanya berbentuk:

Fatal error: ... in /.../wp-content/plugins/nama-plugin/file.php on line 123

Nama file itulah petunjuk utama Anda.

Langkah 3: Nonaktifkan Tersangka

  1. Jika log menunjuk plugin: ganti nama folder plugin itu lewat SSH/SFTP (misalnya nama-plugin menjadi nama-plugin-off). Muat ulang situs.
  2. Jika tidak bisa masuk wp-admin sama sekali: ganti nama seluruh folder wp-content/plugins menjadi plugins-off. Ini menonaktifkan semua plugin sekaligus. Jika situs hidup kembali, penyebabnya plugin — aktifkan satu per satu sampai WSOD kembali, dan itulah pelakunya.
  3. Jika log menunjuk tema: ganti ke tema default WordPress (misalnya Twenty Twenty-Five) lewat dashboard, atau ganti nama folder tema bermasalah lewat file manager sehingga WordPress jatuh kembali ke tema default.

Langkah 4: Jika Penyebabnya Memori

Bila log menyebut memori habis, naikkan batas memori WordPress di wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Ini membantu bila penyebabnya memang batas yang terlalu kecil. Namun bila memori habis karena plugin boros atau kueri tak berujung, menaikkan batas hanya menunda masalah — plugin penyebabnya tetap perlu diperbaiki atau diganti.

Langkah 5: Matikan Debug dan Bersihkan

Setelah situs kembali normal:

  1. Hapus atau kembalikan baris debug di wp-config.php ke WP_DEBUG false.
  2. Hapus wp-content/debug.log bila berisi jalur sensitif, atau pastikan file itu tidak bisa diakses publik.
  3. Perbarui atau ganti plugin/tema bermasalah; jangan sekadar membiarkannya nonaktif tanpa rencana.

Verifikasi Hasil

Perbaikan berhasil bila halaman depan dan wp-admin sama-sama memuat normal, tidak ada lagi baris fatal error baru di debug.log setelah beberapa kali muat ulang, dan plugin/tema lain tetap berfungsi. Uji juga halaman yang sebelumnya putih, bukan hanya beranda.

Troubleshooting Lanjutan

SituasiLangkah berikutnya
Log kosong padahal layar tetap putihPeriksa error log PHP-FPM dan Nginx; kemungkinan error terjadi sebelum WordPress dimuat
WSOD hanya di wp-adminCurigai plugin admin; nonaktifkan lewat folder seperti Langkah 3
WSOD setelah update inti gagalPeriksa file inti; pertimbangkan instal ulang file inti WordPress (tanpa menyentuh wp-content dan wp-config.php)
Situs hidup, tapi halaman tertentu masih putihPeriksa template/komponen khusus halaman itu di log

FAQ

Apakah data saya hilang saat WSOD?

Umumnya tidak. File dan database biasanya utuh; yang gagal hanya proses render halaman karena satu komponen crash.

Bolehkah WP_DEBUG dibiarkan aktif?

Tidak di situs live. Dokumentasi WordPress menegaskan debug ditujukan untuk instalasi pengujian, bukan produksi, karena outputnya bisa mengungkap informasi sensitif.

Kenapa tidak menampilkan error langsung di layar saja?

Karena setiap pengunjung akan melihat jalur file dan detail internal situs Anda. Log file memberi Anda informasi yang sama tanpa mengeksposnya ke publik.

Kesimpulan

WSOD terasa menakutkan karena tidak memberi petunjuk apa pun — tetapi justru di situlah log berperan. Aktifkan pencatatan error dengan aman, biarkan log menunjuk pelakunya, nonaktifkan komponen itu, lalu matikan debug kembali. Urutan ini menyelesaikan sebagian besar kasus WSOD tanpa perlu menebak-nebak.

Referensi

Tags:

Related Posts

Memuat…
Cookie Consent