WordPress block editor load नहीं हो रहा? ऐसे कीजिए ठीक

ज़्यादातर मामलों में, WordPress block editor जो load नहीं होता उसकी वजह एक JavaScript error होती है — किसी plugin या theme की एक टूटी हुई script पूरे React app को रोक देती है, और editor कभी render हो ही नहीं पाता। अपने browser का developer console खोलिए (F12, या Mac पर Cmd+Option+I), edit screen reload कीजिए, और लाल रंग की error पढ़िए। वह लगभग हमेशा उस file का नाम बता देती है जिसने error फेंकी। वही एक line आपको बता देती है कि कौन-सा plugin disable करना है, और आप अक्सर पाँच मिनट के अंदर वापस लिखने लायक हो जाते हैं। WordPress को दोबारा install करना, PHP memory limit बढ़ाना, और Classic Editor पर switch करना — internet पर मिलने वाले ये तीन सबसे आम सुझाव हैं, और तीनों अक्सर ग़लत क़दम होते हैं।

editor इस तरह से क्यों टूटता है

Block editor (Gutenberg) एक single-page React application है जो wp-admin/post.php और post-new.php के अंदर चलती है। WordPress कई script packages enqueue करता है — wp-blocks, wp-element, wp-editor, wp-edit-post — और app wp.domReady() के ज़रिए bootstrap होता है। JavaScript पहले uncaught exception पर ही चलना बंद कर देता है। तो अगर कोई भी enqueue किया गया script editor के initialize होते समय error फेंकता है, तो उसके बाद का सब कुछ उसी के साथ मर जाता है। आपका ध्यान से लिखा गया post area एक ख़ाली सफ़ेद pane में बदल जाता है या “The editor has encountered an unexpected error.” message दिखता है।

Default रूप से WordPress admin scripts को कम requests में concatenate भी करता है। इसका मतलब है कि एक plugin की टूटी हुई JS उसी bundle में load होने वाली बिल्कुल असंबंधित scripts को भी नीचे खींच सकती है, इसीलिए सिर्फ़ behavior से असली गुनहगार हमेशा साफ़ नहीं होता। Console से होता है।

दूसरा failure mode अलग दिखता है: editor तो load हो जाता है, लेकिन save करते समय “Updating failed. The response is not a valid JSON response.” आता है। यह JavaScript की समस्या नहीं है। Editor /wp-json/wp/v2/ पर REST API से बात करता है, और वापस साफ़ JSON की उम्मीद करता है। अगर कोई plugin या आपकी theme की functions.php JSON से पहले कोई PHP notice, warning, या fatal निकालती है — या कोई security plugin REST route block कर देता है, या कोई redirect plugin URL को rewrite कर देता है — तो response गड़बड़ हो जाता है और editor उसे parse नहीं कर पाता।

इसे कैसे ठीक करें, सबसे तेज़ तरीक़ा पहले

1. console पढ़िए। DevTools खुला रखकर failure को दोबारा reproduce कीजिए। Uncaught TypeError ... some-plugin/build/index.js जैसी error सीधे उसी दोषी plugin की तरफ़ इशारा करती है। यह अकेला क़दम ज़्यादातर मामले सुलझा देता है और आपको आँख मूँदकर bisecting करने से बचा लेता है।

2. browser को rule out कीजिए। Hard-refresh कीजिए (Cmd/Ctrl+Shift+R), फिर extensions बंद करके एक incognito window आज़माइए। Ad blockers और privacy extensions कभी-कभी admin scripts हटा देते हैं। अगर incognito में काम करता है, तो समस्या browser extension या पुरानी cache है, आपकी साइट नहीं।

3. REST API को सीधे check कीजिए अगर आपको “not a valid JSON” वाला message दिखा हो। Browser में https://yoursite.com/wp-json/ पर जाइए। आपको JSON की एक दीवार मिलनी चाहिए। अगर आपको HTML, कोई 500, या login redirect मिलता है, तो वही आपका bug है — कोई plugin REST response तोड़ रहा है, ख़ुद editor नहीं।

4. अपने plugins को bisect कीजिए। सबको deactivate कीजिए, पुष्टि कीजिए कि editor load होता है, फिर एक-एक करके तब तक reactivate कीजिए जब तक वह दोबारा न टूटे। अगर आप wp-admin से पूरी तरह बाहर हैं, तो SFTP पर folder का नाम बदलकर यह कीजिए:

mv wp-content/plugins wp-content/plugins_off

Folder ग़ायब होने पर WordPress सब कुछ deactivate कर देता है। इसे वापस rename कीजिए, फिर plugins को एक-एक करके अंदर-बाहर कीजिए।

5. theme test कीजिए। Twenty Twenty-Four पर switch कीजिए। जो theme टूटी हुई editor JS enqueue करती है या functions.php में PHP error फेंकती है, वह बिल्कुल यही लक्षण पैदा करती है।

6. log चालू कीजिए और असली error पढ़िए। ख़ासकर REST/JSON failures के लिए, wp-config.php में debugging enable कीजिए:

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

Fatal error wp-content/debug.log में exact file और line number के साथ लिख दी जाती है। अगर वह stack trace घना हो — namespaced class names, require chains, दस line के trace के नीचे दबा हुआ एक fatal — तो उसे हमारे WordPress error log decoder में paste कीजिए, ताकि साफ़ शब्दों में देख सकें कि असल में कौन-सा plugin और कौन-सी line इसे trigger कर रही है। यही “कुछ टूटा है” और “इस ख़ास plugin की line 214 टूटी है” के बीच का फ़र्क़ है।

अगर आपको लगता है कि script concatenation असली गुनहगार को छिपा रहा है, तो हर script को अलग load होने के लिए force कीजिए ताकि console error ठीक एक file पर इशारा करे:

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

क्या नहीं करना चाहिए

Classic Editor plugin install करके इसे fix मत समझिए। यह कुछ ठीक नहीं करता — यह सिर्फ़ block editor को छिपा देता है ताकि आपको error दिखना बंद हो जाए। टूटी हुई JavaScript या टूटा हुआ REST response अब भी वहीं है, और वह आपको site editor में, widgets में, या अगली बार update करते समय फिर से काटेगा। पहले diagnose कीजिए; Classic पर तभी जाइए जब आपने सोच-समझकर blocks का इस्तेमाल बंद करने का फ़ैसला किया हो।

PHP memory limit को आदतन मत बढ़ाइए। यह internet का पसंदीदा copy-paste fix है, लेकिन ख़ाली editor कभी-कभार ही memory ख़त्म होने की वजह से होता है। असली memory exhaustion एक ख़ास fatal फेंकता है — “Allowed memory size of N bytes exhausted” — जो आपको debug.log में दिखेगा। अगर वह line वहाँ नहीं है, तो ज़्यादा memory कुछ नहीं बदलती।

WordPress core को दोबारा install मत कीजिए। हर install पर core files byte-दर-byte एक जैसी होती हैं। अगर core ही समस्या होती, तो दुनिया की हर WordPress साइट का editor अभी टूटा हुआ होता। ग़लती लगभग हमेशा आपके plugins या theme में होती है, और core reinstall करने से चीज़ें overwrite होने का ख़तरा रहता है जबकि ठीक कुछ नहीं होता।

अपने cache plugin को पहले क़दम के तौर पर आँख मूँदकर clear या disable मत कीजिए। Aggressive JS minification और concatenation editor को तोड़ सकती है, इसलिए test करना ठीक है — लेकिन cache को बिना सोचे flush करने से पहले console check कीजिए। अंदाज़ा लगाना ही वह तरीक़ा है जिससे पाँच मिनट का fix एक पूरी दोपहर में बदल जाता है।

अभी भी अटके हुए हैं?

अगर console साफ़ है, REST API valid JSON देता है, और पूरा plugin-और-theme bisect करने के बाद भी editor मरा हुआ है, तो जवाब लगभग हमेशा debug.log में बैठा होता है। WP_DEBUG_LOG enable कीजिए, failure को एक बार reproduce कीजिए, और निकले हुए fatal को error log decoder से चलाइए। Stack trace file का नाम बता देता है — वहीं से शुरू कीजिए।