حل مشكلة عدم تحميل محرر الكتل في ووردبريس

في أغلب الحالات، يكون محرر الكتل الذي يرفض التحميل في ووردبريس ناتجًا عن خطأ في JavaScript — سكربت واحد معطوب من إضافة أو قالب يوقف تطبيق React بالكامل، فلا يكتمل عرض المحرر أبدًا. افتح وحدة تحكم المطور في متصفحك (F12، أو Cmd+Option+I على الماك)، أعد تحميل شاشة التحرير، واقرأ الخطأ الأحمر. فهو يذكر دائمًا تقريبًا اسم الملف الذي أطلق الخطأ. هذا السطر الواحد يخبرك بالإضافة التي عليك تعطيلها، وعادةً ما تعود إلى الكتابة في أقل من خمس دقائق. أما إعادة تثبيت ووردبريس، ورفع حد ذاكرة PHP، والتبديل إلى المحرر الكلاسيكي، فهي الاقتراحات الثلاثة الأكثر شيوعًا على الإنترنت، وكلها ثلاثتها خطأ في العادة.

لماذا يتعطل المحرر بهذه الطريقة

محرر الكتل (Gutenberg) هو تطبيق React أحادي الصفحة يعمل داخل wp-admin/post.php وpost-new.php. يقوم ووردبريس بتحميل مجموعة من حزم السكربتات — wp-blocks وwp-element وwp-editor وwp-edit-post — ويبدأ التطبيق عبر wp.domReady(). يتوقف تنفيذ JavaScript عند أول استثناء غير مُعالَج. لذلك إذا أطلق أي سكربت مُحمَّل خطأً أثناء تهيئة المحرر، يموت كل ما بعده معه. فتنهار منطقة كتابة مقالك التي أعددتها بعناية إلى لوحة بيضاء فارغة أو تظهر رسالة “واجه المحرر خطأً غير متوقع”.

يقوم ووردبريس افتراضيًا أيضًا بدمج سكربتات لوحة التحكم في عدد أقل من الطلبات. هذا يعني أن سكربت JavaScript معطوبًا من إضافة واحدة قد يجرّ معه سكربتات أخرى لا علاقة لها به مُحمَّلة في الحزمة نفسها، ولهذا لا يكون المتسبب واضحًا دائمًا من السلوك وحده. لكنه واضح في وحدة التحكم.

أما نمط الفشل الثاني فيبدو مختلفًا: يُحمَّل المحرر، لكن الحفظ يطلق “فشل التحديث. الرد ليس ردًا صالحًا بصيغة JSON.” وهذه ليست مشكلة JavaScript. المحرر يتواصل مع REST API عند /wp-json/wp/v2/، ويتوقع أن يعود إليه JSON نظيف. فإذا أطلقت إضافة أو ملف functions.php الخاص بقالبك إشعار أو تحذير أو خطأ فادح في PHP قبل الـ JSON — أو حجبت إضافة أمان مسار REST، أو أعادت إضافة إعادة توجيه كتابة الرابط — يتلوث الرد ولا يستطيع المحرر تحليله.

كيفية حلها، الأسرع أولًا

1. اقرأ وحدة التحكم. أعد إنتاج الفشل ووحدة تحكم المطور مفتوحة. خطأ مثل Uncaught TypeError ... some-plugin/build/index.js يشير مباشرةً إلى الإضافة المخالفة. هذه الخطوة الواحدة تحل غالبية الحالات وتوفر عليك عناء التجربة والاستبعاد الأعمى.

2. استبعد المتصفح. أعد التحميل بالكامل (Cmd/Ctrl+Shift+R)، ثم جرّب نافذة تصفح خفي مع تعطيل الإضافات. أحيانًا تنزع مانعات الإعلانات وإضافات الخصوصية سكربتات لوحة التحكم. إذا عمل في وضع التصفح الخفي، فالمشكلة في إضافة متصفح أو ذاكرة تخزين مؤقت قديمة، وليست في موقعك.

3. افحص REST API مباشرةً إذا رأيت رسالة “ليس ردًا صالحًا بصيغة JSON”. زر https://yoursite.com/wp-json/ في المتصفح. من المفترض أن تحصل على جدار من JSON. فإذا حصلت على HTML أو خطأ 500 أو إعادة توجيه لتسجيل الدخول، فهذا هو الخلل — إضافة ما تعطب رد REST، وليس المحرر نفسه.

4. جرّب استبعاد الإضافات واحدة تلو الأخرى. عطّلها كلها، وتأكد من تحميل المحرر، ثم أعد تفعيلها واحدة تلو الأخرى حتى تتعطل مجددًا. وإذا كنت محجوبًا عن wp-admin تمامًا، فافعل ذلك عبر SFTP بإعادة تسمية المجلد:

mv wp-content/plugins wp-content/plugins_off

يعطّل ووردبريس كل شيء عند اختفاء المجلد. أعد تسميته إلى ما كان عليه، ثم انقل الإضافات إلى الداخل والخارج واحدة تلو الأخرى.

5. اختبر القالب. بدّل إلى قالب Twenty Twenty-Four. القالب الذي يحمّل سكربت JavaScript معطوبًا للمحرر أو يطلق خطأ PHP في functions.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 مع اسم الملف ورقم السطر بالضبط. وإذا كان تتبع المكدس كثيفًا — أسماء أصناف بمساحات أسماء، سلاسل require، خطأ فادح مدفون تحت عشرة أسطر من التتبع — فألصقه في أداة فك سجل أخطاء ووردبريس لترى، بعبارات واضحة، أي إضافة وأي سطر أطلقه فعلًا. هذا هو الفرق بين “هناك شيء معطوب” و”السطر 214 من هذه الإضافة تحديدًا معطوب”.

إذا اشتبهت في أن دمج السكربتات يخفي المتسبب الحقيقي، فأجبر كل سكربت على التحميل منفصلًا حتى يشير خطأ وحدة التحكم إلى ملف واحد بالضبط:

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

ما لا يجب فعله

لا تثبّت إضافة المحرر الكلاسيكي وتعتبر المشكلة محلولة. فهي لا تصلح شيئًا — بل تخفي محرر الكتل حتى تتوقف عن رؤية الخطأ. سيظل الـ JavaScript المعطوب أو رد REST المعطوب موجودًا، وسيعضّك مجددًا في محرر الموقع، أو في الودجات، أو في المرة التالية التي تحدّث فيها. شخّص أولًا؛ ولا تلجأ إلى الكلاسيكي إلا إذا اتخذت قرارًا واعيًا بالتوقف عن استخدام الكتل.

لا ترفع حد ذاكرة PHP بشكل انعكاسي. فهو الحل الأكثر شيوعًا للنسخ واللصق على الإنترنت، لكن المحرر الفارغ نادرًا ما يكون بسبب نفاد الذاكرة. نفاد الذاكرة الحقيقي يطلق خطأً فادحًا محددًا — “Allowed memory size of N bytes exhausted” — ستراه في debug.log. فإذا لم يكن هذا السطر موجودًا، فلن تغيّر زيادة الذاكرة شيئًا.

لا تعد تثبيت نواة ووردبريس. ملفات النواة متطابقة بايتًا ببايت في كل عملية تثبيت. لو كانت النواة هي المشكلة، لكان محرر كل موقع ووردبريس على وجه الأرض معطوبًا الآن. الخلل يكون دائمًا تقريبًا في إضافاتك أو قالبك، وإعادة تثبيت النواة تخاطر بالكتابة فوق أشياء دون إصلاح أي شيء.

لا تمسح أو تعطّل إضافة التخزين المؤقت بشكل أعمى كخطوة أولى. تصغير ودمج JavaScript العدواني قد يعطب المحرر، فيستحق الاختبار — لكن افحص وحدة التحكم قبل أن تبدأ في مسح ذواكر التخزين المؤقت عشوائيًا. التخمين هو ما يحوّل حلًا مدته خمس دقائق إلى ظهيرة كاملة.

ما زلت عالقًا؟

إذا كانت وحدة التحكم نظيفة، ويعيد REST API صيغة JSON صالحة، ولا يزال استبعاد كل الإضافات والقوالب يترك المحرر معطلًا، فالجواب يكون دائمًا تقريبًا موجودًا في debug.log. فعّل WP_DEBUG_LOG، أعد إنتاج الفشل مرة واحدة، ومرّر الخطأ الفادح الناتج عبر أداة فك سجل الأخطاء. تتبع المكدس يذكر الملف — ابدأ من هناك.