Ayusin ang WordPress Block Editor na Hindi Naglo-load

Kadalasan, ang WordPress block editor na ayaw mag-load ay dulot ng JavaScript error — isang sirang script mula sa isang plugin o theme ang pumipigil sa buong React app, kaya hindi natatapos mag-render ang editor. Buksan ang developer console ng iyong browser (F12, o Cmd+Option+I sa Mac), i-reload ang edit screen, at basahin ang pulang error. Halos palagi nitong pinangalanan ang file na nagdulot ng problema. Sinasabi na ng isang linyang iyon kung aling plugin ang dapat i-disable, at karaniwang makakabalik ka na sa pagsusulat sa loob ng wala pang limang minuto. Ang pag-reinstall ng WordPress, pagtaas ng PHP memory limit, at paglipat sa Classic Editor ang tatlong pinakakaraniwang suhestiyon online, at ang tatlong ito ay kadalasang mali.

Bakit nasisira ang editor sa paraang ganito

Ang block editor (Gutenberg) ay isang single-page React application na tumatakbo sa loob ng wp-admin/post.php at post-new.php. Nag-e-enqueue ang WordPress ng ilang script package — wp-blocks, wp-element, wp-editor, wp-edit-post — at nagbo-bootstrap ang app sa pamamagitan ng wp.domReady(). Huminto ang JavaScript sa pag-execute sa unang uncaught exception. Kaya kung may enqueued script na nag-throw habang nag-i-initialize ang editor, lahat ng sumunod dito ay mamamatay din. Ang maingat mong isinulat na post area ay babagsak sa blangkong puting pane o sa mensaheng “The editor has encountered an unexpected error.”

Bilang default, kino-concatenate din ng WordPress ang mga admin script sa mas kaunting request. Ibig sabihin, ang sirang JS ng isang plugin ay maaaring makahila pababa ng mga hindi kaugnay na script na na-load sa parehong bundle, kaya hindi laging halata ang salarin base lamang sa gawi. Ang console ang halata.

Iba ang itsura ng pangalawang failure mode: nag-lo-load ang editor, ngunit nag-throw ang pag-save ng “Updating failed. The response is not a valid JSON response.” Hindi iyon problema sa JavaScript. Nakikipag-usap ang editor sa REST API sa /wp-json/wp/v2/, at umaasa ito ng malinis na JSON pabalik. Kung may plugin o ang functions.php ng iyong theme na naglalabas ng PHP notice, warning, o fatal bago ang JSON — o may security plugin na humaharang sa REST route, o may redirect plugin na nagre-rewrite ng URL — nadudumihan ang response at hindi ito ma-parse ng editor.

Paano ito ayusin, pinakamabilis muna

1. Basahin ang console. I-reproduce ang failure habang bukas ang DevTools. Ang error na tulad ng Uncaught TypeError ... some-plugin/build/index.js ay tumuturo diretso sa may sala na plugin. Ang isang hakbang na ito ang nakakalutas sa karamihan ng mga kaso at nakakaligtas sa iyo sa bulag na pag-bisect.

2. I-rule out ang browser. Mag-hard-refresh (Cmd/Ctrl+Shift+R), pagkatapos subukan ang incognito window na naka-off ang mga extension. Paminsan ay tinatanggal ng ad blocker at privacy extension ang mga admin script. Kung gumagana ito sa incognito, ang problema ay isang browser extension o lumang cache, hindi ang iyong site.

3. Suriin ang REST API nang direkta kung nakita mo ang “not a valid JSON” na mensahe. Bisitahin ang https://yoursite.com/wp-json/ sa isang browser. Dapat kang makakuha ng dami-daming JSON. Kung HTML, 500, o login redirect ang lumabas, iyon ang iyong bug — may plugin na sumisira sa REST response, hindi ang editor mismo.

4. I-bisect ang iyong mga plugin. I-deactivate lahat ng ito, kumpirmahin na nag-lo-load ang editor, pagkatapos i-reactivate isa-isa hanggang sa masira ulit. Kung na-lock ka out sa wp-admin nang buo, gawin ito sa SFTP sa pamamagitan ng pag-rename ng folder:

mv wp-content/plugins wp-content/plugins_off

Dini-deactivate ng WordPress ang lahat kapag nawala ang folder. I-rename itong pabalik, pagkatapos ilipat ang mga plugin papasok at palabas nang isa-isa.

5. Subukan ang theme. Lumipat sa Twenty Twenty-Four. Ang theme na nag-e-enqueue ng sirang editor JS o nag-t-throw ng PHP sa functions.php ay gumagawa ng parehong sintomas.

6. Buksan ang log at basahin ang tunay na error. Para sa REST/JSON failures lalo na, i-enable ang debugging sa wp-config.php:

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

Naisusulat ang fatal sa wp-content/debug.log kasama ang eksaktong file at line number. Kung siksik ang stack trace na iyon — namespaced class names, require chains, isang fatal na nakabaon sa ilalim ng sampung linya ng trace — i-paste ito sa aming WordPress error log decoder para makita, sa simpleng salita, kung aling plugin at linya ang talagang nag-trigger nito. Iyon ang pagkakaiba ng “may sirang bagay” at “sira ang linya 214 ng partikular na plugin na ito.”

Kung pinaghihinalaan mong tinatakpan ng script concatenation ang tunay na salarin, piliting mag-load nang hiwalay ang bawat script para tumuro ang console error sa eksaktong isang file:

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

Ano ang hindi dapat gawin

Huwag i-install ang Classic Editor plugin at ituring na ayos na. Wala itong inaayos — itinatago lang nito ang block editor para hindi mo na makita ang error. Nariyan pa rin ang sirang JavaScript o sirang REST response, at kakagatin ka nito ulit sa site editor, sa widgets, o sa susunod mong pag-update. Mag-diagnose muna; bumalik lang sa Classic kung sadyang napagdesisyunan mong itigil na ang paggamit ng blocks.

Huwag itaas ang PHP memory limit dahil lang sa hilig. Ito ang paboritong copy-paste na ayos ng internet, pero ang blangkong editor ay bihirang dulot ng memory exhaustion. Ang tunay na exhaustion ay nag-t-throw ng partikular na fatal — “Allowed memory size of N bytes exhausted” — na makikita mo sa debug.log. Kung wala ang linyang iyon, walang binabago ang mas maraming memory.

Huwag i-reinstall ang WordPress core. Byte-identical ang core files sa bawat install. Kung ang core ang problema, lahat ng WordPress site sa mundo ay may sirang editor ngayon. Ang kasalanan ay halos palaging nasa iyong mga plugin o theme, at ang pag-reinstall ng core ay may panganib na ma-overwrite ang mga bagay habang wala namang inaayos.

Huwag bulag na i-clear o i-disable ang iyong cache plugin bilang unang hakbang. Ang agresibong JS minification at concatenation ay maaaring sumira sa editor, kaya sulit itong subukan — pero suriin ang console bago ka mag-flush ng cache nang basta-basta. Ang paghula ay kung paano nagiging isang buong hapon ang limang-minutong ayos.

Nasa dilim pa rin?

Kung malinis ang console, nagbabalik ng valid na JSON ang REST API, at ang kumpletong plugin-at-theme bisect ay nag-iiwan pa rin ng patay na editor, ang sagot ay halos palaging nasa debug.log. I-enable ang WP_DEBUG_LOG, i-reproduce ang failure nang isang beses, at patakbuhin ang resultang fatal sa error log decoder. Pinangalanan ng stack trace ang file — magsimula roon.