Terjadi Kesalahan Kritis pada Situs Web Ini: Apa Artinya dan Cara Memperbaikinya

Pesan itu berarti PHP mengalami fatal error saat menyusun halaman Anda, dan WordPress menangkapnya sebelum berubah jadi layar putih kosong. Errornya nyata, spesifik, dan tercatat — WordPress hanya menolak menampilkannya di browser, karena stack trace di halaman publik membocorkan path file dan kode ke siapa pun yang berkunjung.

Jadi perbaikannya tidak pernah soal menebak-nebak. Alurnya: baca error aslinya, lalu tindak lanjuti sesuai isinya.

Apa yang sebenarnya terjadi

Sejak WordPress 5.2 ada fatal error handler bawaan di core. Ketika PHP mati di tengah request, handler ini masuk, mengganti output crash dengan kalimat sopan yang generik itu, dan — kalau berhasil mengenali plugin atau tema penyebabnya — mencoba mengirim email ke administrator situs berisi tautan menuju recovery mode.

Itu sebabnya yang muncul sekarang bukan lagi layar putih kematian versi lama. Ini kemajuan, tapi konsekuensinya informasi diagnostik disembunyikan secara default. Ada dua varian pesan yang beredar:

Yang Anda lihat	Di mana	Apa artinya
”Terjadi kesalahan kritis pada situs web ini.”	Tampilan depan, saat logout	Fatal error terjadi, tidak ada detail lain yang ditampilkan
Kalimat sama plus “Pelajari lebih lanjut tentang penanganan masalah WordPress”	Tampilan depan atau wp-admin	Error yang sama, WordPress menawarkan halaman panduan resminya
”…Silakan cek kotak masuk email admin situs Anda untuk instruksi.”	Tampilan depan	Handler merasa sudah mengirim email pemulihan

Varian ketiga itu yang paling berguna. Artinya WordPress berhasil mengaitkan crash tersebut dengan plugin atau tema tertentu dan mencoba memberi Anda jalan masuk.

Langkah 1: cek email recovery mode

WordPress mengirim tautan pemulihan ke alamat email admin situs — yang ada di Pengaturan, Umum — dan alamat itu sering bukan alamat yang Anda pakai untuk login. Periksa kotak masuk tersebut, termasuk folder spam.

Isinya berupa tautan panjang yang berakhiran kurang lebih ?action=enter_recovery_mode. Membukanya akan memasukkan Anda ke wp-admin dalam recovery mode, di mana plugin atau tema bermasalah sudah dijeda dan ditandai dengan notifikasi merah di bagian atas. Dari situ Anda tinggal menonaktifkannya seperti biasa.

Ada dua catatan jujur. Pertama, email itu dibuat oleh proses PHP yang baru saja crash, di hosting yang bisa jadi tidak punya transport email yang berfungsi sama sekali — tidak sampainya email itu hal biasa, dan ketiadaannya tidak memberi tahu apa pun soal errornya. Kedua, tautan pemulihan punya masa berlaku (sekitar satu hari secara default), jadi email lama di kotak masuk Anda mungkin sudah tidak bisa dipakai; picu crash baru dengan memuat ulang situs lalu tunggu email yang baru.

Kalau Anda ingin email itu masuk ke alamat yang benar-benar Anda baca, tentukan langsung di wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Langkah 2: baca error yang sebenarnya

Langkah inilah yang mengubah situs rusak jadi perbaikan lima menit. Tambahkan baris berikut ke wp-config.php, di atas baris yang meminta Anda berhenti mengedit:

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

WP_DEBUG_DISPLAY yang diset false itu penting — error tetap ditulis ke disk tapi tidak muncul di browser, jadi Anda tidak membocorkan path server ke pengunjung selama proses debugging.

Muat ulang halaman yang rusak sekali, lalu buka wp-content/debug.log. Entri terakhirnya kira-kira seperti ini:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Path filenya adalah jawabannya. Kalau menunjuk ke wp-content/plugins/, plugin itulah penyebabnya. Kalau menunjuk ke wp-content/themes/, berarti temanya — sangat sering karena potongan kode yang baru saja ditempel ke functions.php.

Kalau debug.log tidak muncul, kemungkinan foldernya tidak bisa ditulisi, atau ada plugin keamanan yang memindahkan lokasi log. Beralihlah ke PHP error log milik hosting — hampir semua panel hosting punya bagian “Error Log” atau “Logs”, dan fatal error yang sama akan ada di sana lengkap dengan waktunya.

Tempelkan entri tersebut ke decoder error log WordPress untuk menerjemahkan bahasa PHP-nya menjadi penjelasan praktis dan file mana yang harus dibuka duluan.

Hapus baris debug ini kalau sudah selesai. Membiarkan WP_DEBUG menyala di situs produksi akan memenuhi disk dan, kalau WP_DEBUG_DISPLAY sewaktu-waktu dihidupkan lagi, path server Anda tercetak untuk umum.

Langkah 3: masuk kembali ke wp-admin

Kalau wp-admin ikut mati dan tidak ada email pemulihan yang datang, matikan semua plugin dari sisi filesystem. Sambungkan lewat SFTP (atau File Manager hosting) dan ganti nama satu folder:

mv wp-content/plugins wp-content/plugins-off

WordPress tidak menemukan folder plugin, jadi semuanya dinonaktifkan dan akses admin hampir selalu kembali. Setelah itu:

1. Kembalikan nama folder menjadi plugins. Semuanya tetap nonaktif — WordPress sudah mencatatnya sebagai tidak aktif.
2. Aktifkan plugin satu per satu, buka tampilan depan setiap kali selesai mengaktifkan satu.
3. Plugin yang memunculkan error lagi itulah penyebabnya.

Kalau situs masih rusak padahal semua plugin sudah mati, curigai temanya. Ganti nama folder tema aktif di wp-content/themes/ dan WordPress akan otomatis memakai tema bawaan kalau ada yang terpasang.

Tiga penyebab yang perlu Anda kenali

Update plugin atau tema yang fatal. Sejauh ini paling sering terjadi. Log menyebut nama filenya langsung. Turunkan plugin itu ke versi sebelumnya, atau biarkan nonaktif dan hubungi pengembangnya sambil melampirkan baris lognya.

Versi PHP yang tidak cocok. Hosting menaikkan versi PHP secara terjadwal, kadang tanpa banyak pemberitahuan. Kode yang ditulis untuk PHP lama bisa langsung gagal diproses di versi baru. Cirinya: Anda tidak mengubah apa pun, tapi semuanya rusak sekaligus. Menurunkan PHP satu versi minor lewat panel hosting sah dipakai sebagai alat diagnosis — tapi anggap itu cuma mengulur waktu, bukan solusi. Versi PHP lama sudah tidak menerima patch keamanan.

Memori habis. Lognya berbunyi “Allowed memory size of X bytes exhausted”. Menaikkan batasnya di wp-config.php masuk akal:

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

Tapi jujur soal efeknya: itu menghapus plafonnya, bukan memperbaiki apa pun yang menghabiskan 256MB hanya untuk merender satu halaman. Kalau batas itu terus-menerus harus dinaikkan, ada sesuatu — biasanya proses impor, page builder, atau query yang ditulis asal-asalan — yang jadi masalah sebenarnya.

Saran yang aman Anda abaikan

“Naikkan saja memory limit-nya.” Hanya relevan kalau lognya memang menyebut memori habis. Selain itu tidak mengubah apa pun, dan cuma menutupi fakta bahwa Anda belum membaca errornya.

“Instal ulang WordPress core.” File core jarang jadi penyebab, dan menggantinya membuang waktu yang bisa Anda pakai untuk membaca satu baris log.

“Matikan fatal error handler-nya.” Memang ada konstanta untuk mematikannya, dan hasilnya error mentah tercetak di situs publik Anda alih-alih ditangkap. Itu membocorkan path file ke pengunjung. Pakai WP_DEBUG_LOG dengan WP_DEBUG_DISPLAY mati — informasinya sama, tanpa risiko bocor.

“Bersihkan cache.” Fatal error terjadi di PHP sebelum plugin cache sempat menyajikan apa pun. Kalau salinan cache dari halaman error yang tersaji, membersihkan cache membantu setelah Anda memperbaiki penyebabnya — bukan sebagai pengganti perbaikan itu.

Masih buntu?

Kalau log menunjuk ke file core dan bukan sesuatu di wp-content, penjelasan yang lebih masuk akal adalah ada plugin yang dimuat lebih awal dan merusak kondisi yang diandalkan core, bukan file core yang korup. Matikan semuanya dengan mengganti nama folder, pastikan situs termuat bersih, lalu masukkan plugin kembali satu per satu — plugin terakhir yang Anda aktifkan sebelum error muncul lagi itulah yang perlu Anda laporkan, dengan baris log dilampirkan.