Layar Putih Setelah Upgrade ke PHP 8? Cari Plugin Penyebabnya Lewat WP_DEBUG_LOG

Versi PHP baru dinaikkan ke 8.x, lalu halaman depan WordPress jadi putih kosong. Kadang muncul error 500, kadang cuma pesan 'There has been a critical error on this website'. Dashboard ikut tidak bisa dibuka, dan wajar kalau orang langsung menyalahkan server. Padahal yang biasanya terjadi lebih sederhana: ada plugin atau theme lama yang memanggil fungsi yang sudah dihapus di PHP 8, lalu PHP berhenti total di baris itu. Artikel ini menyusun pola tersebut seperti post-mortem: apa dampaknya, bagaimana investigasinya, di mana petunjuknya ditemukan, cara meredam sementara, dan perbaikan supaya tidak terulang di upgrade berikutnya. Latar belakang kenapa PHP 8 memicu white screen sudah dibahas di Kenapa WordPress Jadi Blank Putih Setelah Upgrade ke PHP 8.x. Di sini fokusnya praktik: cara menemukan plugin pelakunya.

Dampak awal: blank putih atau error 500 tepat setelah ganti versi PHP

Gejalanya hampir selalu muncul langsung setelah versi PHP diganti, entah lewat panel hosting atau di VPS sendiri. Konten situs tidak berubah dan tidak ada update plugin. Satu-satunya yang berubah adalah versi runtime PHP. Tampilannya bisa bermacam-macam:

Halaman benar-benar putih, tanpa teks apa pun.
Error 500 dari web server.
Pesan critical error dari WordPress, karena sejak versi 5.2 WordPress punya fatal error handler sendiri.
Halaman depan normal, tapi wp-admin blank. Ini terjadi kalau kode yang rusak hanya dimuat di area admin.

Di meja support, pola ini sering datang dengan kalimat 'tadi masih jalan, saya cuma ganti PHP'. Kalimat itu justru petunjuk paling berguna. Kalau satu-satunya perubahan adalah versi PHP, tersangka utamanya adalah kode PHP yang tidak kompatibel, bukan database dan bukan DNS.

Investigasi: kenapa layar kosong tidak memberi petunjuk

Di server produksi, display_errors biasanya dimatikan. Ini memang benar, karena pesan error bisa membocorkan path file dan struktur aplikasi ke pengunjung. Efek sampingnya, saat terjadi fatal error, PHP berhenti tanpa menampilkan apa pun dan hasilnya halaman kosong. Langkah pertama yang masuk akal adalah mencari log yang sudah ada. Di banyak setup cPanel, PHP menulis file error_log di folder tempat skrip dijalankan. Di VPS dengan PHP-FPM, error biasanya masuk ke log pool FPM atau log web server. Lokasi persisnya tergantung konfigurasi. Kalau log itu ada dan berisi baris Fatal error, investigasi bisa langsung lompat ke bagian berikutnya. Kalau log server tidak ketemu, kosong, atau kamu tidak punya akses ke sana (umum di shared hosting), aktifkan log bawaan WordPress. Buka wp-config.php dan cari baris define( 'WP_DEBUG', false );. Kalau baris itu sudah ada, ubah nilainya, jangan menduplikasi define-nya. Lalu tambahkan sisanya sebelum komentar /* That's all, stop editing! */:

PHP

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

Fungsi masing-masing baris:

WP_DEBUG menyalakan mode debug.
WP_DEBUG_LOG menyuruh WordPress menulis semua error ke file wp-content/debug.log.
WP_DEBUG_DISPLAY yang diset false dan ini_set memastikan error tidak tampil di halaman.

Jadi pengunjung tetap tidak melihat pesan apa pun, sementara kita mendapat catatan lengkapnya. Setelah itu, buka lagi halaman yang blank satu kali supaya error-nya tercatat. Ada satu hal yang sering terlewat. File debug.log di dalam wp-content berada di folder yang bisa diakses lewat web. Tergantung aturan web server, siapa pun yang tahu URL-nya bisa mengunduh file itu. Jadi anggap log ini sebagai alat sementara. Sejak WordPress 5.1, WP_DEBUG_LOG juga bisa diisi path file di luar public_html sebagai pengganti true, dan itu pilihan yang lebih aman kalau debug perlu menyala lebih lama.

Titik terang: satu baris Fatal error di debug.log

Begitu WP_DEBUG menyala, debug.log biasanya cepat terisi Deprecated dan Notice dari berbagai plugin. Semua itu peringatan, bukan penyebab layar putih. Yang kita cari adalah baris PHP Fatal error, karena hanya fatal error yang menghentikan eksekusi. Contoh format output (bukan dari insiden nyata):

TEXT

[tanggal waktu UTC] PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /home/contoh/public_html/wp-content/plugins/plugin-lama/includes/widget.php:42
Stack trace:
#0 /home/contoh/public_html/wp-includes/class-wp-hook.php(...): ...

Bagian terpenting dari baris itu adalah path filenya. Segmen setelah wp-content/plugins/ adalah nama folder plugin penyebabnya, di contoh ini plugin-lama. Kalau path-nya mengarah ke wp-content/themes/, berarti pelakunya theme. Kalau mengarah ke wp-content/mu-plugins/, itu must-use plugin, dan penanganannya sedikit berbeda. Pesan errornya juga menjelaskan kenapa kode itu rusak di PHP 8. Call to undefined function untuk fungsi seperti create_function(), each(), atau money_format() berarti fungsinya sudah dihapus sejak PHP 8.0. Ada juga pola lain: TypeError dari fungsi seperti count() yang menerima nilai bukan array. Di PHP 7 itu hanya warning, sedangkan di PHP 8 eksekusi langsung berhenti. Kode lama yang dulu jalan dengan banyak warning sekarang langsung mati. Kalau ada beberapa fatal error, fokus ke yang paling baru dan muncul berulang tiap kali halaman dibuka. Fatal error lama bisa saja sisa dari kondisi sebelumnya.

Mitigasi sementara: matikan plugin tanpa masuk wp-admin

Karena dashboard tidak bisa dibuka, plugin harus dimatikan dari luar. Ada dua cara, dan dua-duanya bisa dikembalikan. Pembahasan WP-CLI yang lebih lengkap ada di Cara Cek Plugin Penyebab White Screen WordPress Lewat WP-CLI Tanpa Buka Admin. Ini versi ringkasnya. Jalankan perintah dari folder root WordPress:

BASH

# lihat beberapa fatal error terakhir
grep -n 'PHP Fatal error' wp-content/debug.log | tail -n 5

# cek plugin aktif tanpa memuat plugin dan theme
wp plugin list --status=active --skip-plugins --skip-themes

# nonaktifkan plugin penyebab
wp plugin deactivate plugin-lama --skip-plugins --skip-themes

# alternatif tanpa WP-CLI: rename folder plugin
mv wp-content/plugins/plugin-lama wp-content/plugins/plugin-lama.nonaktif

Opsi --skip-plugins dan --skip-themes itu penting. Tanpa keduanya, WP-CLI memuat WordPress lengkap dengan plugin yang rusak, sehingga perintahnya ikut kena fatal error. Cara rename folder bisa dipakai kalau WP-CLI tidak tersedia, cukup lewat File Manager atau SFTP. WordPress tidak menemukan file plugin di path lamanya, lalu otomatis menganggapnya nonaktif. Kalau nanti folder dikembalikan ke nama asal, plugin tetap dalam kondisi nonaktif sampai diaktifkan lagi secara manual. Penanganan untuk dua kasus lain:

Kalau pelakunya theme, aktifkan theme lain yang sudah terpasang. Cek daftarnya dengan wp theme list --skip-plugins --skip-themes, lalu jalankan wp theme activate dengan nama theme tersebut.
Kalau pelakunya mu-plugins, perintah deactivate tidak berpengaruh, karena must-use plugin selalu dimuat. Satu-satunya jalan adalah memindahkan atau me-rename file-nya.

Setelah satu plugin dimatikan, buka situs lagi dan cek ulang debug.log. Sering ada plugin kedua yang bermasalah dan baru kelihatan setelah yang pertama disingkirkan, karena PHP berhenti di fatal error pertama yang ditemuinya. Opsi mitigasi lain adalah mengembalikan versi PHP ke versi lama lewat panel hosting. Cara ini cepat, tapi sifatnya hanya menunda masalah. Ketersediaan versi lama juga tergantung kebijakan hosting, dan versi PHP yang sudah habis masa dukungannya tidak lagi menerima patch keamanan.

Perbaikan permanen: upgrade PHP lewat staging, bukan langsung di produksi

Mematikan plugin bukan solusi kalau fungsinya dibutuhkan situs. Langkah berikutnya adalah memilih salah satu dari tiga jalan:

Update plugin ke versi terbaru, karena bisa jadi masalahnya sudah diperbaiki developernya.
Ganti dengan plugin lain kalau plugin lama sudah lama tidak di-update.
Perbaiki kodenya sendiri kalau itu kode custom.

Untuk plugin yang tidak lagi dirawat, biasanya lebih aman diganti daripada ditambal. Kode yang tidak kompatibel dengan PHP 8 sering juga punya masalah lain yang belum kelihatan. Secara proses, perubahan paling berdampak adalah memindahkan upgrade PHP ke staging, yaitu salinan situs yang terpisah dari produksi. Alurnya:

Salin situs ke staging.
Jalankan staging di versi PHP target.
Nyalakan WP_DEBUG_LOG.
Klik halaman-halaman utama, termasuk wp-admin, form, dan checkout kalau ada.
Baca debug.log-nya.

Kalau bersih dari fatal error, baru versi PHP di produksi dinaikkan. Untuk situs dengan banyak kode custom, pemindaian statis dengan PHPCompatibilityWP (ruleset untuk PHP_CodeSniffer) bisa membantu menemukan fungsi yang dihapus sebelum kodenya dijalankan. Cakupan pengecekan PHP 8-nya tergantung versi rilis yang dipakai. Jangan lupa juga membereskan setelah investigasi selesai. Kembalikan WP_DEBUG ke false, lalu hapus atau pindahkan debug.log. Log yang dibiarkan menyala terus akan membengkak oleh Deprecated dan Notice, dan bisa terbuka ke publik. Intinya, layar putih setelah upgrade PHP hampir selalu meninggalkan jejak berupa satu baris Fatal error. Nyalakan log tanpa menampilkan error ke pengunjung, cari path di baris itu, lalu matikan plugin yang ditunjuk lewat WP-CLI atau rename folder. Setelah situs kembali normal, perbaiki prosesnya: tes versi PHP baru di staging dulu, supaya upgrade berikutnya tidak berubah jadi sesi debugging di produksi.