انتقل للمحتوى
المحرر والوسائط

محرر ووردبريس صفحة بيضاء؟ تجربة تعزل خطا JavaScript

بتفتح مقالة او صفحة في ووردبريس، شريط الإدارة ظاهر لكن مكان المحرر ابيض؟ قبل ما ترفع ذاكرة PHP او تعيد تثبيت ووردبريس، لازم تعرف اذا الصفحة فشلت على الخادم ولا وصلت سليمة وتعطلت داخل المتصفح بسبب JavaScript.

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

المشكلة ظهرت هذا الاسبوع في موضوع دعم ووردبريس عن محرر 7.1 الابيض واخطاء JavaScript، وظهرت كمان في نقاش ريديت عن صفحة التحرير الفارغة. استخدمناهما لاختيار السؤال، اما الخطا واللقطات والقياسات التالية فمن مختبرنا.

ملخص التجربة

  • قبل الخطا: صفحة التحرير رجعت HTTP 200، ووجد المتصفح اشارتين واضحتين لواجهة المحرر، وما سجل اي خطا صفحة.
  • اثناء الخطا: الصفحة بقيت HTTP 200، لكن اشارات الواجهة صارت صفرا وسجل المتصفح SMSM_ARTICLE_18_CONTROLLED_EDITOR_FAILURE.
  • بعد تعطيل الإضافة: بقي HTTP 200، رجعت اشارتا الواجهة، وصار عدد اخطاء الصفحة صفرا.
  • المسودة نفسها ما انحذفت وما احتجنا نغير القالب او قاعدة البيانات.

الحالة السليمة قبل التغيير

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

لقطة فعلية لمحرر ووردبريس وهو يعرض عنوان المسودة ومحتواها قبل تفعيل إضافة الخطا التجريبية
لقطة المحرر الحقيقية قبل تفعيل إضافة المختبر. المسودة والعنوان ومحتوى الفقرة ظاهرون.

هذه الخطوة مهمة لانها تعطينا خط اساس. بدونها ممكن ننسب شاشة قديمة او مشكلة دخول إلى الإضافة التي سنختبرها.

كيف اعدنا الشاشة البيضاء؟

الإضافة التجريبية استخدمت enqueue_block_editor_assets لتحميل ملف داخل واجهة المحرر فقط. هذا هو المسار الذي يشرحه دليل تحميل ملفات محرر المكونات الرسمي للإضافات التي تضيف ازرارا او لوحات او تعديلات JavaScript.

في المختبر تعمد الملف حذف عناصر مساحة التحرير ثم رمى خطا JavaScript باسم واضح. هذه محاكاة مضبوطة لاثر إضافة محرر سيئة؛ ما بندعي ان كل شاشة بيضاء تحذف العناصر بالطريقة نفسها.

لقطة فعلية لشاشة تحرير ووردبريس وقد اختفت واجهة المحرر بينما بقي شريط الإدارة ظاهرا بعد خطا JavaScript تجريبي
بعد تفعيل الإضافة: شريط الإدارة بقي، لكن مساحة المحرر اختفت وصارت الصفحة بيضاء.

المهم ان طلب HTML نفسه ما فشل. المتصفح استلم الصفحة برمز 200، وبعدها نفذ ملف JavaScript الذي اوقف الواجهة. لو فحصنا الرمز فقط لقلنا الصفحة شغالة، ولو نظرنا للشاشة فقط لقلنا الخادم توقف. القياسان معا اعطيا التشخيص الصحيح.

شو سجل المتصفح؟

التقطنا اخطاء الصفحة واشارات عناصر المحرر في Playwright. قبل التفعيل كان عدد اشارات الواجهة 2. اثناء الخطا صار صفر وظهر اسم الخطا التجريبي مرة واحدة. بعد التعطيل رجع العدد إلى 2 واختفى الخطا.

تقرير قياس يبين HTTP 200 في الحالات الثلاث واختفاء اشارات المحرر وظهور خطا JavaScript في الحالة المعطلة فقط
HTTP بقي 200 في الحالات الثلاث. التغيير الحقيقي كان داخل JavaScript وواجهة المحرر.

على موقعك افتح DevTools بالزر F12 ثم Console قبل تحديث صفحة التحرير. صور اول خطا احمر كاملا، وافتح الرابط الذي يظهر اسم الملف والسطر. لا تبدأ بآخر عشرات الاخطاء؛ اول خطا ممكن يوقف مكتبة، وما بعده يكون نتيجة متسلسلة.

فيديو توثيق التجربة الفعلية

هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.

تسجيل شاشة صامت ومتواصل لتجربة فعلية داخل بيئة محلية معزولة. يعرض الحالة السليمة، تنفيذ المسبب، ظهور النتيجة، ثم الاصلاح واعادة الفحص. لا يستخدم صورا مركبة.

بعد تعطيل المسبب

عطلنا إضافة المختبر واعدنا الرابط نفسه في جلسة مدير جديدة. ما مسحنا المسودة وما غيرنا القالب. ظهر العنوان والفقرة والشريط الجانبي، واختفى خطا الصفحة.

لقطة فعلية لمحرر ووردبريس بعد تعطيل إضافة JavaScript التجريبية وعودة المسودة والمحتوى كما كانا
عودة المحرر بعد تعطيل ملف JavaScript المسبب. محتوى المسودة بقي كما هو.

كيف تفرق بين خطا JavaScript وخطا PHP؟

مؤشرات JavaScript

  • شريط الإدارة او جزء من wp-admin يظهر، لكن مساحة المحرر فارغة.
  • طلب الصفحة الرئيسي يرجع 200.
  • Console فيه TypeError او ReferenceError او خطا من ملف إضافة.
  • المحرر يعمل في نافذة خاصة او بعد تعطيل إضافة تحسين ملفات.

مؤشرات PHP او الخادم

  • الطلب الرئيسي يرجع 500 او صفحة خطا قبل ظهور شريط الإدارة.
  • سجل PHP فيه fatal error بنفس الثانية.
  • المشكلة تظهر حتى مع تعطيل JavaScript او من طلب مباشر.
  • كل صفحات wp-admin او الموقع تتوقف، مش المحرر فقط.

ممكن السببان يجتمعوا. مثلا REST يرجع HTML خطا من PHP، ثم JavaScript يفشل وهو يحاول تحليل JSON. وقتها راجع Network وConsole معا.

ترتيب تشخيص عملي

  1. افتح الصفحة في نافذة خاصة حتى تستبعد إضافة متصفح وكاش جلسة.
  2. من Network سجل رمز طلب post.php او post-new.php.
  3. من Console انسخ اول خطا واسمه واسم الملف والسطر.
  4. افحص تبويب Network عن ملفات JS ترجع 404 او 403 او نوع HTML بدل JavaScript.
  5. جرب تحديثا قويا Ctrl+F5 بعد تفريغ كاش CDN والإضافة.
  6. عطل إضافات المحرر والتحسين والحماية واحدة واحدة على staging.
  7. اذا رجع المحرر، اعد تفعيل الإضافات بالتدريج حتى تعيد الخطا.
  8. سجل المجموعة المسببة قبل تحديث او استبدال اي إضافة.

اذا ما بتقدر تدخل المحرر لتعطل الإضافة

تعطيل الإضافة ما يحتاج محرر المقال. من شاشة الإضافات عطل اخر إضافة حدثتها. اذا لوحة الإدارة كلها لا تفتح، غير اسم مجلد الإضافة المحددة من مدير ملفات الاستضافة. لا تغير اسم مجلد plugins كله الا كاختبار مؤقت وانت عارف اثر تعطيل جميع الإضافات.

قبل التغيير صور قائمة الإضافات الفعالة واحفظ اسم المجلد الاصلي. بعد رجوع المحرر اعد الاسم، لكن لا تفعل المسبب قبل تحديثه او مراجعة مطوره.

ملفات الدمج والتصغير والكاش

إضافات السرعة ممكن تجمع ملفات قديمة مع ملفات جديدة بعد تحديث ووردبريس. اذا اسم الخطا يشير إلى ملف كاش مجمع، عطل الجمع والتأخير مؤقتا، فرغ الكاش من الإضافة والخادم وCDN، ثم جرب. لا تمسح كاش المتصفح فقط وتنسى النسخة المخزنة على الخادم.

افحص Content-Type لملف JS. لازم يكون JavaScript، مش صفحة HTML فيها 404 او تسجيل دخول. ملف يرجع 200 لكنه يحتوي HTML ممكن ينتج خطا Unexpected token <.

REST API ممكن يعطي شاشة مشابهة

محرر المكونات يعتمد على REST لجلب المقال والإعدادات. اذا Console يذكر api-fetch، افتح طلب REST الفاشل في Network واقرأ Status وResponse. 401 او 403 يوجهك للمصادقة والحماية، و500 يوجهك لسجل الخادم، وHTML بدل JSON يوجهك لتحويل او خطا مطبوع.

لا تعطل REST كله كحل. هذا قد يزيد الشاشة البيضاء لانه يقطع المسار الذي يحتاجه المحرر.

هل حفظ الروابط الدائمة يصلح المشكلة؟

حفظ الروابط ممكن يصلح مسارات REST في حالات محددة، لكنه ما يصلح خطا JavaScript من ملف إضافة مثل تجربتنا. نفذ الخطوة لما Network يثبت ان مسارات REST ترجع 404، مش لانها نصيحة محفوظة لكل شاشة بيضاء.

هل نرفع الذاكرة؟

ارفعها فقط اذا سجل PHP يقول نفاد ذاكرة او طلب REST يرجع 500 بسبب ذلك. في تجربتنا HTTP بقي 200 وما كان في fatal PHP، لذلك رفع الذاكرة ما كان ليغير ملف JavaScript المسبب.

معلومات مفيدة ترسلها للمطور

  • نسخة ووردبريس وPHP والمتصفح.
  • اسم الإضافة ونسختها واخر تغيير قبل ظهور المشكلة.
  • اول خطا Console مع اسم الملف والسطر.
  • طلب Network الفاشل ورمزه من غير كوكي او nonce.
  • هل الخطا يختفي مع الإضافة وحدها او مع تعارض إضافتين.
  • لقطة الشاشة ووقت الاختبار.

تنظيف المختبر

بعد التقاط الحالات عطلنا إضافة JavaScript وحذفنا المسودة التجريبية وملفات الإضافة وجلسة الدخول المؤقتة. ما غيرنا محتوى المقالات المنشورة، وبقيت الإضافة الفعالة الوحيدة إضافة سمسم لاب.

الخلاصة

الشاشة البيضاء داخل المحرر مش دليل كافي على توقف PHP. تجربتنا رجعت HTTP 200 طوال الوقت، لكن ملف JavaScript واحد اخفى الواجهة وسجل خطا واضحا. تعطيله رجع المحرر والمسودة مباشرة.

ابدأ بالطبقة الصحيحة: HTTP وNetwork وConsole. التقط اول خطا، اعزل الإضافة او ملف الكاش، واعد نفس المسودة بعد التعطيل. هيك بتحل السبب من غير اعادة تثبيت ووردبريس او رفع موارد ما الها علاقة.