لا يؤدي ضبط DISABLE_WP_CRON = true إلى إغلاق نقطة نهاية wp-cron.php؛ بل يكتفي بمنع WordPress من إرسال طلب loopback الخاص به. يظل الملف متاحاً عبر الويب، لذا يمكن لأي شخص الوصول إليه وإجبار WordPress على بدء عملية الـ bootstrap بالكامل.

يمكن لنقطة الدخول الخفية هذه أن تستهلك المعالج (CPU) والذاكرة وعمال PHP (PHP workers)، خاصة في المواقع المزدحمة. إذا كنت تعتقد أنك أغلقت الباب، فأنت لم تفعل ذلك بعد.

لماذا يُساء فهم هذا الإعداد غالباً

عندما يقوم WordPress بتشغيل مهمة مجدولة، فإنه يحاول أولاً إرسال طلب HTTP سريع إلى ملف wp-cron.php الخاص به. ضبط DISABLE_WP_CRON على true يخبر النظام الأساسي (core) بتجاوز هذا الطلب الداخلي. لكن النظام الأساسي لا يغير إعدادات خادم الويب، ولا يضيف أي طبقة مصادقة إلى wp-cron.php. يظل السكربت عبارة عن رابط (URL) عام يعيد حالة 200 حتى لو توقفت عملية PHP مبكراً.

يمكن للمهاجم الذي يكتشف الرابط أن يقوم بعمل ping له بشكل متكرر، مما يجبر WordPress على تحميل جميع الإضافات (plugins) والقوالب (themes) وقاعدة البيانات في كل مرة. في الاستضافات المشتركة أو المواقع ذات عدد محدود من عمال PHP، يمكن أن تصبح نقطة النهاية هذه وسيلة لهجمات حجب الخدمة (denial-of-service).

ما يجب فعله حقاً

لنقل المهام المجدولة إلى مجدول على مستوى النظام (مثل cron أو systemd-timer، إلخ) وإغلاق الباب العام، اتبع الخطوات الخمس التالية.

1. تعطيل الـ loopback الداخلي

أضف السطر التالي

define( 'DISABLE_WP_CRON', true );

إلى ملف wp-config.php. هذا يمنع WordPress من محاولة إرسال طلب HTTP الخاص به، لكنه لا يمنع الطلبات الخارجية.

2. حظر wp-cron.php على مستوى خادم الويب

في Nginx، على سبيل المثال، قم بإدراج كتلة location تعيد حالة 403 Forbidden:

location = /wp-cron.php {
    return 403;
}

سيرفض الخادم الآن الطلب قبل أن تبدأ عملية PHP، مما يلغي تكلفة الـ bootstrap.

3. إضافة mu-plugin كشبكة أمان

قم بإنشاء إضافة must-use (توضع في wp-content/mu-plugins) تقوم بتسجيل أي طلب يصل إلى wp-cron.php وتخرج بحالة 403. هذا سيصطاد الطلبات التي قد تتجاوز قاعدة الخادم بطريقة ما—ربما من خلال اسم مضيف (hostname) مختلف أو قاعدة edge في CDN.

4. كبح استدعاءات Action Scheduler غير المتزامنة

تستخدم العديد من الإضافات مكتبة Action Scheduler، والتي يمكن أن تنشئ طلبات loopback خاصة بها. قم بعمل hook في action_scheduler_queue_runner واجعل العملية تنتهي مبكراً للطلبات التي ليست عبر CLI، مما يمنع المكتبة من محاولة فتح أبوابها الخاصة.

5. إلغاء ربط مشغل الطابور من hook الخاص بـ WP-Cron

قم بإزالة مشغل طابور Action Scheduler الافتراضي المرتبط بـ wp cron hook. يضمن ذلك عدم تشغيل الطابور إلا عندما تقوم بتشغيله صراحةً من سطر الأوامر.

تشغيل المهام بالطريقة الصحيحة

بعد إغلاق نقطة النهاية العامة، استخدم مجدول النظام لاستدعاء WordPress مرة واحدة كل دقيقة (أو أي وتيرة تحتاجها) عبر WP-CLI:

wp cron event run --due-now

يقوم هذا الأمر الوحيد بمعالجة أحداث cron الأساسية و طابور Action Scheduler في بيئة محكومة، باستخدام نفس عملية PHP التي قد تستخدمها لأي مهمة CLI أخرى.

فوائد يمكنك قياسها

  • الأمان – لا يمكن لأي مستخدم غير مصرح له بدء مهام خلفية ثقيلة.
  • الأداء – تظل عمال PHP متاحة للزوار الحقيقيين؛ وتختفي طفرات الذاكرة الناتجة عن طلبات cron العشوائية.
  • الموثوقية – تصبح الجدولة استباقية؛ حيث ستعرف بالضبط متى يتم تشغيل المهمة لأنها مدفوعة بـ cron النظام، وليس بتحميل صفحة من قبل زائر.

ما يجب مراقبته بعد التغيير

لا تعتمد على رمز حالة HTTP الخاص بـ wp-cron.php؛ فقد لا يزال يعيد 200 حتى عند حظره بواسطة PHP. بدلاً من ذلك:

  • راقب حجم طابور Action Scheduler. غالباً ما يشير الطابور المتزايد إلى فشل في عمليات التشغيل.
  • تحقق من سجلات الخادم بحثاً عن إدخالات "403" من كتلة location الخاصة بـ wp-cron.php.
  • راقب عدد عمليات PHP-FPM أو FastCGI أثناء ذروة حركة المرور للتأكد من انخفاض الحمل.

ملاحظة تحذيرية

يحتفظ بعض المسؤولين بـ DISABLE_WP_CRON على القيمة false لأنهم يعتمدون على المواقع ذات حركة المرور المنخفضة لتشغيل cron بشكل طبيعي. النهج المذكور أعلاه يزيل هذا الاعتماد تماماً، ولكنه يضيف خطوة صيانة: يجب عليك التأكد من أن مجدول النظام يعمل بشكل موثوق. إذا فشل cron daemon الخاص بالخادم، فستتوقف المهام المجدولة. اربط هذا الإعداد بمراقبة خدمة cron الخاصة بالنظام لتجنب هذا المأزق.

الخلاصة: ضبط DISABLE_WP_CRON على true يمنع WordPress فقط من إرسال ping لنفسه؛ ولكنه لا يغلق نقطة نهاية wp-cron.php العامة. قم بحظر الملف على مستوى خادم الويب، وأضف mu-plugin كبديل احتياطي، وقم بتوجيه جميع المهام المجدولة عبر مجدول النظام باستخدام WP-CLI. القيام بذلك يؤمن الموقع، ويقلل من أعمال PHP غير الضرورية، ويمنحك تحكماً دقيقاً في وقت تنفيذ المهام الخلفية.