المقال المجدول لم ينشر؟ تجربة Missed Schedule وWP-Cron

جدولت مقالا في ووردبريس، مر الموعد وظهر جنب المقال فشل الجدولة او Missed schedule؟ النشر المجدول يعتمد على حدث داخل WP-Cron. اذا الحدث موجود لكن ما حدا شغل قائمة Cron في الوقت المناسب، يظل المقال بحالة future وما يظهر للزوار.

في تجربتنا انشانا مقالا مؤقتا وحدث publish_future_post حقيقيا، وجعلنا موعده قبل وقت القياس بخمس دقائق. منعنا تشغيل Cron مع زيارات الموقع مؤقتا حتى نثبت الحالة، ثم شغلنا ملف wp-cron.php يدويا وراقبنا حالة المقال والحدث والرابط العام.

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

ملخص النتيجة

• موعد النشر صار في الماضي بخمس دقائق.
• حدث publish_future_post بقي موجودا ومتأخرا.
• حالة المقال بقيت future والرابط العام رجع 404.
• بعد تشغيل wp-cron.php انتقلت الحالة إلى publish.
• اختفى الحدث المنفذ من قائمة Cron وظهر الرابط للزوار.

قبل تشغيل Cron: الرابط غير موجود للزائر

منعنا الاستدعاء التلقائي لـ WP-Cron بإضافة مختبر مؤقتة، ثم فتحنا رابط المقال من متصفح غير مسجل. الصفحة رجعت 404، وهذا متوقع لمقال حالته future حتى لو كان موعده في الماضي.

هاي النقطة تفرق بين مشكلة كاش ومشكلة حالة. لو كانت الحالة publish والصفحة القديمة في الكاش، نفحص التفريغ. هون الحالة نفسها ما انتقلت، لذلك بدأنا من Cron.

فحص الحدث وحالة المقال

استدعينا wp_next_scheduled() لنفس hook ومعرف المقال. وجدنا الموعد ما زال في قائمة Cron رغم انه متأخر 315 ثانية. في الوقت نفسه رجع get_post_status() القيمة future.

توثيق wp_schedule_single_event يوضح ان الحدث ينفذ بعد وصول موعد UTC عندما يتم تشغيل WP-Cron. الموعد وحده ما يشغل كودا في الخلفية مثل خدمة مستقلة.

شو عمل تشغيل wp-cron.php؟

شغلنا ملف Cron مرة واحدة من PHP على نفس نسخة ووردبريس. ما نشرنا المقال يدويا من المحرر، وما غيرنا post_status بايدينا. WP-Cron قرأ الحدث المستحق وشغل hook النشر.

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

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

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

بعد التنفيذ: نفس الرابط صار عاما

فتحنا الرابط مرة ثانية بعد تشغيل Cron. هذه المرة ظهر عنوان مقال المختبر ومحتواه، وصار post_status=publish.

كيف يعمل WP-Cron فعليا؟

WP-Cron مش خدمة نظام تظل مستيقظة كل دقيقة. في الوضع الافتراضي يحاول ووردبريس تشغيل الاحداث المستحقة عند وصول طلب للموقع. لذلك موقع قليل الزيارات ممكن يتاخر، وموقع يمنع loopback او يمنع wp-cron.php ممكن تتراكم عنده الاحداث.

التاخير البسيط مش دايما عطل. لكن اذا المقالات تبقى Missed Schedule لدقائق طويلة، افحص هل Cron ينفذ اصلا وهل اخر تشغيل يكتمل.

افحص المنطقة الزمنية قبل كل شيء

من الإعدادات العامة سجل Timezone ووقت ووردبريس الحالي. لا تعتمد على ساعة جهازك فقط. قاعدة Cron تخزن timestamp يعتمد على UTC، بينما شاشة التحرير تعرض وقت الموقع. فرق ساعتين او ثلاث ممكن يخليك تفحص الحدث قبل موعده الحقيقي او بعده.

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

قائمة تشخيص مرتبة

1. تأكد ان حالة المقال future وان موعده صار في الماضي حسب وقت الموقع.
2. ابحث عن حدث publish_future_post ومعرف المقال.
3. افحص صحة الموقع عن فشل الاحداث المجدولة او loopback.
4. جرب تشغيل wp-cron.php مرة واحدة من الاستضافة.
5. راقب هل الحالة انتقلت وهل الحدث اختفى.
6. راجع سجل PHP في وقت التشغيل عن fatal او timeout.
7. افحص هل حماية او Basic Auth تمنع loopback.
8. اذا تستخدم Cron نظام، تأكد ان DISABLE_WP_CRON يقابله امر حقيقي شغال.

لا تضع DISABLE_WP_CRON وحده

تعطيل WP-Cron من زيارات الموقع من غير إعداد Cron في لوحة الاستضافة يوقف النشر المجدول والتنظيف ورسائل بعض الإضافات. اذا بدك Cron نظام اكثر ثباتا، رتب الخطوتين معا: شغل wp-cron.php كل دقيقة او خمس دقائق حسب الحاجة، وبعد ما تختبره عطل التشغيل مع الزيارات.

لا تنس ان مسار PHP وملف ووردبريس يختلفان بين الاستضافات. سجل مخرجات الامر وحالة الخروج بدل افتراض انه يعمل لمجرد وجوده في لوحة Cron.

طلب HTTP ام تشغيل PHP مباشر؟

بعض الاستضافات تشغل رابط wp-cron.php?doing_wp_cron عبر HTTP، وبعضها يشغل الملف مباشرة عبر PHP CLI. التشغيل المباشر يتجنب DNS وSSL وWAF، لكنه لازم يستخدم نسخة PHP والإعدادات الصحيحة للموقع.

اذا تستخدم طلب HTTP، افحص الرمز والزمن والتحويلات. 403 يعني حماية، و404 يعني مسار خطأ، وtimeout ممكن يعني حدثا ثقيلا داخل القائمة.

ماذا لو اشتغل Cron لكن المقال ما نشر؟

افحص سجل PHP وhook النشر. إضافة ممكن توقف transition_post_status او ترمي خطا اثناء النشر. جرب مقالا بسيطا بلا حقول إضافية. اذا البسيط ينشر والمقال المعقد يفشل، قارن الإضافات والعمليات التي تعمل عند النشر.

كمان افحص وجود اكثر من حدث لنفس المقال. args جزء من هوية الحدث؛ حدث بمعرف مكتوب كنص ممكن يختلف عن معرف صحيح كرقم في بعض الحالات.

لا تعالج الجدولة بإعادة نشر كل شيء

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

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

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

الخلاصة

في تجربتنا كان المقال والحدث موجودين، لكن التنفيذ التلقائي ممنوع مؤقتا. بقي المقال future والرابط 404 بعد فوات الموعد. تشغيل wp-cron.php نفذ publish_future_post، نقل الحالة إلى publish، حذف الحدث المنفذ، واظهر الرابط.

عند Missed Schedule افحص ثلاث طبقات: صحة الموعد، وجود الحدث، وتشغيل Cron. لا تنشر المقال يدويا وتنهي التشخيص؛ اختبر حدثا واحدا واعرف اين توقف، ثم ثبت Cron نظام اذا كان تشغيل الزيارات غير موثوق.