DISABLE_WP_CRON = true मुळे wp-cron.php endpoint पूर्णपणे बंद (seal) होत नाही; ते फक्त WordPress ला स्वतःची loopback request थांबवण्यास सांगते. ही फाईल वेबवरून अजूनही उपलब्ध असते, त्यामुळे कोणीही ती एक्सेस करून पूर्ण WordPress bootstrap फोर्स करू शकते.

तो लपलेला entry point CPU, मेमरी आणि PHP workers वाया घालवू शकतो, विशेषतः व्यस्त साइट्सवर. जर तुम्हाला वाटले असेल की तुम्ही दरवाजा बंद केला आहे, तर तुम्ही अजून तो केलेला नाही.

हे सेटिंग अनेकदा का चुकीचे समजले जाते

जेव्हा WordPress एखादे scheduled task चालवते, तेव्हा ते प्रथम त्याच्या स्वतःच्या wp-cron.php फाईलला एक जलद HTTP request पाठवण्याचा प्रयत्न करते. DISABLE_WP_CRON true सेट केल्यामुळे core ला ती अंतर्गत request वगळण्यास सांगितले जाते. core मुळे web-server च्या कॉन्फिगरेशनमध्ये कोणताही बदल होत नाही, किंवा wp-cron.php मध्ये कोणतेही authentication layer जोडले जात नाही. जरी PHP process लवकर थांबली तरीही, हा script एक public URL म्हणून राहतो जो 200 status रिटर्न करतो.

ज्या अटॅकरला हा URL सापडतो, तो वारंवार त्याला ping करू शकतो, ज्यामुळे प्रत्येक वेळी WordPress ला सर्व plugins, themes आणि database लोड करावे लागतात. Shared host वर किंवा मर्यादित PHP workers असलेल्या साइटवर, हा एक single endpoint Denial-of-Service (DoS) vector बनू शकतो.

खरं तर काय करण्याची गरज आहे

Scheduled work ला system-level scheduler (cron, systemd-timer, इ.) कडे वळवण्यासाठी आणि public दरवाजा बंद करण्यासाठी, या पाच स्टेप्स फॉलो करा.

1. अंतर्गत loopback अक्षम करा

ही ओळ जोडा 

define( 'DISABLE_WP_CRON', true );

wp-config.php मध्ये. यामुळे WordPress स्वतःची HTTP request करण्याचा प्रयत्न थांबवते, पण यामुळे बाह्य (external) calls थांबत नाहीत.

2. Web-server वर wp-cron.php ब्लॉक करा

उदाहरणार्थ, Nginx मध्ये, एक location block समाविष्ट करा जो 403 Forbidden रिटर्न करेल:

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

आता PHP सुरू होण्यापूर्वीच सर्व्हर ही request नाकारतो, ज्यामुळे bootstrap चा खर्च वाचतो.

3. Safety net म्हणून mu-plugin जोडा

एक must-use plugin तयार करा (wp-content/mu-plugins मध्ये ठेवा) जो wp-cron.php पर्यंत पोहोचणाऱ्या कोणत्याही request ला log करेल आणि 403 सह exit करेल. हे अशा requests पकडते ज्या कशा प्रकारे सर्व्हरच्या नियमांना बायपास करतात—कदाचित वेगळ्या hostname द्वारे किंवा CDN edge rule द्वारे.

4. Action Scheduler async calls रोखा

अनेक plugins Action Scheduler library वापरतात, जी स्वतःच्या loopback requests तयार करू शकते. action_scheduler_queue_runner मध्ये hook करा आणि non-CLI requests साठी लवकर return करा, ज्यामुळे library स्वतःचे दरवाजे उघडण्याचा प्रयत्न करणार नाही.

5. WP-Cron hook मधून queue runner अनहुक (Unhook) करा

wp cron hook ला जोडलेला default Action Scheduler queue runner काढून टाका. यामुळे queue फक्त तेव्हाच रन होईल जेव्हा तुम्ही कमांड लाईनवरून ती स्पष्टपणे ट्रिगर कराल.

जॉब्स योग्य पद्धतीने चालवणे

Public endpoint सुरक्षित केल्यानंतर, WP-CLI द्वारे दर मिनिटाला (किंवा तुम्हाला आवश्यक असलेल्या वेळेनुसार) WordPress ला कॉल करण्यासाठी system scheduler वापरा:

wp cron event run --due-now

ही एकच कमांड नियंत्रित वातावरणात core cron events आणि Action Scheduler queue प्रोसेस करते, ज्यासाठी तुम्ही इतर कोणत्याही CLI टास्कसाठी वापरत असलेल्या PHP process चा वापर करता.

तुम्ही मोजू शकणारे फायदे

  • Security – कोणताही unauthenticated यूजर जड background work सुरू करू शकत नाही.
  • Performance – PHP workers खऱ्या व्हिजिटर्ससाठी उपलब्ध राहतात; विनाकारण होणाऱ्या cron hits मुळे होणारे memory spikes निघून जातात.
  • Reliability – Scheduling अधिक proactive होते; तुम्हाला नक्की माहित असेल की जॉब कधी रन होतो कारण तो व्हिजिटरच्या पेज लोडवर नाही, तर सिस्टमच्या cron द्वारे चालवला जातो.

बदल केल्यानंतर काय लक्ष ठेवायचे

wp-cron.php च्या HTTP status code वर अवलंबून राहू नका; PHP द्वारे ब्लॉक केले असतानाही तो 200 रिटर्न करू शकतो. त्याऐवजी:

  • Action Scheduler queue चा आकार (size) मॉनिटर करा. वाढती queue अनेकदा मिस झालेल्या runs चे संकेत देते.
  • wp-cron.php location block मधून येणाऱ्या “403” entries साठी सर्व्हर लॉग्स तपासा.
  • लोड कमी झाला आहे की नाही हे तपासण्यासाठी peak traffic दरम्यान PHP-FPM किंवा FastCGI process counts तपासा.

एक सावधगिरीची सूचना

काही ॲडमिनिस्ट्रेटर्स DISABLE_WP_CRON false ठेवतात कारण ते कमी ट्रॅफिक असलेल्या साइट्सवर cron नैसर्गिकरित्या ट्रिगर व्हावा यावर अवलंबून असतात. वरील पद्धत त्या अवलंबित्व पूर्णपणे काढून टाकते, परंतु ती एक मेंटेनन्स स्टेप जोडते: तुम्हाला सिस्टम scheduler विश्वसनीयपणे चालत असल्याची खात्री करावी लागेल. जर सर्व्हरचा cron daemon फेल झाला, तर scheduled jobs थांबतील. ही अडचण टाळण्यासाठी सेटअपसोबत सिस्टम cron सर्व्हिसचे मॉनिटरिंग देखील करा.

Bottom line: DISABLE_WP_CRON true सेट केल्याने फक्त WordPress स्वतःला ping करणे थांबवते; ते public wp-cron.php endpoint बंद करत नाही. फाईलला web-server वर ब्लॉक करा, mu-plugin fallback जोडा आणि सर्व scheduled work WP-CLI द्वारे system scheduler कडे वळवा. असे केल्याने साइट सुरक्षित होते, अनावश्यक PHP काम कमी होते आणि background tasks कधी कार्यान्वित होतील यावर तुम्हाला अचूक नियंत्रण मिळते.