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

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

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

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

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

ماذا حصل في تجربتنا؟

اشتغلت التجربة على ووردبريس 7.1 مع PHP 8.3.30 وMySQL 8.4.3. جهزنا صفحة فيها عبارة “النسخة القديمة قبل التعديل”، وطلبناها كزائر غير مسجل. اول استجابة كانت 200 وبعلامة MISS، وهذا يعني ان الكاش لم يجد نسخة جاهزة فاخذ الصفحة من ووردبريس وخزنها.

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

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

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

ابدأ بالتأكد انك تعدل الصفحة الصحيحة

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

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

حدد هل القديم هو HTML ام ملف CSS

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

في ادوات المطور افتح تبويب الشبكة، ثم افحص طلب الصفحة وطلب ملف التنسيق. رؤوس مثل Age وCF-Cache-Status وX-Cache بتعطي دليلا، لكن الاسم يختلف حسب الاستضافة. في Cloudflare تعني HIT ان المورد جاء من الكاش، بينما MISS يعني انه لم يكن موجودا وقت الطلب. ويشرح توثيق استجابات كاش Cloudflare باقي الحالات مثل BYPASS وEXPIRED.

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

فرغ الطبقة الصحيحة بالترتيب

1. اذا المشكلة في جهاز واحد فقط، اعمل تحديثا قويا للصفحة وافحصها من نافذة خاصة. لا تمسح كل سجل المتصفح من اول محاولة.
2. اذا النسخة القديمة تظهر لكل الزوار، فرغ كاش الصفحة من الاضافة المستخدمة فعلا. لا تثبت اضافة كاش جديدة حتى تمسح كاشا غير موجود.
3. اذا بقيت النسخة، افتح لوحة الاستضافة وابحث عن Page Cache او Varnish او خيار Purge. بعض الخطط تطبق الكاش حتى بدون اضافة داخل ووردبريس.
4. اذا الموقع خلف CDN، فرغ رابط الصفحة المتأثر ثم ملف CSS او الصورة المتأثرة عند الحاجة.
5. اختبر كزائر غير مسجل بعد كل خطوة، وسجل اي طبقة غيرت النتيجة.

تفريغ كل شيء ممكن يضغط على الخادم ويخفي مكان السبب. Cloudflare نفسه يوصي عادة بالتفريغ حسب الرابط بدل حذف كامل الكاش، كما يوضح دليل تفريغ الكاش الرسمي.

لو المشكلة في التنسيق والصور فقط

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

اذا تستخدم منشئ صفحات، افحص ايضا خيار اعادة توليد ملفات CSS بعد النقل او تغيير النطاق. لا تضغط كل ازرار التنظيف معا؛ ابدأ بالملف او الصفحة التي تغيرت حتى تعرف ما الذي اصلح المشكلة.

ليش مسح Object Cache قد لا يكفي؟

Object Cache مثل Redis يخزن نتائج بيانات يستخدمها PHP، بينما Page Cache قد يقدم ملف HTML كامل قبل تشغيل ووردبريس. لذلك امر تفريغ Object Cache مش ضمانا لمسح صفحة مخزنة في Varnish او CDN. الاسماء متشابهة لكن مكان التخزين ومسار الطلب مختلفان.

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

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

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

الخلاصة من المختبر

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

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