مواد پر جائیں
ایررز اور کریشز

WordPress بلاک ایڈیٹر لوڈ نہ ہونے کا حل

زیادہ تر معاملات میں، جو WordPress بلاک ایڈیٹر لوڈ نہیں ہوتا اس کی وجہ ایک JavaScript ایرر ہوتی ہے — کسی پلگ اِن یا تھیم کی ایک خراب اسکرپٹ پورے React ایپ کو روک دیتی ہے، اور

شائع شدہ

زیادہ تر معاملات میں، جو WordPress بلاک ایڈیٹر لوڈ نہیں ہوتا اس کی وجہ ایک JavaScript ایرر ہوتی ہے — کسی پلگ اِن یا تھیم کی ایک خراب اسکرپٹ پورے React ایپ کو روک دیتی ہے، اور ایڈیٹر کبھی مکمل طور پر رینڈر نہیں ہو پاتا۔ اپنے براؤزر کا ڈیولپر کنسول کھولیں (F12، یا Mac پر Cmd+Option+I)، ایڈٹ اسکرین کو دوبارہ لوڈ کریں، اور سرخ رنگ کی ایرر پڑھیں۔ یہ تقریباً ہمیشہ اُس فائل کا نام بتا دیتی ہے جس نے مسئلہ پیدا کیا۔ وہی ایک لائن آپ کو بتا دیتی ہے کہ کون سا پلگ اِن بند کرنا ہے، اور عام طور پر آپ پانچ منٹ کے اندر دوبارہ لکھنے کی طرف لوٹ سکتے ہیں۔ WordPress دوبارہ انسٹال کرنا، PHP کی memory limit بڑھانا، اور Classic Editor پر منتقل ہونا — یہ آن لائن سب سے زیادہ دی جانے والی تین تجاویز ہیں، اور یہ تینوں عموماً غلط قدم ہوتے ہیں۔

ایڈیٹر جس طرح سے ٹوٹتا ہے، ویسا کیوں ہوتا ہے

بلاک ایڈیٹر (Gutenberg) ایک سنگل پیج React ایپلیکیشن ہے جو wp-admin/post.php اور post-new.php کے اندر چلتی ہے۔ WordPress اسکرپٹ پیکجز کا ایک ڈھیر enqueue کرتا ہے — wp-blocks، wp-element، wp-editor، wp-edit-post — اور ایپ wp.domReady() کے ذریعے بوٹ اسٹریپ ہوتی ہے۔ JavaScript پہلی ہی غیر ہینڈل شدہ ایکسیپشن پر عمل کرنا بند کر دیتی ہے۔ لہٰذا اگر کوئی بھی enqueue کی گئی اسکرپٹ ایڈیٹر کے initialize ہونے کے دوران مسئلہ پیدا کرتی ہے، تو اس کے بعد کی ہر چیز اسی کے ساتھ ختم ہو جاتی ہے۔ آپ کا محنت سے لکھا ہوا پوسٹ ایریا ایک خالی سفید پین میں بدل جاتا ہے یا “The editor has encountered an unexpected error” کا پیغام آ جاتا ہے۔

ڈیفالٹ طور پر WordPress ایڈمن اسکرپٹس کو کم درخواستوں میں concatenate بھی کر دیتا ہے۔ اس کا مطلب ہے کہ ایک پلگ اِن کی خراب JS اسی بنڈل میں لوڈ ہونے والی غیر متعلقہ اسکرپٹس کو بھی نیچے گھسیٹ سکتی ہے، اسی لیے صرف رویّے سے مجرم ہمیشہ واضح نہیں ہوتا۔ کنسول واضح کرتا ہے۔

دوسرا فیلیئر موڈ مختلف نظر آتا ہے: ایڈیٹر لوڈ ہو جاتا ہے، لیکن سیو کرتے وقت “Updating failed. The response is not a valid JSON response.” آ جاتا ہے۔ یہ JavaScript کا مسئلہ نہیں ہے۔ ایڈیٹر /wp-json/wp/v2/ پر موجود REST API سے بات کرتا ہے، اور اسے بدلے میں صاف ستھری JSON کی توقع ہوتی ہے۔ اگر کوئی پلگ اِن یا آپ کے تھیم کی functions.php JSON سے پہلے کوئی PHP نوٹس، وارننگ یا فیٹل خارج کرتی ہے — یا کوئی سیکیورٹی پلگ اِن REST روٹ کو بلاک کر دیتا ہے، یا کوئی ری ڈائریکٹ پلگ اِن URL کو دوبارہ لکھ دیتا ہے — تو ریسپانس آلودہ ہو جاتا ہے اور ایڈیٹر اسے پارس نہیں کر پاتا۔

اسے کیسے ٹھیک کریں، سب سے تیز پہلے

1. کنسول پڑھیں۔ DevTools کھلا رکھ کر فیلیئر کو دوبارہ پیدا کریں۔ Uncaught TypeError ... some-plugin/build/index.js جیسی ایرر سیدھا اُس ذمہ دار پلگ اِن کی طرف اشارہ کرتی ہے۔ یہ ایک قدم زیادہ تر معاملات حل کر دیتا ہے اور آپ کو اندھا دھند bisecting سے بچا لیتا ہے۔

2. براؤزر کو مسترد کریں۔ ہارڈ ری فریش کریں (Cmd/Ctrl+Shift+R)، پھر ایکسٹینشنز بند کر کے incognito ونڈو آزمائیں۔ ایڈ بلاکرز اور پرائیویسی ایکسٹینشنز کبھی کبھار ایڈمن اسکرپٹس کو ہٹا دیتے ہیں۔ اگر incognito میں کام کر جائے، تو مسئلہ کوئی براؤزر ایکسٹینشن یا پرانا کیشے ہے، آپ کی سائٹ نہیں۔

3. REST API کو براہِ راست چیک کریں اگر آپ کو “not a valid JSON” کا پیغام نظر آیا تھا۔ براؤزر میں https://yoursite.com/wp-json/ پر جائیں۔ آپ کو JSON کی ایک دیوار ملنی چاہیے۔ اگر آپ کو HTML، 500، یا لاگ اِن ری ڈائریکٹ ملے، تو یہی آپ کا مسئلہ ہے — کوئی پلگ اِن REST ریسپانس کو توڑ رہا ہے، خود ایڈیٹر نہیں۔

4. اپنے پلگ اِنز کو bisect کریں۔ ان سب کو غیر فعال کریں، تصدیق کریں کہ ایڈیٹر لوڈ ہو رہا ہے، پھر ایک ایک کر کے دوبارہ فعال کریں یہاں تک کہ یہ دوبارہ ٹوٹ جائے۔ اگر آپ wp-admin سے مکمل طور پر باہر ہو گئے ہیں، تو یہ کام SFTP کے ذریعے فولڈر کا نام بدل کر کریں:

mv wp-content/plugins wp-content/plugins_off

جب فولڈر غائب ہو جاتا ہے تو WordPress سب کچھ غیر فعال کر دیتا ہے۔ اس کا نام واپس بدلیں، پھر پلگ اِنز کو انفرادی طور پر اندر باہر کریں۔

5. تھیم کو ٹیسٹ کریں۔ Twenty Twenty-Four پر منتقل ہو جائیں۔ ایسا تھیم جو خراب ایڈیٹر JS enqueue کرتا ہے یا functions.php میں PHP خارج کرتا ہے، وہی علامات پیدا کرتا ہے۔

6. لاگ آن کریں اور اصل ایرر پڑھیں۔ خاص طور پر REST/JSON فیلیئرز کے لیے، wp-config.php میں ڈیبگنگ فعال کریں:

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

فیٹل عین فائل اور لائن نمبر کے ساتھ wp-content/debug.log میں لکھی جاتی ہے۔ اگر وہ اسٹیک ٹریس گنجان ہو — namespace والے کلاس نام، require چینز، دس لائنوں کے ٹریس کے نیچے دبی ہوئی فیٹل — تو اسے ہمارے WordPress error log decoder میں پیسٹ کریں تاکہ سادہ الفاظ میں دیکھ سکیں کہ اصل میں کون سے پلگ اِن اور لائن نے اسے پیدا کیا۔ یہی فرق ہے “کچھ ٹوٹا ہوا ہے” اور “اس مخصوص پلگ اِن کی لائن 214 ٹوٹی ہوئی ہے” کے درمیان۔

اگر آپ کو شک ہے کہ اسکرپٹ concatenation اصل مجرم کو چھپا رہا ہے، تو ہر اسکرپٹ کو الگ سے لوڈ ہونے پر مجبور کریں تاکہ کنسول ایرر ٹھیک ایک ہی فائل کی طرف اشارہ کرے:

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

کیا نہیں کرنا چاہیے

Classic Editor پلگ اِن انسٹال کر کے اسے حل شدہ نہ سمجھ لیں۔ یہ کچھ ٹھیک نہیں کرتا — یہ صرف بلاک ایڈیٹر کو چھپا دیتا ہے تاکہ آپ کو ایرر نظر آنا بند ہو جائے۔ خراب JavaScript یا خراب REST ریسپانس اب بھی موجود ہے، اور یہ آپ کو سائٹ ایڈیٹر میں، ویجٹس میں، یا اگلی بار اپڈیٹ کرتے وقت دوبارہ کاٹے گا۔ پہلے تشخیص کریں؛ Classic کی طرف صرف تب لوٹیں جب آپ نے سوچ سمجھ کر بلاکس کا استعمال چھوڑنے کا فیصلہ کر لیا ہو۔

فوراً PHP کی memory limit نہ بڑھائیں۔ یہ انٹرنیٹ کا پسندیدہ کاپی پیسٹ حل ہے، لیکن خالی ایڈیٹر شاذ و نادر ہی میموری ختم ہونے کی وجہ سے ہوتا ہے۔ اصل میموری ختم ہونے پر ایک مخصوص فیٹل آتی ہے — “Allowed memory size of N bytes exhausted” — جو آپ کو debug.log میں نظر آئے گی۔ اگر وہ لائن موجود نہیں، تو زیادہ میموری کچھ نہیں بدلتی۔

WordPress کور دوبارہ انسٹال نہ کریں۔ کور فائلیں ہر انسٹال پر بائٹ ٹو بائٹ ایک جیسی ہوتی ہیں۔ اگر کور مسئلہ ہوتا، تو دنیا کی ہر WordPress سائٹ کا ایڈیٹر ابھی ٹوٹا ہوا ہوتا۔ خرابی تقریباً ہمیشہ آپ کے پلگ اِنز یا تھیم میں ہوتی ہے، اور کور دوبارہ انسٹال کرنے سے چیزوں کے اوور رائٹ ہونے کا خطرہ ہوتا ہے جبکہ کچھ ٹھیک بھی نہیں ہوتا۔

اپنے کیشے پلگ اِن کو پہلے قدم کے طور پر بغیر سوچے صاف یا غیر فعال نہ کریں۔ جارحانہ JS minification اور concatenation ایڈیٹر کو توڑ سکتا ہے، اس لیے اسے آزمانا فائدہ مند ہے — لیکن اندھا دھند کیشے فلش کرنے سے پہلے کنسول چیک کریں۔ اندازہ لگانا ہی وہ طریقہ ہے جس سے پانچ منٹ کا حل ایک پوری دوپہر میں بدل جاتا ہے۔

اب بھی پھنسے ہوئے ہیں؟

اگر کنسول صاف ہے، REST API درست JSON لوٹا رہا ہے، اور پلگ اِن اور تھیم کا مکمل bisect کرنے کے بعد بھی ایڈیٹر مردہ ہے، تو جواب تقریباً ہمیشہ debug.log میں موجود ہوتا ہے۔ WP_DEBUG_LOG فعال کریں، فیلیئر کو ایک بار دوبارہ پیدا کریں، اور نتیجے میں آنے والی فیٹل کو error log decoder میں چلائیں۔ اسٹیک ٹریس فائل کا نام بتا دیتا ہے — وہیں سے شروع کریں۔