Mengatasi Block Editor WordPress yang Tidak Mau Loading

Sebagian besar kasus, block editor WordPress yang tidak mau loading disebabkan oleh error JavaScript — satu skrip rusak dari plugin atau tema menghentikan seluruh aplikasi React, dan editor tidak pernah selesai dirender. Buka developer console di browser Anda (F12, atau Cmd+Option+I di Mac), muat ulang layar edit, lalu baca error berwarna merah. Hampir selalu error itu menyebut file yang jadi penyebabnya. Satu baris itu memberi tahu plugin mana yang harus dinonaktifkan, dan biasanya Anda sudah bisa kembali menulis dalam waktu kurang dari lima menit. Menginstal ulang WordPress, menaikkan PHP memory limit, dan beralih ke Classic Editor adalah tiga saran yang paling sering muncul di internet, dan ketiganya biasanya justru langkah yang keliru.

Kenapa editor rusak dengan cara seperti itu

Block editor (Gutenberg) adalah aplikasi React single-page yang berjalan di dalam wp-admin/post.php dan post-new.php. WordPress meng-enqueue tumpukan paket skrip — wp-blocks, wp-element, wp-editor, wp-edit-post — dan aplikasi ini melakukan bootstrap melalui wp.domReady(). JavaScript berhenti dieksekusi pada exception pertama yang tidak tertangani. Jadi kalau ada skrip yang di-enqueue melempar error saat editor sedang inisialisasi, semua yang berjalan setelahnya ikut mati. Area tulisan yang sudah Anda siapkan dengan susah payah berubah jadi panel putih kosong atau muncul pesan “The editor has encountered an unexpected error.”

Secara default, WordPress juga menggabungkan skrip admin menjadi lebih sedikit request. Artinya, JS rusak dari satu plugin bisa menyeret skrip lain yang tidak berkaitan tapi dimuat dalam bundle yang sama, dan itulah kenapa penyebabnya tidak selalu jelas hanya dari perilaku editor. Yang jelas justru console-nya.

Mode kegagalan kedua bentuknya berbeda: editor berhasil loading, tapi saat menyimpan muncul “Updating failed. The response is not a valid JSON response.” Ini bukan masalah JavaScript. Editor berkomunikasi dengan REST API di /wp-json/wp/v2/, dan mengharapkan JSON yang bersih sebagai balasan. Kalau sebuah plugin atau functions.php tema Anda memunculkan notice, warning, atau fatal PHP sebelum JSON — atau plugin keamanan memblokir route REST, atau plugin redirect menulis ulang URL — responsnya jadi terkontaminasi dan editor tidak bisa mem-parse-nya.

Cara mengatasinya, dari yang paling cepat

1. Baca console-nya. Reproduksi kegagalannya dengan DevTools terbuka. Error seperti Uncaught TypeError ... some-plugin/build/index.js langsung menunjuk ke plugin biang keroknya. Satu langkah ini menyelesaikan mayoritas kasus dan menyelamatkan Anda dari bisecting membabi buta.

2. Singkirkan kemungkinan browser. Hard-refresh (Cmd/Ctrl+Shift+R), lalu coba jendela incognito dengan ekstensi dimatikan. Ad blocker dan ekstensi privasi kadang menghapus skrip admin. Kalau di incognito berhasil, berarti masalahnya di ekstensi browser atau cache basi, bukan di situs Anda.

3. Cek REST API secara langsung kalau Anda melihat pesan “not a valid JSON”. Kunjungi https://yoursite.com/wp-json/ di browser. Seharusnya muncul tembok JSON. Kalau yang muncul HTML, error 500, atau redirect ke login, di situlah bug-nya — ada plugin yang merusak respons REST, bukan editornya sendiri.

4. Bisecting plugin Anda. Nonaktifkan semuanya, pastikan editor loading, lalu aktifkan kembali satu per satu sampai rusak lagi. Kalau Anda sampai terkunci total dari wp-admin, lakukan lewat SFTP dengan mengganti nama foldernya:

mv wp-content/plugins wp-content/plugins_off

WordPress akan menonaktifkan semua plugin ketika foldernya hilang. Ganti namanya kembali, lalu keluar-masukkan plugin satu per satu.

5. Uji temanya. Beralih ke Twenty Twenty-Four. Tema yang meng-enqueue JS editor rusak atau melempar PHP di functions.php menghasilkan gejala yang sama.

6. Aktifkan log dan baca error yang sebenarnya. Khususnya untuk kegagalan REST/JSON, aktifkan debugging di wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Fatal-nya akan ditulis ke wp-content/debug.log lengkap dengan file dan nomor baris yang persis. Kalau stack trace itu padat — nama class ber-namespace, rantai require, sebuah fatal yang terkubur di bawah sepuluh baris trace — tempelkan ke WordPress error log decoder kami untuk melihat, dalam bahasa yang jelas, plugin dan baris mana yang sebenarnya jadi pemicu. Itulah bedanya antara “ada yang rusak” dan “baris 214 dari plugin spesifik ini yang rusak.”

Kalau Anda curiga penggabungan skrip menyembunyikan penyebab sebenarnya, paksa setiap skrip dimuat terpisah supaya error di console menunjuk tepat ke satu file:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Yang jangan dilakukan

Jangan menginstal plugin Classic Editor lalu menganggap masalah beres. Plugin itu tidak memperbaiki apa pun — ia hanya menyembunyikan block editor supaya Anda berhenti melihat error-nya. JavaScript rusak atau respons REST yang bermasalah tetap ada, dan akan menggigit lagi di site editor, di widget, atau saat Anda melakukan update berikutnya. Diagnosis dulu; jatuh ke Classic hanya kalau Anda sudah sengaja memutuskan berhenti memakai blok.

Jangan menaikkan PHP memory limit secara refleks. Ini adalah perbaikan copy-paste favorit internet, padahal editor kosong jarang disebabkan kehabisan memori. Kehabisan memori yang benar-benar terjadi akan melempar fatal spesifik — “Allowed memory size of N bytes exhausted” — yang akan Anda lihat di debug.log. Kalau baris itu tidak ada, menambah memori tidak mengubah apa-apa.

Jangan menginstal ulang WordPress core. File core identik byte-per-byte di setiap instalasi. Kalau core-nya yang bermasalah, setiap situs WordPress di dunia akan punya editor rusak saat ini juga. Kesalahan hampir selalu ada di plugin atau tema Anda, dan menginstal ulang core berisiko menimpa sesuatu tanpa memperbaiki apa pun.

Jangan membabi buta membersihkan atau menonaktifkan plugin cache sebagai langkah pertama. Minifikasi dan penggabungan JS yang agresif memang bisa merusak editor, jadi layak diuji — tapi cek console dulu sebelum asal menghapus cache. Menebak-nebak adalah cara perbaikan lima menit berubah jadi menghabiskan sepanjang sore.

Masih buntu?

Kalau console-nya bersih, REST API mengembalikan JSON yang valid, dan bisect penuh atas plugin serta tema tetap membiarkan editor mati, jawabannya hampir selalu tersimpan di debug.log. Aktifkan WP_DEBUG_LOG, reproduksi kegagalannya sekali, lalu jalankan fatal yang muncul melalui error log decoder. Stack trace-nya menyebut file penyebabnya — mulailah dari situ.