Cron ومعالجة الخلفية

تنفذ PrimoCRM جميع مهامها الثقيلة في الخلفية: حيث تتم معالجة إرسال الحملات، وتتابع التسلسلات، وخطوات الأتمتة بواسطة عمال مجدولين، وليس أبداً في طلب الصفحة. يعمل هؤلاء العمال على Cron الخاص بوردبريس، لذا فإن وجود Cron موثوق هو ما يحافظ على استمرار إرسال بريدك الإلكتروني في وقته. تشرح هذه الصفحة كيف يعمل وكيفية جعله صلباً ومستقراً.

كيف تستخدم PrimoCRM ميزة Cron

تسجل PrimoCRM جدولين مخصصين ومجموعة صغيرة من عمال الخلفية:

العامل	يعمل	المهمة
إرسال البريد الإلكتروني للحملة	عند الطلب (فقط عندما تحتوي الحملة على رسائل بريد إلكتروني معلقة)	يسلم الحملة في دفعات مقيدة
معالجة التسلسلات	كل دقيقة	يرسل رسائل التسلسل المستحقة
معالجة الأتمتة	كل دقيقة	يحرك جهات الاتصال خلال خطوات الأتمتة
فحص صحة قائمة الانتظار	كل 5 دقائق	يستعيد رسائل البريد الإلكتروني العالقة ويعيد تشغيل الحملات المتوقفة

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

لماذا يهم وجود Cron موثوق

تأتي ووردبريس مع Cron زائف يعمل فقط عندما يزور شخص ما الموقع. هذا جيد على موقع مزدحم. أما على موقع منخفض الزيارات, فقد تمر ساعات بدون أي زيارات، لذا لا تعمل عمليات الإرسال المجدولة حتى يصل الزائر التالي. العلامة على ذلك هي الحملة التي تبقى في حالة “جاري الإرسال” وتتدفق ببطء شديد أو لا تتدفق أبداً.

الحل هو استبدال Cron الزائف الذي يفعله الزوار بـ Cron حقيقي يعمل وفق جدول زمني ثابت، ويفضل أن يكون كل دقيقة.

تحقق مما إذا كان Cron يعمل

افتح PrimoCRM ثم الإعدادات وابحث عن حالة النظام أو Cron، والتي توضح ما إذا كان العمال مجدولين ومتى عملوا آخر مرة.
أو قم بتثبيت إضافات مساعدة مثل WP Crontrol وتأكد من وجود أحداث primocrm_process_sequences و primocrm_process_automations و primocrm_queue_health_check وتفعيلها.

إذا كانت الحملة عالقة وكان موقعك يتلقى زيارات قليلة، فإن Cron هو السبب في الغالب الأعم.

إعداد Cron حقيقي (موصى به)

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

1. تعطيل Cron الزائف

أضف هذا إلى ملف wp-config.php، فوق السطر “That’s all, stop editing”:

define( 'DISABLE_WP_CRON', true );

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

2. إضافة Cron حقيقي كل دقيقة

اختر ما يناسب استضافتك.

أداة WP-CLI (الأفضل، إذا كان لديك صلاحية الوصول إلى سطر الأوامر):

* * * * * cd /path/to/wordpress && wp cron event run --due-now >/dev/null 2>&1

ملف PHP التنفيذي (ممتاز أيضاً مع صلاحية الوصول إلى سطر الأوامر):

* * * * * php /path/to/wordpress/wp-cron.php >/dev/null 2>&1

لوحة تحكم cPanel: افتح مهام Cron (Cron Jobs)، واضبط الجدول الزمني ليصبح كل دقيقة (* * * * *)، واستخدم أحد الأوامر أعلاه مع المسار الكامل لموقعك.

لا توجد صلاحية وصول لسطر الأوامر (استضافة مشتركة)؟ استخدم خدمة Cron عن بُعد مجانية مثل cron-job.org لاستدعاء رابط Cron الخاص بك عبر بروتوكول HTTP كل دقيقة:

https://yoursite.com/wp-cron.php?doing_wp_cron

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

استكشاف الأخطاء وإصلاحها

الحملة عالقة في حالة “جاري الإرسال”. غالباً ما يكون السبب هو Cron. تأكد من أن Cron الحقيقي يعمل كل دقيقة وأن DISABLE_WP_CRON مفعل. سيقوم فحص الصحة لمدة 5 دقائق بتسئناف الإرسال بمجرد تشغيل Cron.
تعمل الأتمتة أو التسلسلات متأخرة. الفاصل الزمني لـ Cron لديك طويل جداً، أو أن Cron الزائف ينتظر الزوار. انتقل إلى Cron حقيقي يعمل كل دقيقة واحدة.
لا شيء يرسل على الإطلاق. بشكل منفصل عن Cron، تأكد من أن طريقة الإرسال الخاصة بك مُكوّنة وأن البريد الإلكتروني التجريبي يصل. يتحكم Cron في وقت تشغيل العمل؛ بينما يتحكم برنامج البريد في ما إذا كان سيتم تسليمه.
حدود وحدة المعالجة المركزية للاستضافة المشتركة. العمال محددون بميزانية زمنية ويتراجعون تحت الضغط، لذا فهي آمنة على الاستضافات المشتركة. إذا استمر مزود الاستضافة في الشكوى، فإن استخدام فاصل زمني أطول قليلاً (من 2 إلى 5 دقائق) يقلل التكرار على حساب سرعة الاستجابة.

راجع أيضاً المتطلبات الخاصة بمتطلبات PHP والخادم، والإرسال وقابلية التسليم لجانب مرسل البريد.