DISABLE_WP_CRON = true করার মানে এই নয় যে wp-cron.php এন্ডপয়েন্টটি সুরক্ষিত বা বন্ধ হয়ে গেছে; এটি কেবল WordPress-কে তার নিজস্ব loopback রিকোয়েস্ট পাঠানো থেকে বিরত রাখে। ফাইলটি ওয়েব থেকে অ্যাক্সেসযোগ্য থাকে, তাই যে কেউ এটি হিট করতে পারে এবং একটি সম্পূর্ণ WordPress bootstrap প্রক্রিয়া শুরু করতে পারে।

এই লুকানো এন্ট্রি পয়েন্টটি CPU, মেমরি এবং PHP workers অপচয় করতে পারে, বিশেষ করে ব্যস্ত সাইটগুলোতে। আপনি যদি ভেবে থাকেন যে আপনি দরজাটি বন্ধ করে দিয়েছেন, তবে আপনি তা করতে পারেননি—এখনও পর্যন্ত।

কেন এই সেটিংসটি প্রায়শই ভুল বোঝা হয়

যখন WordPress একটি শিডিউল করা টাস্ক (scheduled task) চালায়, তখন এটি প্রথমে তার নিজস্ব wp-cron.php ফাইলে একটি দ্রুত HTTP রিকোয়েস্ট পাঠানোর চেষ্টা করে। DISABLE_WP_CRON কে true হিসেবে সেট করলে কোর (core) সেই অভ্যন্তরীণ রিকোয়েস্টটি স্কিপ করতে বলে। কোর ওয়েব-সার্ভার কনফিগারেশন পরিবর্তন করে না, এমনকি wp-cron.php-তে কোনো অথেন্টিকেশন লেয়ারও যোগ করে না। স্ক্রিপ্টটি একটি পাবলিক URL হিসেবেই থেকে যায় যা 200 স্ট্যাটাস রিটার্ন করে, এমনকি যদি PHP প্রসেসটি মাঝপথে বন্ধও হয়ে যায়।

একজন আক্রমণকারী যদি URL-টি খুঁজে পায়, তবে সে বারবার এটি পিং (ping) করতে পারে, যার ফলে প্রতিবার WordPress-কে সমস্ত প্লাগইন, থিম এবং ডাটাবেস লোড করতে হয়। একটি শেয়ার্ড হোস্ট বা সীমিত PHP workers সম্পন্ন সাইটের ক্ষেত্রে, এই একটি মাত্র এন্ডপয়েন্ট Denial-of-Service (DoS) ভেক্টরে পরিণত হতে পারে।

আসলে যা করা প্রয়োজন

শিডিউল করা কাজগুলোকে সিস্টেম-লেভেল শিডিউলার (cron, systemd-timer, ইত্যাদি) এ স্থানান্তর করতে এবং পাবলিক প্রবেশপথটি বন্ধ করতে, নিচের পাঁচটি ধাপ অনুসরণ করুন।

1. অভ্যন্তরীণ loopback নিষ্ক্রিয় করুন

wp-config.php-তে এই লাইনটি যোগ করুন:

define( 'DISABLE_WP_CRON', true );

এটি WordPress-কে তার নিজস্ব 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 plugin তৈরি করুন (যা wp-content/mu-plugins-এ থাকবে) যা wp-cron.php-তে আসা যেকোনো রিকোয়েস্ট লগ করবে এবং 403 এর মাধ্যমে প্রসেসটি বন্ধ করে দেবে। এটি সেই রিকোয়েস্টগুলোকে শনাক্ত করবে যা কোনোভাবে সার্ভার রুল বাইপাস করে আসতে পারে—যেমন ভিন্ন কোনো হোস্টনেম বা CDN edge রুলের মাধ্যমে।

4. Action Scheduler-এর async কলগুলো দমন করুন

অনেক প্লাগইন Action Scheduler লাইব্রেরি ব্যবহার করে, যা নিজস্ব loopback রিকোয়েস্ট তৈরি করতে পারে। action_scheduler_queue_runner-এ হুক (hook) করুন এবং non-CLI রিকোয়েস্টের জন্য দ্রুত রিটার্ন করুন, যাতে লাইব্রেরিটি তার নিজস্ব প্রবেশপথ খোলার চেষ্টা না করে।

5. WP-Cron হুক থেকে queue runner-কে আনহুক (unhook) করুন

wp cron হুকের সাথে যুক্ত ডিফল্ট Action Scheduler queue runner-টি সরিয়ে ফেলুন। এটি নিশ্চিত করে যে কিউ (queue) কেবল তখনই চলবে যখন আপনি কমান্ড লাইন থেকে এটি স্পষ্টভাবে ট্রিগার করবেন।

সঠিকভাবে জব (job) চালানো

পাবলিক এন্ডপয়েন্টটি সুরক্ষিত করার পর, WP-CLI-এর মাধ্যমে প্রতি মিনিটে (বা আপনার প্রয়োজন অনুযায়ী নির্দিষ্ট সময় অন্তর) WordPress কল করার জন্য সিস্টেম শিডিউলার ব্যবহার করুন:

wp cron event run --due-now

এই একটি মাত্র কমান্ড একটি নিয়ন্ত্রিত পরিবেশে কোর ক্রন ইভেন্ট এবং Action Scheduler কিউ—উভয়ই প্রসেস করে, এবং এটি সেই একই PHP প্রসেস ব্যবহার করে যা আপনি অন্য যেকোনো CLI টাস্কের জন্য ব্যবহার করেন।

আপনি যে সুবিধাগুলো পরিমাপ করতে পারবেন

  • Security (নিরাপত্তা) – কোনো অননুমোদিত (unauthenticated) ব্যবহারকারী ভারী ব্যাকগ্রাউন্ড কাজ শুরু করতে পারবে না।
  • Performance (পারফরম্যান্স) – PHP workers প্রকৃত ভিজিটরদের জন্য উপলব্ধ থাকবে; এলোমেলো ক্রন হিট থেকে সৃষ্ট মেমরি স্পাইক (memory spikes) দূর হবে।
  • Reliability (নির্ভরযোগ্যতা) – শিডিউলিং প্রঅ্যাক্টিভ (proactive) হয়ে উঠবে; আপনি ঠিক জানবেন কখন একটি জব চলবে কারণ এটি সিস্টেমের ক্রন দ্বারা পরিচালিত হয়, কোনো ভিজিটরের পেজ লোড দ্বারা নয়।

পরিবর্তনের পর যা খেয়াল রাখতে হবে

wp-cron.php-এর HTTP স্ট্যাটাস কোডের ওপর নির্ভর করবেন না; PHP দ্বারা ব্লক করা হলেও এটি এখনও 200 রিটার্ন করতে পারে। পরিবর্তে:

  • Action Scheduler কিউ-এর সাইজ মনিটর করুন। কিউ ক্রমাগত বাড়তে থাকা মানে হলো জবগুলো মিস হচ্ছে।
  • wp-cron.php location ব্লক থেকে আসা “403” এন্ট্রিগুলোর জন্য সার্ভার লগ চেক করুন।
  • লোড কমেছে কিনা তা নিশ্চিত করতে পিক ট্রাফিক চলাকালীন PHP-FPM বা FastCGI প্রসেস কাউন্ট পর্যবেক্ষণ করুন।

একটি সতর্কবার্তা

কিছু অ্যাডমিনিস্ট্রেটর DISABLE_WP_CRON কে false রাখেন কারণ তারা কম ট্রাফিকযুক্ত সাইটে ক্রন স্বাভাবিকভাবে ট্রিগার হওয়ার ওপর নির্ভর করেন। উপরের পদ্ধতিটি সেই নির্ভরতা সম্পূর্ণভাবে দূর করে, তবে এটি একটি রক্ষণাবেক্ষণ ধাপ (maintenance step) যোগ করে: আপনাকে নিশ্চিত করতে হবে যে সিস্টেম শিডিউলার নির্ভরযোগ্যভাবে চলছে। যদি সার্ভারের ক্রন ডেমন (cron daemon) ব্যর্থ হয়, তবে শিডিউল করা জবগুলো বন্ধ হয়ে যাবে। এই সমস্যা এড়াতে সেটআপটির সাথে সিস্টেম ক্রন সার্ভিস মনিটর করার ব্যবস্থা রাখুন।

সারকথা: DISABLE_WP_CRON কে true হিসেবে সেট করা কেবল WordPress-কে নিজেকে পিং করা থেকে বিরত রাখে; এটি পাবলিক wp-cron.php এন্ডপয়েন্টটি বন্ধ করে না। ওয়েব-সার্ভারে ফাইলটি ব্লক করুন, একটি mu-plugin ফলব্যাক (fallback) যোগ করুন এবং WP-CLI-এর মাধ্যমে সমস্ত শিডিউল করা কাজ সিস্টেম শিডিউলারের মাধ্যমে পরিচালনা করুন। এটি সাইটকে সুরক্ষিত করে, অপ্রয়োজনীয় PHP কাজ কমায় এবং ব্যাকগ্রাউন্ড টাস্কগুলো কখন কার্যকর হবে তার ওপর আপনাকে নিখুঁত নিয়ন্ত্রণ দেয়।