الاستجابة لا تمثل 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، وتغير وقت تعديل المسودة رغم ان المحرر اعتبر الحفظ فاشلا. هاي ملاحظة مهمة: لا تضغط حفظ عشر مرات مباشرة. افتح Network وشوف الرد، وافحص المسودة في تبويب ثاني قبل تكرار عملية قد تنفذ جزئيا.
فيديو توثيق التجربة الفعلية
هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.
شو تغير بعد تعطيل المسبب؟
عطلنا الإضافة التجريبية فقط، واعدنا فتح المسودة وحفظها بالطريقة نفسها. الرد بقي 200 ونوعه بقي application/json، لكنه بدأ مباشرة بالقوس {. نجح JSON.parse()، ظهر تنبيه تم حفظ المسودة، وصارت حالة التغييرات غير المحفوظة false.


اول خطوة صحيحة: افتح طلب REST نفسه
- افتح محرر المقال واضغط F12.
- انتقل إلى Network وفعل الاحتفاظ بالسجل اذا الصفحة تعيد التحميل.
- اضغط حفظ او تحديث مرة واحدة.
- ابحث عن
wp-jsonاو طلب نوعه fetch. - افتح الطلب وراجع 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 حسب الدليل اللي قدامك.