Kenapa WordPress Jadi Blank Putih Setelah Upgrade ke PHP 8.x

Banyak pengelola website mendapati WordPress mereka tiba-tiba berubah menjadi halaman putih kosong tanpa teks apa pun sesaat setelah mengganti versi PHP dari 7.4 ke 8.x di cPanel atau konfigurasi web server. Gejala ini lazim dikenal sebagai White Screen of Death (WSoD). Sebagian orang menduga instalasi PHP di server rusak atau file inti WordPress mendadak korup, padahal penyebabnya hampir selalu bermuara pada kode plugin atau tema lama yang tidak siap menghadapi perubahan aturan ketat pada mesin PHP 8. Di meja dukungan teknis hosting, keluhan ini sangat sering masuk setiap kali ada siklus migrasi versi PHP yang sudah mencapai akhir masa hidup atau End of Life (EOL). Kita perlu memahami apa yang sebenarnya terjadi di balik layar mesin eksekusi PHP dan bagaimana cara melacak penyebab aslinya secara tenang tanpa harus panik menebak-nebak.

Perubahan Karakter Mesin PHP 7 ke PHP 8

Pada versi PHP 7.x, mesin PHP cenderung pemaaf terhadap kesalahan penulisan kode atau pemanggilan fungsi lama. Jika sebuah plugin memanggil fungsi yang sudah usang (deprecated) atau mengakses variabel array yang kuncinya belum didefinisikan, PHP 7 umumnya hanya mencatat pesan tingkat Notice atau Warning. Selama web server menyembunyikan peringatan tersebut dari layar browser, halaman website WordPress tetap bisa dimuat dan tampil normal bagi pengunjung. PHP 8 mengubah pendekatan toleransi ini. Tim pengembang inti PHP memperketat sistem tipe data (type safety) dan merapikan fungsi bawaan dengan menghapus fitur lawas yang sudah lama ditinggalkan. Kode yang sebelumnya hanya memicu Notice kini dapat berubah menjadi Warning, dan banyak kesalahan yang dulunya berstatus peringatan ringan kini langsung melempar pengecualian berupa Fatal error atau TypeError. Ketika PHP menemui Fatal error di tengah proses pembuatan halaman dan mekanisme penanganan eror bawaan WordPress tidak menangkapnya secara bersih, eksekusi skrip langsung berhenti seketika di titik baris tersebut. Web server seperti LiteSpeed, Apache, atau Nginx kemudian mengirimkan respons HTTP 500 (Internal Server Error) atau respons kosong dengan status 200 tanpa konten HTML. Di browser pengguna, respons kosong ini tampak sebagai layar putih polos. Beberapa fungsi lama yang resmi dihapus di PHP 8 sering menjadi biang keladi pada plugin yang tidak diperbarui selama bertahun-tahun. Pemanggilan fungsi seperti create_function() atau each() langsung menghentikan proses eksekusi skrip karena fungsinya memang sudah tidak ada lagi di dalam memori PHP 8.

Menyalakan Log Debugging untuk Menemukan Baris Bermasalah

Langkah pertama saat menghadapi WSoD bukan langsung mengutak-atik kode atau menghapus database, melainkan membaca pesan eror yang sebenarnya disembunyikan oleh sistem hosting. Pengaturan hosting produksi secara baku mematikan opsi display_errors demi keamanan agar jalur file sistem dan kredensial server tidak terlihat oleh publik. Untuk melihat penyebab pasti berhentinya skrip, kita bisa memanfaatkan fitur logging bawaan WordPress melalui berkas wp-config.php. Buka file tersebut lewat file manager atau SSH, cari baris define('WP_DEBUG', false);, lalu sesuaikan konfigurasi agar WordPress menulis eror ke dalam file log tersembunyi.

PHP

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

Setelah konfigurasi tersebut disimpan, muat ulang halaman website yang blank putih tadi satu kali. WordPress akan mencatat jejak eksekusi eror ke dalam file bernama wp-content/debug.log. Saat membaca baris eror di dalam debug.log, jangan teralihkan oleh rentetan teks penjelas yang panjang. Fokuskan mata kamu pada dua elemen utama: jenis eror dan jalur file (file path). Contoh format output log fatal umumnya terlihat seperti ini:

TEXT

[10-May-2024 04:12:01 UTC] PHP Fatal error:  Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /home/user/public_html/wp-content/plugins/revslider/inc_php/framework/base_admin.class.php:28

Dari baris contoh format output tersebut, kita langsung mendapatkan titik terang: file yang bermasalah berada di dalam direktori plugin revslider pada baris ke-28, disebabkan oleh pemanggilan fungsi count() yang menerima nilai kosong padahal PHP 8 mewajibkan tipe data array. Dengan bukti log ini, kamu tidak perlu menebak apakah masalahnya ada di WordPress inti, database, atau tema.

Langkah Isolasi Tanpa Akses Dashboard WordPress

Karena tampilan depan website dan halaman dashboard wp-admin sama-sama mengalami layar putih, kamu tidak bisa menonaktifkan plugin lewat antarmuka grafis WordPress. Cara paling cepat dan aman untuk memulihkan akses sementara adalah mengisolasi direktori plugin yang bersangkutan melalui file manager hosting atau terminal SSH. Masuk ke folder wp-content/plugins/, lalu ubah nama folder plugin yang tercatat di log eror, misalnya mengubah revslider menjadi revslider_disabled. Perubahan nama folder ini membuat WordPress tidak dapat menemukan file registrasi plugin tersebut, sehingga sistem secara otomatis melepas (deactivate) plugin dari antrean pemuatan tanpa menghapus data atau konfigurasinya di database. Setelah folder plugin bermasalah diubah namanya, muat ulang halaman website. Jika situs kembali tampil normal, kamu sudah memverifikasi bahwa penyebab utama kegagalan memang berada pada plugin tersebut. Dari titik ini, kamu punya waktu tenang untuk mencari versi pembaruan plugin yang sudah mendukung PHP 8, menggantinya dengan alternatif lain, atau menurunkan kembali versi PHP ke 7.4 untuk sementara waktu sembari menyiapkan langkah perbaikan menyeluruh. Trik yang sama berlaku jika file yang tercatat di debug.log berada di bawah folder wp-content/themes/. Mengubah nama folder tema yang sedang aktif akan memaksa WordPress kembali ke tema standar bawaan (seperti Twenty Twenty-Four) asalkan file tema standar tersebut tersedia di server.

Mengapa Menurunkan Versi PHP Bukan Solusi Jangka Panjang

Banyak pemilik website tergoda untuk membiarkan versi PHP tetap di 7.4 setelah mengetahui situs mereka pulih saat di-downgrade. Cara ini memang menyelesaikan masalah secara instan di saat genting, tetapi menyimpan risiko teknis yang nyata untuk jangka panjang. Versi PHP memiliki siklus dukungan resmi yang terbatas. Komunitas pengembang PHP umumnya memberikan pembaruan bug aktif selama dua tahun pertama dan pembaruan tambalan keamanan (security fixes) selama dua tahun berikutnya. Versi lama yang sudah mencapai fase EOL tidak lagi menerima tambalan keamanan resmi dari pengembang inti PHP. Menjalankan skrip lama di atas versi EOL membuat server rentan terhadap celah keamanan yang sudah diketahui publik (known vulnerabilities). Selain faktor keamanan, pengembang plugin dan tema WordPress aktif secara bertahap menaikkan syarat minimum PHP pada rilis terbaru mereka. Mengunci sistem di PHP 7.4 pada akhirnya akan membuat kamu tertinggal dari pembaruan fitur inti WordPress, peningkatan performa eksekusi, serta optimasi penggunaan memori yang ditawarkan oleh mesin PHP 8. Jika kamu mengelola website berskala besar di lingkungan VPS mandiri, pemahaman tentang beban eksekusi PHP pada level server juga sangat penting, seperti yang diulas pada artikel Managed WordPress Hosting vs Unmanaged VPS in 2026: The Maintenance Reality terkait beban pemeliharaan rutin yang harus ditangani sendiri.

Strategi Aman Sebelum Melakukan Cutover Versi PHP

Untuk menghindari downtime dan kepanikan WSoD di website produksi, proses peralihan versi PHP sebaiknya selalu diawali dengan pengujian di lingkungan yang terisolasi. Kita bisa membiasakan pola kerja bertahap berikut:

Audit Plugin yang Tidak Aktif dan Usang: Periksa daftar plugin kamu. Hapus plugin yang tidak digunakan daripada membiarkannya menumpuk. Periksa juga tanggal pembaruan terakhir pada halaman repositori plugin; jika sebuah plugin tidak pernah diperbarui selama lebih dari dua tahun, plugin tersebut berpeluang besar menimbulkan galat fatal di PHP 8.
Gunakan Environment Staging: Gandakan website kamu ke subdomain atau server terpisah (staging environment). Di lingkungan tiruan ini, naikkan versi PHP ke 8.1, 8.2, atau 8.3 terlebih dahulu. Uji fungsi-fungsi krusial seperti proses checkout, pengiriman formulir kontak, dan alur login pengguna.
Cek Log Web Server: Saat menguji di staging, pantau file log eror web server secara langsung. Hal ini membantu menangkap peringatan Deprecated yang belum memicu WSoD tetapi berpotensi menjadi eror fatal di sub-versi PHP berikutnya.
Perbarui Tema dan Plugin Sebelum Naik Versi: Selalu perbarui WordPress inti, tema, dan semua plugin ke versi paling mutakhir yang tersedia sebelum kamu menekan tombol ganti versi PHP di panel hosting. Sering kali pengembang plugin sudah merilis kompatibilitas PHP 8 di versi terbaru mereka.

Masalah WSoD setelah upgrade PHP bukan tanda bahwa server kamu rusak atau instalasi WordPress hancur total. Ini hanyalah sinyal tegas dari mesin PHP modern yang menolak mengeksekusi sintaks lawas demi menjaga keandalan dan keamanan data. Dengan mengaktifkan WP_DEBUG_LOG, membaca berkas log secara cermat, dan mengisolasi komponen yang belum kompatibel, kita bisa menjaga website tetap aman di versi PHP modern tanpa harus mengorbankan stabilitas operasional harian.