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

الاستجابة لا تمثل JSON صحيح في ووردبريس؟ تجربة حفظ من داخل المحرر

بتعدل مقالا في محرر ووردبريس، تضغط حفظ، وفجأة تظهر رسالة: فشلت عملية التحديث، الاستجابة لا تمثل رد JSON صحيح. هاي الرسالة ما بتخبرك عن السبب الحقيقي. معناها فقط ان المحرر كان ينتظر JSON من REST API، لكنه ما قدر يحلل الرد اللي وصله.

ممكن الرد يكون صفحة دخول HTML، منع من جدار حماية، 404 بسبب مسار REST، خطأ PHP برمز 500، او JSON سليم قبله تحذير او مسافة او نص من إضافة. عشان نثبت الفكرة، انشأنا مسودة فعلية وسببنا إخراجا زائدا في طلب حفظها فقط، ثم حفظناها من محرر المكونات داخل ايدج.

المشكلة ما زالت تظهر للمستخدمين. في موضوع داخل دعم ووردبريس استمرت الرسالة رغم تجربة حلول شائعة، وكانت النصيحة المفيدة فحص Console وNetwork والرد نفسه. وفي سؤال حديث على ريديت ظهرت الرسالة عند حفظ إعداد داخل المحرر. استخدمنا الحالات لاختيار المشكلة، اما القياسات التالية فمن نسختنا المحلية.

كيف عملنا التجربة؟

انشأنا مسودة باسم مختبر JSON ووضعنا عليها علامة داخلية، ثم فعلنا إضافة تجريبية صغيرة. الإضافة ما اثرت على REST كله؛ كانت تراقب طلب POST لمسودة المختبر فقط، وتطبع السطر التالي قبل استجابة ووردبريس:

SMSM_LAB_OUTPUT

بعدها فتحنا المسودة بجلسة مدير مؤقتة مولدة داخليا، غيرنا العنوان، وشغلنا عملية الحفظ من محرر ووردبريس نفسه. راقبنا طلب /wp-json/wp/v2/posts/115 وجسم الرد وحالة المحرر.

النتيجة الغريبة: الرد 200 لكنه مش JSON صالح

طلب الحفظ رجع برمز 200، ونوع المحتوى كان application/json; charset=UTF-8. لو فحصنا الرمز والترويسة فقط كنا رح نقول ان كل شيء سليم. لكن جسم الرد بدأ هكذا:

SMSM_LAB_OUTPUT
{"id":115,"date":"2026-09-05T13:51:42",...}

كائن JSON نفسه موجود، لكن في نص قبله. دالة تحليل JSON تتوقع ان يبدأ الرد بقيمة JSON، لذلك فشلت. محرر ووردبريس عرض التنبيه الاحمر الحقيقي: فشلت عملية التحديث. الاستجابة لا تمثل رد JSON صحيح. وبقيت حالة المحرر تقول ان في تغييرات غير محفوظة.

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

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

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

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

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

شو تغير بعد تعطيل المسبب؟

عطلنا الإضافة التجريبية فقط، واعدنا فتح المسودة وحفظها بالطريقة نفسها. الرد بقي 200 ونوعه بقي application/json، لكنه بدأ مباشرة بالقوس {. نجح JSON.parse()، ظهر تنبيه تم حفظ المسودة، وصارت حالة التغييرات غير المحفوظة false.

تقرير قياس يوضح ان الردين كانا 200 وapplication/json لكن النص الزائد افسد التحليل قبل الاصلاح
نفس طلب الحفظ: الرمز والترويسة متطابقان، لكن النص الزائد قبل القوس هو اللي افسد الحالة الاولى.
محرر مكونات ووردبريس يعرض تم حفظ المسودة بعد تعطيل الإخراج الزائد وعودة استجابة REST سليمة
بعد تعطيل الإخراج الزائد: محرر ووردبريس عرض تم حفظ المسودة ولم تبق تغييرات معلقة.

اول خطوة صحيحة: افتح طلب REST نفسه

  1. افتح محرر المقال واضغط F12.
  2. انتقل إلى Network وفعل الاحتفاظ بالسجل اذا الصفحة تعيد التحميل.
  3. اضغط حفظ او تحديث مرة واحدة.
  4. ابحث عن wp-json او طلب نوعه fetch.
  5. افتح الطلب وراجع Status وResponse وHeaders والرابط النهائي بعد التحويل.

لا تكتفي برسالة Console العامة. جسم Response هو اللي يفرق بين صفحة HTML وتحذير PHP ورفض صلاحية وكائن JSON ملوث.

كيف تقرا رمز الاستجابة؟

200 لكن الجسم يبدأ بنص او تحذير

هذا سيناريو تجربتنا. ابحث عن echo او print_r او var_dump من إضافة او قالب، تحذير PHP ظاهر، او BOM قبل بداية ملف PHP. افتح اول احرف من الرد؛ غالبا تعطيك اسم الملف او نص المسبب.

لا تستخدم مسح الإخراج كحل دائم من غير معرفة المصدر. ممكن يخفي رسالة مهمة ويترك الخطأ يتكرر في REST او AJAX او تنزيل الملفات. اصلح الملف اللي يطبع الإخراج، واوقف عرض اخطاء PHP للزوار مع بقاء التسجيل في ملف سجل آمن.

401 او 403

هنا الرد قد يكون JSON صحيحا لكنه يرفض الحفظ، او قد يكون صفحة منع من WAF. افحص الرسالة داخل الرد. محرر ووردبريس يستخدم كوكي جلسة ومعه nonce في ترويسة X-WP-Nonce. توثيق مصادقة REST الرسمي يوضح ان غياب nonce يجعل الطلب غير مصادق حتى لو كانت كوكي الدخول موجودة.

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

404

افتح /wp-json/ مباشرة. اذا رجع صفحة 404، راجع قواعد الروابط الدائمة وتهيئة الخادم. حفظ الروابط الدائمة قد يعيد كتابة القواعد ويحل الحالة فعلا، لكنه مش وصفة لكل خطأ JSON. في تجربتنا المسار كان صحيحا والرد 200، لذلك حفظ الروابط ما كان رح يزيل النص الزائد.

301 او 302 او صفحة دخول HTML

قارن WordPress Address وSite Address والبروتوكول وwww. تحويل REST إلى صفحة الدخول او الدومين القديم يعطي المحرر HTML بدل JSON. راجع كمان قواعد التحويل في الاستضافة وCloudflare، خصوصا القواعد اللي تطابق جزءا من رابط المقال او نوع محتوى مخصص.

500

راجع سجل PHP والخادم في وقت الضغط على حفظ. السبب قد يكون خطأ قاتل، نفاد ذاكرة، استعلام قاعدة بيانات، او تعارض داخل فلتر REST. لا ترفع حد الذاكرة بشكل عشوائي قبل قراءة السطر المسبب.

عزل الإضافة او القالب بدون تخريب الموقع

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

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

ماذا تفحص داخل الاستجابة؟

  • هل اول حرف مفيد هو { او [؟
  • هل الرد يبدأ بـ <!doctype html> او صفحة دخول؟
  • هل فيه Warning او Notice واسم ملف PHP ورقم سطر؟
  • هل WAF رجع صفحة منع او رقم حادثة؟
  • هل الرابط النهائي مختلف عن رابط الطلب الاصلي بسبب تحويل؟
  • هل نوع المحتوى JSON فعلا، وهل الجسم يطابقه؟

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

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

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

الخلاصة

رسالة الاستجابة لا تمثل JSON صحيح مش تشخيص، بل نتيجة فشل المحرر في فهم رد REST. تجربتنا رجعت 200 وapplication/json في الحالتين، لكن سطر SMSM_LAB_OUTPUT قبل كائن JSON سبب رسالة الخطأ وبقاء المحرر بحالة غير محفوظة. بعد تعطيل المسبب بدأ الرد بالقوس، نجح التحليل، وظهرت رسالة تم حفظ المسودة.

افتح Network قبل تطبيق حلول عشوائية. الرمز والجسم والرابط النهائي يحددوا طريقك: اصلح الإخراج الزائد، المصادقة، WAF، التحويل، الروابط الدائمة، او خطأ PHP حسب الدليل اللي قدامك.