DISABLE_WP_CRON = true کرنے سے wp-cron.php اینڈ پوائنٹ (endpoint) بند نہیں ہوتا؛ یہ صرف ورڈپریس کو اپنا لوپ بیک (loopback) ریکویسٹ بھیجنے سے روکتا ہے۔ یہ فائل ویب سے قابل رسائی رہتی ہے، اس لیے کوئی بھی اب بھی اسے ہٹ کر مکمل ورڈپریس بوٹ اسٹریپ (bootstrap) شروع کرنے پر مجبور کر سکتا ہے۔

وہ چھپا ہوا داخلی راستہ (entry point) CPU، میموری اور PHP ورکرز کو ضائع کر سکتا ہے، خاص طور پر مصروف سائٹس پر۔ اگر آپ کو لگا تھا کہ آپ نے دروازہ بند کر دیا ہے، تو ایسا نہیں ہوا—ابھی تک نہیں۔

یہ سیٹنگ اکثر غلط کیوں سمجھی جاتی ہے

جب ورڈپریس کوئی شیڈول شدہ ٹاسک (scheduled task) چلاتا ہے تو وہ پہلے اپنی wp-cron.php فائل کو ایک فوری HTTP ریکویسٹ بھیجنے کی کوشش کرتا ہے۔ DISABLE_WP_CRON کو true پر سیٹ کرنے سے کور (core) کو وہ اندرونی ریکویسٹ چھوڑنے کا حکم ملتا ہے۔ کور ویب سرور کی کنفیگریشن کو تبدیل نہیں کرتا، اور نہ ہی یہ wp-cron.php میں کوئی آتھنٹیکیشن لیئر (authentication layer) شامل کرتا ہے۔ یہ اسکرپٹ ایک عوامی URL رہتا ہے جو 200 اسٹیٹس واپس کرتا ہے، چاہے PHP پروسیس وقت سے پہلے ہی ختم ہو جائے۔

ایک حملہ آور جو اس URL کو دریافت کر لیتا ہے، وہ اسے بار بار پنگ (ping) کر سکتا ہے، جس سے ورڈپریس ہر بار تمام پلگ انز، تھیمز اور ڈیٹا بیس کو لوڈ کرنے پر مجبور ہو جاتا ہے۔ شیئرڈ ہوسٹنگ یا محدود PHP ورکرز والی سائٹ پر، یہ ایک سنگل اینڈ پوائنٹ 'ڈینیئل آف سروس' (denial-of-service) کا ذریعہ بن سکتا ہے۔

اصل میں کیا کرنے کی ضرورت ہے

شیڈول شدہ کاموں کو سسٹم لیول شیڈولر (cron, systemd-timer, وغیرہ) پر منتقل کرنے اور عوامی دروازے کو بند کرنے کے لیے، ان پانچ مراحل پر عمل کریں۔

1. اندرونی لوپ بیک کو غیر فعال کریں

یہ لائن شامل کریں 

define( 'DISABLE_WP_CRON', true );

wp-config.php میں۔ یہ ورڈپریس کو اپنی HTTP ریکویسٹ بھیجنے سے روکتا ہے، لیکن یہ بیرونی کالز (external calls) کو نہیں روکتا۔

2. ویب سرور پر wp-cron.php کو بلاک کریں

مثال کے طور پر، Nginx کے ساتھ، ایک لوکیشن بلاک (location block) شامل کریں جو 403 Forbidden واپس کرے:

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

اب سرور PHP شروع ہونے سے پہلے ہی ریکویسٹ کو مسترد کر دے گا، جس سے بوٹ اسٹریپ (bootstrap) کا خرچہ ختم ہو جائے گا۔

3. حفاظتی جال کے طور پر ایک mu-plugin شامل کریں

ایک must-use پلگ ان بنائیں (جو wp-content/mu-plugins میں رکھا گیا ہو) جو wp-cron.php تک پہنچنے والی کسی بھی ریکویسٹ کو لاگ کرے اور 403 کے ساتھ ختم ہو جائے۔ یہ ان ریکویسٹس کو پکڑ لیتا ہے جو کسی نہ کسی طرح سرور کے اصول کو بائی پاس کر جاتی ہیں—شاید کسی مختلف ہوسٹ نیم یا CDN ایج رول کے ذریعے ہو۔

4. Action Scheduler کی async کالز کو روکیں

بہت سے پلگ انز Action Scheduler لائبریری استعمال کرتے ہیں، جو اپنی لوپ بیک ریکویسٹس پیدا کر سکتی ہے۔ action_scheduler_queue_runner میں ہک (hook) کریں اور غیر-CLI ریکویسٹس کے لیے جلدی واپس (return early) ہو جائیں، تاکہ لائبریری اپنے دروازے کھولنے کی کوشش نہ کر سکے۔

5. WP-Cron ہک سے کیو رنر (queue runner) کو ان ہک کریں

ڈیفالٹ Action Scheduler کیو رنر کو ہٹا دیں جو wp کرون ہک کے ساتھ منسلک ہے۔ اس بات کو یقینی بنائیں کہ کیو (queue) صرف اس وقت چلے جب آپ اسے واضح طور پر کمانڈ لائن سے ٹرگر کریں۔

کاموں کو صحیح طریقے سے چلانا

عوامی اینڈ پوائنٹ بند ہونے کے بعد، WP-CLI کے ذریعے ہر منٹ میں (یا جتنی بار آپ کو ضرورت ہو) ورڈپریس کو چلانے کے لیے سسٹم شیڈولر کا استعمال کریں:

wp cron event run --due-now

وہ واحد کمانڈ کنٹرول شدہ ماحول میں کور کرون ایونٹس اور Action Scheduler کیو کو پروسیس کرتی ہے، اور اسی PHP پروسیس کا استعمال کرتی ہے جو آپ کسی بھی دوسرے CLI ٹاسک کے لیے استعمال کریں گے۔

فوائد جنہیں آپ ناپ سکتے ہیں

  • سیکیورٹی – کوئی بھی غیر تصدیق شدہ صارف بھاری بیک گراؤنڈ کام شروع نہیں کر سکتا۔
  • پرفارمنس – PHP ورکرز حقیقی وزٹرز کے لیے دستیاب رہتے ہیں؛ بے مقصد کرون ہٹس سے ہونے والے میموری اسپائکس (memory spikes) ختم ہو جاتے ہیں۔
  • مستقل مزاجی (Reliability) – شیڈولنگ فعال (proactive) ہو جاتی ہے؛ آپ کو بالکل معلوم ہوتا ہے کہ کوئی کام کب چل رہا ہے کیونکہ یہ سسٹم کے کرون کے ذریعے چلایا جاتا ہے، نہ کہ کسی وزیٹر کے پیج لوڈ کرنے سے۔

تبدیلی کے بعد کن چیزوں پر نظر رکھنی ہے

wp-cron.php کے HTTP اسٹیٹس کوڈ پر بھروسہ نہ کریں؛ یہ PHP کے ذریعے بلاک ہونے کے باوجود بھی 200 واپس کر سکتا ہے۔ اس کے بجائے:

  • Action Scheduler کیو کے سائز کی نگرانی کریں۔ بڑھتی ہوئی کیو اکثر مس ہونے والے رنز (missed runs) کا اشارہ دیتی ہے۔
  • wp-cron.php لوکیشن بلاک سے "403" انٹریز کے لیے سرور لاگز چیک کریں۔
  • لوڈ کم ہونے کی تصدیق کے لیے پیک ٹریفک کے دوران PHP-FPM یا FastCGI پروسیس کی تعداد کا مشاہدہ کریں۔

احتیاطی نوٹ

کچھ ایڈمنسٹریٹرز DISABLE_WP_CRON کو false رکھتے ہیں کیونکہ وہ کم ٹریفک والی سائٹس پر کرون کے قدرتی طور پر چلنے پر بھروسہ کرتے ہیں۔ اوپر والا طریقہ اس بھروسے کو مکمل طور پر ختم کر دیتا ہے، لیکن یہ دیکھ بھال (maintenance) کا ایک مرحلہ بھی شامل کرتا ہے: آپ کو اس بات کو یقینی بنانا ہوگا کہ سسٹم شیڈولر قابل اعتماد طریقے سے چلے۔ اگر سرور کا کرون ڈیمن (cron daemon) فیل ہو جائے تو شیڈول شدہ کام رک جاتے ہیں۔ اس مشکل سے بچنے کے لیے سیٹ اپ کے ساتھ سسٹم کرون سروس کی نگرانی کو بھی جوڑیں۔

خلاصہ: DISABLE_WP_CRON کو true پر سیٹ کرنے سے صرف ورڈپریس کو خود کو پنگ کرنے سے روکا جاتا ہے؛ یہ عوامی wp-cron.php اینڈ پوائنٹ کو بند نہیں کرتا۔ فائل کو ویب سرور پر بلاک کریں، ایک mu-plugin فال بیک (fallback) شامل کریں، اور تمام شیڈول شدہ کاموں کو WP-CLI کے ذریعے سسٹم شیڈولر کے ذریعے بھیجیں۔ ایسا کرنے سے سائٹ محفوظ ہوتی ہے، غیر ضروری PHP کام کم ہوتا ہے، اور آپ کو اس بات پر درست کنٹرول ملتا ہے کہ بیک گراؤنڈ ٹاسک کب چلتے ہیں۔