بديل WP-Cron

يمكن لـ Queuety استبدال نظام WordPress cron المدمج. عند تفعيله، تُعترض استدعاءات wp_schedule_event() وتُمرر إلى مجدول Queuety بدلًا من آلية WP-Cron الافتراضية. يُفترض أن يعالج عامل Queuety الأحداث، ما يتيح تنفيذها بمعزل عن زيارات الموقع.

قيد حالي: ينشئ الجسر جداول Queuety، لكن العامل لا يملك معالجًا لمهام __queuety_cron_{hook} الناتجة عنها، لذلك لا تُشغّل استدعاءات WordPress الأصلية مطلقًا. تفشل كل مهمة، ثم يعاد تنفيذها بعد مهلة تراجع، وفي النهاية تُدفن (#9). لا تفعّل الجسر على موقع يجب تشغيل أحداث cron فيه إلى أن يُصلح ذلك.

تفعيل البديل

استدعِ Queuety::replace_wp_cron() مبكرًا أثناء تهيئة الإضافة أو القالب:

use Queuety\Queuety;

Queuety::replace_wp_cron();

يُستدعى هذا عادةً في الملف الرئيسي للإضافة أو ضمن خطاف plugins_loaded. يجب استدعاؤه أثناء تحميل WordPress (أي يجب أن تكون الإضافة مفعّلة).

ما الذي يعترضه

يرتبط جسر cron بثلاثة مرشحات من WordPress:

لا يُعترض إلا على الأحداث المتكررة (التي لها خاصية schedule مثل hourly وtwicedaily وdaily). أما الأحداث أحادية التنفيذ المجدولة باستخدام wp_schedule_single_event() فلا يُعترض عليها.

كيفية ربط الأحداث

عندما تستدعي إضافة wp_schedule_event()، يحل Queuety اسم الجدول عبر wp_get_schedules()، وينشئ جدول Queuety باسم المعالج __queuety_cron_{hook}، ويخزّن اسم خطاف WordPress الأصلي ومعاملاته في حمولة الجدول.

السلوك المقصود هو أن يستدعي عامل Queuety، أثناء معالجة المهمة المجدولة، do_action() باسم الخطاف الأصلي ومعاملاته، لتعمل استدعاءات WordPress الحالية وتتولى Queuety ضبط التوقيت. تنفذ CronBridge::process_cron_event() هذا الاستدعاء، لكن لا شيء يستدعيها حتى الآن (انظر القيد أعلاه). لا تُقيّم الجداول أيضًا إلا بواسطة عملية wp queuety work طويلة التشغيل، بمعدل مرة كل دقيقة تقريبًا (راجع الجدولة).

تحديد الفاصل الزمني

يحل الجسر أسماء الجداول عبر wp_get_schedules() أولًا، ثم يستخدم القيم الافتراضية المدمجة:

تُدعم الفواصل الزمنية المخصصة المسجلة عبر المرشح cron_schedules ما دام wp_get_schedules() يعيدها.

استعادة WP-Cron

للعودة إلى نظام WordPress cron الافتراضي:

Queuety::restore_wp_cron();

يزيل هذا خطافات المرشحات ويتيح لـ WordPress معالجة أحداث cron مجددًا عبر آليته المدمجة. يُرجى ملاحظة أن DISABLE_WP_CRON يُعرّف على أنه true عند تثبيت الجسر، ولا يمكن إلغاء تعريفه أثناء التشغيل، لذا قد تحتاج إلى إزالة ذلك الثابت من wp-config.php أو إعادة تشغيل العملية.

متى تستخدمه

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

القيود

هناك عدة قيود مهمة. يلزم وجود عامل Queuety نشط، وإلا فلن تُشغّل الأحداث المجدولة مطلقًا. لا يُعترض إلا على الجداول المتكررة؛ وتظل الأحداث أحادية التنفيذ المنشأة باستخدام wp_schedule_single_event() خارج الجسر. كما يعرّف replace_wp_cron() الثابت DISABLE_WP_CRON لبقية عملية PHP الحالية، لذا يزيل restore_wp_cron() الخطافات لكنه لا يستطيع إلغاء تعريف الثابت. وأخيرًا، لا يعمل الجسر إلا عند تحميل WordPress، لأنه يعتمد على مرشحات WordPress وdo_action().

مثال: إعداد كامل

use Queuety\Queuety;

// In your plugin's main file.
add_action( 'plugins_loaded', function () {
    Queuety::replace_wp_cron();
} );

لا حاجة إلى استدعاء Queuety::init() هنا: تنشئ إضافة Queuety النشطة اتصالها باستخدام بيانات اعتماد قاعدة بيانات WordPress، وتُهيئ نفسها عند plugins_loaded. أما replace_wp_cron() فلا يثبت سوى المرشحات، لذا لا يعتمد على حدوث ذلك أولًا.

بعد ذلك، تُخزّن الأحداث المتكررة التي تسجلها الإضافات باستخدام wp_schedule_event() على هيئة جداول Queuety. وإلى أن يُصلح #9، لن تعمل استدعاءاتها.