DISABLE_WP_CRON = true എന്നത് wp-cron.php എൻഡ്പോയിന്റിനെ (endpoint) സുരക്ഷിതമാക്കുന്നില്ല; അത് വെറും വേർഡ്പ്രസ്സ് അതിന്റെ സ്വന്തം ലൂപ്പ്ബാക്ക് (loopback) റിക്വസ്റ്റ് അയക്കുന്നത് നിർത്തുക മാത്രമാണ് ചെയ്യുന്നത്. ഫയൽ ഇന്റർനെറ്റിലൂടെ ഇപ്പോഴും ലഭ്യമാണ്, അതിനാൽ ആർക്കും അത് ഉപയോഗിച്ച് ഒരു ഫുൾ വേർഡ്പ്രസ്സ് ബൂട്ട്‌സ്‌ട്രാപ്പ് (WordPress bootstrap) നിർബന്ധപൂർവ്വം പ്രവർത്തിപ്പിക്കാൻ സാധിക്കും.

ആ മറഞ്ഞിരിക്കുന്ന എൻട്രി പോയിന്റ് (entry point) സിപിയു (CPU), മെമ്മറി, പിഎച്ച്പി (PHP) വർക്കർ എന്നിവ പാഴാക്കിയേക്കാം, പ്രത്യേകിച്ച് തിരക്കുള്ള സൈറ്റുകളിൽ. നിങ്ങൾ വാതിൽ അടച്ചു എന്ന് കരുതിയിട്ടുണ്ടെങ്കിൽ, അത് ശരിയല്ല—അത് ഇപ്പോഴും തുറന്നുതന്നെ ഇരിക്കുന്നു.

ഈ സെറ്റിംഗ് എന്തുകൊണ്ടാണ് പലപ്പോഴും തെറ്റായി മനസ്സിലാക്കപ്പെടുന്നത്

വേർഡ്പ്രസ്സ് ഒരു ഷെഡ്യൂൾ ചെയ്ത ടാസ്ക് (scheduled task) നടത്തുമ്പോൾ, അത് ആദ്യം അതിന്റെ സ്വന്തം wp-cron.php ഫയലിലേക്ക് ഒരു ചെറിയ HTTP റിക്വസ്റ്റ് അയക്കാൻ ശ്രമിക്കുന്നു. DISABLE_WP_CRON എന്നത് true എന്ന് സെറ്റ് ചെയ്യുന്നത് ആ ആന്തരിക റിക്വസ്റ്റ് ഒഴിവാക്കാൻ കോറിനോട് (core) ആവശ്യപ്പെടുന്നു. എന്നാൽ കോർ വെബ്-സെർവർ കോൺഫിഗറേഷനിൽ മാറ്റം വരുത്തുന്നില്ല, അല്ലെങ്കിൽ wp-cron.php-യിലേക്ക് ഒരു ഓതന്റിക്കേഷൻ ലെയറും (authentication layer) ചേർക്കുന്നില്ല. പിഎച്ച്പി പ്രോസസ്സ് നേരത്തെ തന്നെ റദ്ദാക്കിയാൽ പോലും, ആ സ്ക്രിപ്റ്റ് ഒരു 200 സ്റ്റാറ്റസ് നൽകുന്ന പബ്ലിക് യുആർഎൽ (public URL) ആയി തന്നെ തുടരുന്നു.

ഈ URL കണ്ടെത്തുന്ന ഒരു അറ്റാക്കർക്ക് (attacker) അത് ആവർത്തിച്ച് പിംഗ് (ping) ചെയ്യാൻ സാധിക്കും, ഇത് ഓരോ തവണയും വേർഡ്പ്രസ്സ് എല്ലാ പ്ലഗിനുകളും തീമുകളും ഡാറ്റാബേസും ലോഡ് ചെയ്യാൻ കാരണമാകും. ഒരു ഷെയേർഡ് ഹോസ്റ്റിലോ (shared host) പരിമിതമായ PHP വർക്കറുകളുള്ള സൈറ്റിലോ, ഈ ഒറ്റ എൻഡ്പോയിന്റ് ഒരു ഡിനയൽ-ഓഫ്-സർവീസ് (denial-of-service) വെക്റ്ററായി മാറാം.

യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യേണ്ടത്

ഷെഡ്യൂൾ ചെയ്ത ജോലികൾ ഒരു സിസ്റ്റം-ലെവൽ ഷെഡ്യൂളറിലേക്ക് (cron, systemd-timer, etc.) മാറ്റുന്നതിനും പബ്ലിക് എൻട്രി പോയിന്റ് അടയ്ക്കുന്നതിനും ഈ അഞ്ച് ഘട്ടങ്ങൾ പിന്തുടരുക.

1. ആന്തരിക ലൂപ്പ്ബാക്ക് (internal loopback) ഡിസേബിൾ ചെയ്യുക

ഈ വരി ചേർക്കുക 

define( 'DISABLE_WP_CRON', true );

wp-config.php-ൽ. ഇത് വേർഡ്പ്രസ്സ് അതിന്റെ സ്വന്തം HTTP റിക്വസ്റ്റ് അയക്കുന്നത് തടയുന്നു, എന്നാൽ ഇത് ബാഹ്യമായ കോളുകളെ (external calls) തടയുന്നില്ല.

2. വെബ്-സെർവറിൽ wp-cron.php ബ്ലോക്ക് ചെയ്യുക

ഉദാഹരണത്തിന്, Nginx ഉപയോഗിക്കുകയാണെങ്കിൽ, 403 Forbidden നൽകുന്ന ഒരു location block ചേർക്കുക:

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

ഇപ്പോൾ PHP തുടങ്ങുന്നതിന് മുമ്പ് തന്നെ സെർവർ റിക്വസ്റ്റ് നിരസിക്കുന്നു, ഇത് ബൂട്ട്‌സ്‌ട്രാപ്പ് ചിലവ് (bootstrap cost) ഒഴിവാക്കുന്നു.

3. സുരക്ഷയ്ക്കായി ഒരു mu-plugin ചേർക്കുക

wp-cron.php-ലേക്ക് എത്തുന്ന ഏതൊരു റിക്വസ്റ്റും ലോഗ് ചെയ്യുകയും 403 നൽകി പുറത്തുകടക്കുകയും ചെയ്യുന്ന ഒരു മസ്റ്റ്-യൂസ് പ്ലഗിൻ (wp-content/mu-plugins-ൽ ചേർക്കുക) നിർമ്മിക്കുക. സെർവർ റൂൾസ് ഏതെങ്കിലും തരത്തിൽ മറികടന്നാൽ (ഒരുപക്ഷേ മറ്റൊരു ഹോസ്റ്റ് നെയിം അല്ലെങ്കിൽ ഒരു CDN എഡ്ജ് റൂൾ വഴി) പോലും ഇത് റിക്വസ്റ്റുകളെ പിടികൂടും.

4. Action Scheduler async കോളുകൾ നിയന്ത്രിക്കുക

പല പ്ലഗിനുകളും Action Scheduler ലൈബ്രറി ഉപയോഗിക്കുന്നു, ഇത് സ്വന്തമായി ലൂപ്പ്ബാക്ക് റിക്വസ്റ്റുകൾ ഉണ്ടാക്കിയേക്കാം. action_scheduler_queue_runner-ൽ ഹുക്ക് (hook) ചെയ്യുകയും non-CLI റിക്വസ്റ്റുകൾക്കായി നേരത്തെ തന്നെ റിട്ടേൺ ചെയ്യുകയും ചെയ്യുക, ഇത് ലൈബ്രറി സ്വന്തം വാതിലുകൾ തുറക്കാൻ ശ്രമിക്കുന്നത് തടയുന്നു.

5. WP-Cron ഹുക്കിൽ നിന്ന് ക്യൂ റണ്ണറെ (queue runner) മാറ്റുക

wp cron ഹുക്കിൽ ഘടിപ്പിച്ചിട്ടുള്ള ഡിഫോൾട്ട് Action Scheduler ക്യൂ റണ്ണർ നീക്കം ചെയ്യുക. ഇത് നിങ്ങൾ കമാൻഡ് ലൈനിൽ നിന്ന് നേരിട്ട് പ്രവർത്തിപ്പിക്കുമ്പോൾ മാത്രം ക്യൂ പ്രവർത്തിക്കുന്നു എന്ന് ഉറപ്പാക്കുന്നു.

ജോലികൾ ശരിയായ രീതിയിൽ പ്രവർത്തിപ്പിക്കുക

പബ്ലിക് എൻഡ്പോയിന്റ് സുരക്ഷിതമാക്കിയ ശേഷം, WP-CLI വഴി ഓരോ മിനിറ്റിലും (അല്ലെങ്കിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ള ഇടവേളകളിൽ) വേർഡ്പ്രസ്സിനെ വിളിക്കാൻ സിസ്റ്റം ഷെഡ്യൂളർ ഉപയോഗിക്കുക:

wp cron event run --due-now

ആ ഒറ്റ കമാൻഡ് ഉപയോഗിച്ച് കോർ ക്രോൺ ഇവന്റുകളും (core cron events) Action Scheduler ക്യൂവും നിയന്ത്രിത സാഹചര്യത്തിൽ പ്രോസസ്സ് ചെയ്യുന്നു, മറ്റ് CLI ടാസ്ക്കുകൾക്കായി നിങ്ങൾ ഉപയോഗിക്കുന്ന അതേ PHP പ്രോസസ്സ് തന്നെയാണിവിടെ ഉപയോഗിക്കുന്നത്.

നിങ്ങൾക്ക് അളക്കാവുന്ന ഗുണങ്ങൾ

  • സുരക്ഷ (Security) – ഓതന്റിക്കേഷൻ ഇല്ലാത്ത ഒരു ഉപയോക്താവിനും ഭാരമേറിയ ബാക്ക്ഗ്രൗണ്ട് ജോലികൾ ആരംഭിക്കാൻ കഴിയില്ല.
  • പ്രകടനം (Performance) – യഥാർത്ഥ സന്ദർശകർക്കായി PHP വർക്കറുകൾ ലഭ്യമായിരിക്കും; അനാവശ്യ ക്രോൺ ഹിറ്റുകൾ മൂലമുണ്ടാകുന്ന മെമ്മറി സ്പൈക്കുകൾ (memory spikes) ഇല്ലാതാകും.
  • വിശ്വസനീയത (Reliability) – ഷെഡ്യൂളിംഗ് കൂടുതൽ കൃത്യതയുള്ളതാകുന്നു; ഒരു ജോലി എപ്പോൾ പ്രവർത്തിക്കുന്നു എന്ന് നിങ്ങൾക്ക് കൃത്യമായി അറിയാം, കാരണം അത് ഒരു സന്ദർശകന്റെ പേജ് ലോഡ് വഴിയല്ല, മറിച്ച് സിസ്റ്റത്തിന്റെ ക്രോൺ വഴിയാണ് പ്രവർത്തിക്കുന്നത്.

മാറ്റത്തിന് ശേഷം ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

wp-cron.php-യുടെ HTTP സ്റ്റാറ്റസ് കോഡിൽ മാത്രം ആശ്രയിക്കരുത്; PHP വഴി ബ്ലോക്ക് ചെയ്യപ്പെട്ടാലും ഇത് 200 നൽകിയേക്കാം. പകരം:

  • Action Scheduler ക്യൂ സൈസ് നിരീക്ഷിക്കുക. ക്യൂ കൂടുന്നത് ജോലികൾ കൃത്യസമയത്ത് നടക്കാത്തതിന്റെ സൂചനയാകാം.
  • wp-cron.php location block-ൽ നിന്നുള്ള “403” എൻട്രികൾക്കായി സെർവർ ലോഗുകൾ പരിശോധിക്കുക.
  • തിരക്കുള്ള സമയങ്ങളിൽ PHP-FPM അല്ലെങ്കിൽ FastCGI പ്രോസസ്സ് എണ്ണം നിരീക്ഷിക്കുക, ഇത് ലോഡ് കുറഞ്ഞുവെന്ന് ഉറപ്പാക്കാൻ സഹായിക്കും.

ഒരു മുന്നറിയിപ്പ്

ചില അഡ്മിനിസ്ട്രേറ്റർമാർ DISABLE_WP_CRON false ആയി നിലനിർത്താറുണ്ട്, കാരണം കുറഞ്ഞ ട്രാഫിക്കുള്ള സൈറ്റുകളിൽ ക്രോൺ സ്വാഭാവികമായി പ്രവർത്തിക്കാൻ അവർ ആഗ്രഹിക്കുന്നു. മുകളിൽ പറഞ്ഞ രീതി ആ ആശ്രയത്വം പൂർണ്ണമായും ഒഴിവാക്കുന്നു, എന്നാൽ ഇത് ഒരു മെയിന്റനൻസ് ഘട്ടം കൂടി കൂട്ടിച്ചേർക്കുന്നു: സിസ്റ്റം ഷെഡ്യൂളർ വിശ്വസനീയമായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് നിങ്ങൾ ഉറപ്പാക്കണം. സെർവറിലെ ക്രോൺ ഡെമൺ (cron daemon) പരാജയപ്പെട്ടാൽ, ഷെഡ്യൂൾ ചെയ്ത ജോലികൾ നിൽക്കും. ഈ പ്രശ്നം ഒഴിവാക്കാൻ സിസ്റ്റം ക്രോൺ സർവീസ് നിരീക്ഷിക്കുന്നതിനൊപ്പം ഈ സെറ്റപ്പ് കൂടി ചെയ്യുക.

ചുരുക്കത്തിൽ: DISABLE_WP_CRON എന്നത് true ആക്കുന്നത് വേർഡ്പ്രസ്സ് സ്വയം പിംഗ് ചെയ്യുന്നത് തടയാൻ മാത്രമാണ്; അത് പബ്ലിക് ആയ wp-cron.php എൻഡ്പോയിന്റ് അടയ്ക്കുന്നില്ല. വെബ്-സെർവറിൽ ഫയൽ ബ്ലോക്ക് ചെയ്യുക, ഒരു mu-plugin ഫാള்பാക്ക് (fallback) ചേർക്കുക, കൂടാതെ എല്ലാ ഷെഡ്യൂൾ ചെയ്ത ജോലികളും WP-CLI വഴി ഒരു സിസ്റ്റം ഷെഡ്യൂളറിലൂടെ റൂട്ട് ചെയ്യുക. ഇത് സൈറ്റിനെ സുരക്ഷിതമാക്കുകയും, അനാവശ്യമായ PHP ജോലി കുറയ്ക്കുകയും, ബാക്ക്ഗ്രൗണ്ട് ടാസ്ക്കുകൾ എപ്പോൾ പ്രവർത്തിക്കണം എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് കൃത്യമായ നിയന്ത്രണം നൽകുകയും ചെയ്യുന്നു.