Cara Cek Plugin Penyebab White Screen WordPress Lewat WP-CLI Tanpa Buka Admin

Situs WordPress tiba-tiba cuma menampilkan halaman putih kosong, atau langsung error 500, tepat setelah ada update plugin. Masalahnya, wp-admin ikut mati, jadi tombol Deactivate yang biasa dipakai tidak bisa diklik. Kalau kamu punya akses SSH, WP-CLI bisa dipakai untuk melewati plugin yang rusak, mencari pelakunya satu per satu, lalu menonaktifkannya tanpa perlu membuka dashboard. Artikel ini disusun seperti postmortem: dari dampak awal, jalur investigasi, titik konfirmasi, mitigasi sementara, sampai perbaikan supaya kejadian serupa tidak terulang. Ini bukan cerita satu insiden tertentu, melainkan pola yang memang sering muncul di tiket support WordPress.

Dampak awal: frontend blank, admin ikut mati

White screen di WordPress hampir selalu berarti PHP berhenti di tengah jalan karena fatal error. Contohnya fungsi yang tidak ada, class yang dideklarasikan dua kali, atau sintaks yang tidak didukung versi PHP di server. Di server produksi, display_errors biasanya dimatikan supaya pesan error tidak bocor ke pengunjung. Hasilnya, browser hanya menerima halaman kosong atau status 500 tanpa penjelasan apa pun. Admin ikut mati karena urutan loading WordPress sama untuk frontend maupun wp-admin. Setiap request memuat core, lalu semua plugin aktif, lalu tema. Kalau satu plugin crash saat dimuat, proses berhenti sebelum halaman admin sempat dirender. Karena itu customer sering bilang "semuanya mati", padahal sumbernya cuma satu file di satu folder plugin. Langkah klasiknya adalah rename folder plugin lewat File Manager atau FTP. Cara ini memang jalan, tapi kalau plugin aktifnya banyak, kita jadi menebak-nebak. WP-CLI membuat proses ini jauh lebih terarah.

Investigasi: memastikan masalahnya di plugin atau tema

WP-CLI adalah tool command line resmi untuk mengelola WordPress. Ia juga memuat WordPress saat dijalankan, jadi plugin yang rusak biasanya ikut membuat perintah WP-CLI gagal. Bedanya, WP-CLI punya dua parameter global yang tidak dimiliki browser: --skip-plugins untuk melewati pemuatan plugin, dan --skip-themes untuk melewati pemuatan tema. Keduanya bisa dipakai tanpa nilai (lewati semua) atau dengan daftar slug yang dipisah koma (lewati yang disebut saja). Masuk ke direktori instalasi WordPress sebagai user pemilik file. Hindari menjalankannya sebagai root. Kalau terpaksa, WP-CLI akan minta flag --allow-root, dan file yang dibuat bisa berakhir dengan owner yang salah. Setelah itu, jalankan tiga tes dasar ini:

BASH

# Tes 1: muat WordPress normal (kemungkinan besar gagal)
wp option get siteurl

# Tes 2: lewati semua plugin dan tema
wp option get siteurl --skip-plugins --skip-themes

# Tes 3: lewati tema saja, plugin tetap dimuat
wp option get siteurl --skip-themes

wp option get siteurl dipilih karena perintahnya ringan, read-only, dan tetap memaksa WordPress dimuat penuh. Cara membaca hasilnya:

Tes 1 gagal, tes 2 berhasil, tes 3 gagal: penyebabnya ada di plugin.
Tes 1 gagal, tes 2 dan tes 3 berhasil: penyebabnya kemungkinan besar di tema aktif, termasuk functions.php.
Tes 2 pun gagal: masalahnya di luar plugin dan tema biasa. Cek wp-config.php, file core, must-use plugin di wp-content/mu-plugins, atau drop-in seperti object-cache.php. Jenis file ini umumnya tetap dimuat meski --skip-plugins dipakai.

Sering kali tes 1 sudah langsung mencetak pesan fatal error lengkap dengan path file di terminal, karena output error CLI tidak selalu mengikuti setting display_errors di web. Kalau path-nya mengarah ke wp-content/plugins/nama-plugin/, separuh pekerjaan sudah selesai. Tambahkan --debug kalau butuh detail lebih banyak tentang tahap loading mana yang sedang berjalan.

Mengisolasi plugin satu per satu

Kalau pesan error tidak jelas, atau ada beberapa plugin yang dicurigai, kita bisa membalik logikanya: muat semua plugin kecuali satu, lalu ulangi untuk setiap plugin aktif. Plugin yang ketika dilewati membuat WordPress berhasil dimuat, itulah tersangka utamanya.

BASH

# Ambil daftar plugin aktif tanpa memuat plugin apa pun
wp plugin list --status=active --field=name --skip-plugins --skip-themes

# Coba muat WordPress sambil melewati satu plugin per putaran
for p in $(wp plugin list --status=active --field=name --skip-plugins --skip-themes); do
  if wp option get siteurl --skip-plugins=$p --skip-themes >/dev/null 2>&1; then
    echo "Berhasil dimuat tanpa plugin: $p"
  fi
done

Loop ini read-only, karena --skip-plugins hanya berlaku untuk proses CLI itu sendiri dan tidak mengubah status aktif plugin di database. Ada beberapa pola hasil yang perlu dibaca dengan hati-hati:

Satu nama muncul: hampir pasti itu plugin penyebabnya.
Tidak ada nama yang muncul, padahal tes 2 tadi berhasil: bisa jadi ada dua plugin yang sama-sama rusak, atau dua plugin yang bentrok satu sama lain (misalnya sama-sama membawa library dengan nama class yang sama). Coba lewati dua plugin sekaligus, misalnya --skip-plugins=plugin-a,plugin-b, mulai dari plugin yang baru di-update.
Beberapa nama muncul: biasanya salah satunya bergantung pada yang lain. Contohnya add-on yang ikut error kalau plugin induknya dilewati. Lihat log untuk memastikan mana yang asli.

Ada satu batasan penting. CLI tidak menjalankan request web yang sesungguhnya. Plugin yang baru crash di hook frontend tertentu, misalnya saat merender template atau memproses checkout, bisa lolos di tes CLI padahal browser tetap blank. Kalau semua tes CLI lolos tapi situs tetap error, jawabannya ada di error log, bukan di loop.

Titik konfirmasi di PHP error log

Hasil loop baru berupa dugaan kuat. Konfirmasinya tetap harus dari error log, karena di sana tercatat file dan baris persis tempat PHP berhenti. Lokasinya tergantung setup server. Di banyak akun cPanel ada file error_log di direktori situs. Di VPS dengan PHP-FPM biasanya ada log per pool, dan web server juga punya error log sendiri. Kalau WP_DEBUG_LOG aktif, WordPress menulis ke wp-content/debug.log. Yang dicari adalah baris PHP Fatal error dengan waktu yang cocok dengan munculnya keluhan:

TEXT

# contoh format output, bukan dari insiden nyata
PHP Fatal error:  Uncaught Error: Call to undefined function contoh_fungsi() in /home/user/public_html/wp-content/plugins/contoh-plugin/includes/loader.php:42

Path di baris itu menunjukkan plugin mana yang crash. Pesan errornya sering memberi petunjuk tentang penyebabnya. Call to undefined function atau Class not found biasanya berarti file plugin tidak lengkap setelah update yang terputus, atau plugin butuh plugin lain yang belum aktif. Cannot redeclare biasanya tanda dua plugin membawa kode yang sama. Error sintaks setelah server ganti versi PHP mengarah ke plugin yang belum kompatibel dengan versi tersebut. Kalau kamu menyalakan WP_DEBUG_LOG sementara untuk investigasi, jangan lupa matikan lagi setelah selesai. File log yang dibiarkan bisa membengkak dan terbaca publik. Untuk catatan debugging WordPress yang lebih umum, lihat Catatan Praktis WordPress Performance & Debugging untuk Troubleshooting Sehari-hari.

Mitigasi sementara dan perbaikan yang lebih permanen

Setelah plugin penyebabnya terkonfirmasi, mitigasi tercepatnya adalah menonaktifkan plugin itu tanpa memuat plugin lain: wp plugin deactivate nama-plugin --skip-plugins --skip-themes Perintah ini mengubah daftar plugin aktif di database, jadi efeknya langsung terasa di web. Buka situs dan wp-admin untuk memastikan semuanya kembali normal. Kalau penyebabnya ternyata tema, cek tema yang tersedia dengan wp theme list --skip-plugins --skip-themes, lalu aktifkan sementara tema bawaan WordPress yang sudah terpasang lewat wp theme activate. Tolong diingat bahwa menonaktifkan plugin bukan tindakan netral. Plugin keamanan, cache, membership, atau payment gateway yang mati bisa mengubah perilaku situs: form tidak terkirim, halaman member terbuka, checkout berhenti. Kabari pemilik situs fungsi apa yang sedang hilang, jangan cuma bilang "sudah normal". Kalau plugin itu wajib ada, opsi berikutnya adalah rollback ke versi sebelumnya. Untuk plugin dari direktori WordPress.org, ada wp plugin install nama-plugin --version=<versi-sebelumnya> --force. Plugin premium biasanya perlu file ZIP versi lama dari vendornya. Sebelum rollback atau mengubah apa pun di database, ambil backup dulu dengan wp db export, supaya ada titik kembali kalau langkah berikutnya malah memperburuk keadaan. Perbaikan jangka panjangnya lebih ke proses daripada tool:

Update plugin satu per satu, bukan sekaligus semua. Kalau ada yang crash, tersangkanya cuma satu.
Uji update di staging dulu untuk situs yang menghasilkan uang atau menangani data penting.
Cek kompatibilitas versi PHP sebelum hosting atau server menaikkan versi PHP.
Pertimbangkan ulang auto-update untuk plugin yang kritis bagi bisnis. Ini trade-off antara cepat dapat patch keamanan dan risiko situs mati di jam yang tidak ada orang berjaga.
Pastikan email admin WordPress masih aktif. Versi WordPress yang lebih baru bisa mengirim email recovery mode saat fatal error terjadi, dan email itu sering jadi petunjuk pertama.

Urutan yang paling hemat waktu biasanya begini: jalankan tiga tes dasar untuk memisahkan masalah plugin dari masalah tema, baca pesan fatal error yang sering sudah muncul di terminal, pakai loop --skip-plugins kalau penyebabnya belum jelas, lalu konfirmasi dari error log sebelum menonaktifkan apa pun. Semua langkah sampai tahap konfirmasi itu read-only, jadi aman dicoba di situs yang sedang down. Perubahan baru dilakukan setelah kamu tahu persis plugin mana yang harus dimatikan.