DISABLE_WP_CRON = true என்பது wp-cron.php endpoint-ஐப் பூட்டாது; இது WordPress தனது சொந்த loopback request-ஐ இயக்குவதை மட்டுமே நிறுத்தும். அந்தத் கோப்பு இணையத்திலிருந்து அணுகக்கூடிய நிலையிலேயே இருக்கும், எனவே எவர் வேண்டுமானாலும் அதை அணுகி முழுமையான WordPress bootstrap-ஐத் தூண்ட முடியும்.

அந்த மறைமுகமான நுழைவுப் புள்ளி (entry point), குறிப்பாகப் பிஸியான இணையதளங்களில் CPU, memory மற்றும் PHP workers ஆகியவற்றை வீணடிக்கக்கூடும். நீங்கள் கதவை மூடிவிட்டதாக நினைத்தால், இன்னும் அவ்வாறு செய்யவில்லை என்று அர்த்தம்.

இந்தச் செயல்முறை ஏன் பெரும்பாலும் தவறாகப் புரிந்துகொள்ளப்படுகிறது

WordPress ஒரு திட்டமிடப்பட்ட பணியைச் (scheduled task) செய்யும்போது, முதலில் தனது சொந்த wp-cron.php கோப்பிற்கு ஒரு விரைவான HTTP request-ஐ அனுப்ப முயற்சிக்கும். DISABLE_WP_CRON-ஐ true என அமைப்பது, அந்த உள்முறை (internal) request-ஐத் தவிர்க்க core-இடம் கூறுகிறது. ஆனால், core இணையச் சேவையகத்தின் (web-server) கட்டமைப்பை மாற்றாது, அல்லது wp-cron.php-க்கு எந்தவொரு அங்கீகார அடுக்கையும் (authentication layer) சேர்க்காது. PHP செயல்முறை முன்கூட்டியே நிறுத்தப்பட்டாலும், அந்த ஸ்கிரிப்ட் ஒரு பொதுவான URL-ஆகவே இருக்கும் மற்றும் 200 status-ஐத் தரும்.

அந்த URL-ஐக் கண்டறியும் ஒரு தாக்குதல் நடத்துபவர் (attacker), அதைத் திரும்பத் திரும்ப ping செய்ய முடியும், இதனால் ஒவ்வொரு முறையும் WordPress அனைத்து plugins, themes மற்றும் database ஆகியவற்றையும் ஏற்ற வேண்டியிருக்கும். ஒரு shared host அல்லது குறைந்த PHP workers கொண்ட இணையதளத்தில், அந்த ஒற்றை endpoint ஒரு denial-of-service (DoS) தாக்குதலுக்கான வழியாக மாறக்கூடும்.

உண்மையில் செய்ய வேண்டியவை என்ன?

திட்டமிடப்பட்ட பணிகளை ஒரு system-level scheduler (cron, systemd-timer, போன்றவை) மூலம் மாற்றி, பொதுவான நுழைவுப் பாதையை மூட, இந்த ஐந்து படிகளைப் பின்பற்றவும்.

1. உள்முறை loopback-ஐ முடக்குதல்

wp-config.php-இல் இந்த வரியைச் சேர்க்கவும்: 

define( 'DISABLE_WP_CRON', true );

இது WordPress தனது சொந்த HTTP request-ஐ முயற்சிப்பதைத் தடுக்கும், ஆனால் இது வெளிப்புற அழைப்புகளை (external calls) நிறுத்தாது.

2. Web-server-இல் wp-cron.php-ஐத் தடுத்தல்

உதாரணமாக, Nginx-இல், 403 Forbidden-ஐத் திருப்பி அனுப்பும் ஒரு location block-ஐச் சேர்க்கவும்:

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

இப்போது PHP தொடங்குவதற்கு முன்பே சேவையகம் அந்த request-ஐ நிராகரித்துவிடும், இதனால் bootstrap செலவு தவிர்க்கப்படுகிறது.

3. பாதுகாப்பு வலையாக (safety net) ஒரு mu-plugin-ஐச் சேர்த்தல்

wp-cron.php-ஐச் சென்றடையும் எந்தவொரு request-ஐயும் பதிவு செய்து (log), 403 உடன் வெளியேறும் ஒரு must-use plugin-ஐ (wp-content/mu-plugins-இல் வைக்கவும்) உருவாக்கவும். இது ஒருவேளை வேறு hostname அல்லது CDN edge rule மூலம் server விதியைத் தாண்டி வரும் request-களைப் பிடிக்க உதவும்.

4. Action Scheduler async அழைப்புகளைத் தடுத்தல்

பல plugins Action Scheduler library-ஐப் பயன்படுத்துகின்றன, இது அதன் சொந்த loopback request-களை உருவாக்கக்கூடும். action_scheduler_queue_runner-இல் hook செய்து, non-CLI request-களுக்கு முன்கூட்டியே வெளியேறுமாறு (return early) செய்வதன் மூலம், அந்த library தனது சொந்த நுழைவுப் பாதைகளைத் திறப்பதைத் தவிர்க்கலாம்.

5. WP-Cron hook-லிருந்து queue runner-ஐ நீக்குதல்

wp cron hook-உடன் இணைக்கப்பட்டுள்ள இயல்புநிலை (default) Action Scheduler queue runner-ஐ நீக்கவும். இதன் மூலம், நீங்கள் command line மூலம் நேரடியாகத் தூண்டும்போது மட்டுமே queue இயங்குவதை உறுதி செய்யலாம்.

பணிகளைச் சரியான முறையில் இயக்குதல்

பொதுவான endpoint மூடப்பட்ட பிறகு, WP-CLI மூலம் நிமிடத்திற்கு ஒருமுறை (அல்லது உங்களுக்குத் தேவையான இடைவெளியில்) WordPress-ஐ இயக்க system scheduler-ஐப் பயன்படுத்தவும்:

wp cron event run --due-now

அந்த ஒற்றை கட்டளை (command), நீங்கள் மற்ற CLI பணிகளுக்குப் பயன்படுத்தும் அதே PHP process-ஐப் பயன்படுத்தி, core cron நிகழ்வுகள் மற்றும் Action Scheduler queue ஆகியவற்றை ஒரு கட்டுப்படுத்தப்பட்ட சூழலில் செயலாக்கும்.

நீங்கள் உணரக்கூடிய நன்மைகள்

  • பாதுகாப்பு (Security) – அங்கீகரிக்கப்படாத (unauthenticated) பயனரால் அதிகப்படியான பின்னணிப் பணிகளைத் தொடங்க முடியாது.
  • செயல்திறன் (Performance) – PHP workers உண்மையான பார்வையாளர்களுக்குக் கிடைப்பார்கள்; தேவையற்ற cron hits-களால் ஏற்படும் memory spikes தவிர்க்கப்படும்.
  • நம்பகத்தன்மை (Reliability) – திட்டமிடுதல் (Scheduling) முன்கூட்டியே திட்டமிடப்பட்டதாக மாறும்; ஒரு பணி எப்போது இயங்குகிறது என்பதை நீங்கள் துல்லியமாகத் தெரிந்து கொள்ளலாம், ஏனெனில் அது பார்வையாளரின் page load மூலம் அல்லாமல், system-ன் cron மூலம் இயக்கப்படுகிறது.

மாற்றத்திற்குப் பிறகு கவனிக்க வேண்டியவை

wp-cron.php-இன் HTTP status code-ஐ மட்டும் நம்பியிருக்க வேண்டாம்; PHP மூலம் தடுக்கப்பட்டாலும் அது 200 status-ஐத் தரக்கூடும். அதற்குப் பதிலாக:

  • Action Scheduler queue அளவைக் கண்காணிக்கவும். வரிசை (queue) அதிகரிப்பது, பணிகள் இயங்கத் தவறியதைக் குறிக்கலாம்.
  • wp-cron.php location block-லிருந்து வரும் “403” பதிவுகளை (entries) server logs-இல் சரிபார்க்கவும்.
  • சுமை குறைந்துள்ளதை உறுதிப்படுத்த, அதிகப்படியான டிராஃபிக் (peak traffic) இருக்கும்போது PHP-FPM அல்லது FastCGI process எண்ணிக்கையைக் கவனிக்கவும்.

ஒரு எச்சரிக்கை குறிப்பு

சில நிர்வாகிகள் குறைந்த டிராஃபிக் கொண்ட இணையதளங்கள் இயல்பாகவே cron-ஐத் தூண்டும் என்பதால் DISABLE_WP_CRON-ஐ false நிலையில் வைத்திருக்கிறார்கள். மேலே உள்ள அணுகுமுறை அந்தச் சார்புநிலையை முற்றிலும் நீக்குகிறது, ஆனால் இது ஒரு பராமரிப்புப் பணியைச் சேர்க்கிறது: system scheduler நம்பகமான முறையில் இயங்குவதை நீங்கள் உறுதி செய்ய வேண்டும். சர்வரின் cron daemon செயலிழந்தால், திட்டமிடப்பட்ட பணிகள் நின்றுவிடும். அந்தத் தவறைத் தவிர்க்க, இந்த அமைப்பை system cron சேவையின் கண்காணிப்புடன் இணைக்கவும்.

சுருக்கமாகச் சொன்னால்: DISABLE_WP_CRON-ஐ true என அமைப்பது WordPress தன்னைத் தானே அழைப்பதைத் மட்டுமே தடுக்கும்; அது பொதுவான wp-cron.php endpoint-ஐ மூடாது. கோப்பை web-server-இல் தடுத்து, ஒரு mu-plugin fallback-ஐச் சேர்த்து, அனைத்துத் திட்டமிடப்பட்ட பணிகளையும் WP-CLI மூலம் system scheduler வழியாக இயக்கவும். இவ்வாறு செய்வதன் மூலம் இணையதளத்தைப் பாதுகாக்கவும், தேவையற்ற PHP வேலைகளைக் குறைக்கவும், பின்னணிப் பணிகள் எப்போது இயங்க வேண்டும் என்பதைக் கட்டுப்படுத்தவும் முடியும்.