DISABLE_WP_CRON = true ಎಂಬುದು wp-cron.php ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು (endpoint) ಸಂಪೂರ್ಣವಾಗಿ ಮುಚ್ಚುವುದಿಲ್ಲ; ಇದು ಕೇವಲ WordPress ತನ್ನದೇ ಆದ loopback request ಅನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಮಾತ್ರ ತಡೆಯುತ್ತದೆ. ಈ ಫೈಲ್ ವೆಬ್ ಮೂಲಕ ಲಭ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾರೇ ಬೇಕಾದರೂ ಅದನ್ನು ಬಳಸಿ ಪೂರ್ಣ WordPress bootstrap ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು.

ಆ ಗುಪ್ತ ಪ್ರವೇಶ ದ್ವಾರವು (entry point) CPU, ಮೆಮೊರಿ ಮತ್ತು 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 ಪ್ರಕ್ರಿಯೆಯು ಮೊದಲೇ ಸ್ಥಗಿತಗೊಂಡರೂ ಸಹ, ಆ ಸ್ಕ್ರಿಪ್ಟ್ 200 status ಅನ್ನು ನೀಡುವ ಸಾರ್ವಜನಿಕ URL ಆಗಿಯೇ ಉಳಿಯುತ್ತದೆ.

ಈ URL ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವ ದಾಳಿಕೋರರು (attacker) ಅದನ್ನು ಪದೇ ಪದೇ ping ಮಾಡಬಹುದು, ಇದರಿಂದ ಪ್ರತಿ ಬಾರಿಯೂ WordPress ಎಲ್ಲಾ plugins, themes ಮತ್ತು database ಅನ್ನು ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. Shared host ಅಥವಾ ಸೀಮಿತ PHP workers ಇರುವ ಸೈಟ್‌ನಲ್ಲಿ, ಆ ಒಂದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್ denial-of-service vector ಆಗಿ ಪರಿಣಮಿಸಬಹುದು.

ನಿಜವಾಗಿಯೂ ಏನು ಮಾಡಬೇಕಿದೆ

ನಿಗದಿತ ಕೆಲಸಗಳನ್ನು system-level scheduler (cron, systemd-timer, ಇತ್ಯಾದಿ) ಗೆ ವರ್ಗಾಯಿಸಲು ಮತ್ತು ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶವನ್ನು ಮುಚ್ಚಲು, ಈ ಐದು ಹಂತಗಳನ್ನು ಅನುಸರಿಸಿ.

1. ಆಂತರಿಕ loopback ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ

ಈ ಸಾಲನ್ನು ಸೇರಿಸಿ

define( 'DISABLE_WP_CRON', true );

wp-config.php ಗೆ. ಇದು WordPress ತನ್ನದೇ ಆದ HTTP request ಅನ್ನು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಆದರೆ ಇದು ಬಾಹ್ಯ (external) ಕರೆಗಳನ್ನು ತಡೆಯುವುದಿಲ್ಲ.

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 ನಲ್ಲಿ ಇರಿಸಿ) ರಚಿಸಿ. ಇದು ಸರ್ವರ್ ನಿಯಮಗಳನ್ನು ತಪ್ಪಿಸಿಕೊಂಡು ಬರುವ request ಗಳನ್ನು (ಬಹುಶಃ ಬೇರೆ hostname ಅಥವಾ CDN edge rule ಮೂಲಕ) ಹಿಡಿಯುತ್ತದೆ.

4. Action Scheduler async ಕರೆಗಳನ್ನು ತಡೆಯಿರಿ

ಅನೇಕ plugins Action Scheduler library ಅನ್ನು ಬಳಸುತ್ತವೆ, ಇದು ತನ್ನದೇ ಆದ loopback request ಗಳನ್ನು ಸೃಷ್ಟಿಸಬಹುದು. action_scheduler_queue_runner ಗೆ hook ಮಾಡಿ ಮತ್ತು non-CLI request ಗಳಿಗೆ ಮೊದಲೇ return ಮಾಡಿ, ಇದರಿಂದ ಆ library ತನ್ನದೇ ಆದ ದ್ವಾರಗಳನ್ನು ತೆರೆಯುವುದನ್ನು ತಡೆಯಬಹುದು.

5. WP-Cron hook ನಿಂದ queue runner ಅನ್ನು ತೆಗೆದುಹಾಕಿ

wp cron hook ಗೆ ಅಂಟಿಕೊಂಡಿರುವ ಡಿಫಾಲ್ಟ್ Action Scheduler queue runner ಅನ್ನು ತೆಗೆದುಹಾಕಿ. ಇದರಿಂದ ನೀವು command line ನಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ಟ್ರಿಗ್ಗರ್ ಮಾಡಿದಾಗ ಮಾತ್ರ queue ಚಾಲನೆಯಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು.

ಕೆಲಸಗಳನ್ನು ಸರಿಯಾದ ರೀತಿಯಲ್ಲಿ ನಡೆಸುವುದು

ಸಾರ್ವಜನಿಕ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮುಚ್ಚಿದ ನಂತರ, WP-CLI ಮೂಲಕ ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ ಒಮ್ಮೆ (ಅಥವಾ ನಿಮಗೆ ಬೇಕಾದ ವೇಗದಲ್ಲಿ) WordPress ಅನ್ನು ಕರೆಯಲು system scheduler ಅನ್ನು ಬಳಸಿ:

wp cron event run --due-now

ಆ ಒಂದೇ ಕಮಾಂಡ್ ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ core cron events ಮತ್ತು Action Scheduler queue ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ಯಾವುದೇ ಇತರ CLI ಕಾರ್ಯಕ್ಕಾಗಿ ಬಳಸುವ ಅದೇ PHP ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಳಸುತ್ತದೆ.

ನೀವು ಅಳೆಯಬಹುದಾದ ಪ್ರಯೋಜನಗಳು

  • Security (ಸುರಕ್ಷತೆ) – ಯಾವುದೇ ಅಧೀಕೃತವಲ್ಲದ (unauthenticated) ಬಳಕೆದಾರನು ಭಾರೀ ಹಿನ್ನೆಲೆ ಕೆಲಸಗಳನ್ನು (background work) ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
  • Performance (ಕಾರ್ಯಕ್ಷಮತೆ) – PHP workers ನಿಜವಾದ ಸಂದರ್ಶಕರಿಗಾಗಿ ಲಭ್ಯವಿರುತ್ತವೆ; ಅನಗತ್ಯ cron hits ನಿಂದ ಉಂಟಾಗುವ memory spikes ಮಾಯವಾಗುತ್ತವೆ.
  • Reliability (ವಿಶ್ವಾಸಾರ್ಹತೆ) – ಶೆಡ್ಯೂಲಿಂಗ್ ಪ್ರೊಆಕ್ಟಿವ್ ಆಗುತ್ತದೆ; ಕೆಲಸವು ಯಾವಾಗ ನಡೆಯುತ್ತದೆ ಎಂಬುದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ವಿಸಿಟರ್‌ನ ಪೇಜ್ ಲೋಡ್ ಮೂಲಕ ಅಲ್ಲದೆ, ಸಿಸ್ಟಮ್‌ನ cron ಮೂಲಕ ಚಾಲನೆಯಾಗುತ್ತದೆ.

ಬದಲಾವಣೆಯ ನಂತರ ಗಮನಿಸಬೇಕಾದವುಗಳು

wp-cron.php ನ HTTP status code ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬೇಡಿ; PHP ಮೂಲಕ ಬ್ಲಾಕ್ ಮಾಡಲ್ಪಟ್ಟಿದ್ದರೂ ಸಹ ಅದು 200 ಅನ್ನು ನೀಡಬಹುದು. ಬದಲಾಗಿ:

  • Action Scheduler queue ಗಾತ್ರವನ್ನು ಗಮನಿಸಿ. ಕ್ಯೂ (queue) ಹೆಚ್ಚಾಗುತ್ತಿದ್ದರೆ, ಅದು ಕೆಲಸಗಳು ತಪ್ಪುತ್ತಿವೆ ಎಂಬುದರ ಸಂಕೇತವಾಗಿರಬಹುದು.
  • wp-cron.php location block ನಿಂದ ಬರುವ “403” ಎಂಟ್ರಿಗಳಿಗಾಗಿ ಸರ್ವರ್ ಲಾಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
  • ಲೋಡ್ ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಿರುವ ಸಮಯದಲ್ಲಿ PHP-FPM ಅಥವಾ FastCGI ಪ್ರಕ್ರಿಯೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಗಮನಿಸಿ.

ಎಚ್ಚರಿಕೆಯ ಸೂಚನೆ

ಕೆಲವು ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್‌ಗಳು ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಇರುವ ಸೈಟ್‌ಗಳು ನೈಸರ್ಗಿಕವಾಗಿ cron ಅನ್ನು ಟ್ರಿಗ್ಗರ್ ಮಾಡುತ್ತದೆ ಎಂಬ ನಂಬಿಕೆಯಿಂದ DISABLE_WP_CRON ಅನ್ನು false ಎಂದು ಇಡುತ್ತಾರೆ. ಮೇಲಿನ ವಿಧಾನವು ಆ ಅವಲಂಬನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದರೆ ಇದು ನಿರ್ವಹಣೆಯ (maintenance) ಹಂತವನ್ನು ಸೇರಿಸುತ್ತದೆ: ಸಿಸ್ಟಮ್ ಶೆಡ್ಯೂಲರ್ ನಂಬಿಕಾರ್ಹವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಸರ್ವರ್‌ನ cron daemon ವಿಫಲವಾದರೆ, ನಿಗದಿತ ಕೆಲಸಗಳು ನಿಂತುಹೋಗುತ್ತವೆ. ಅಂತಹ ತೊಂದರೆಯನ್ನು ತಪ್ಪಿಸಲು, ಈ ಸೆಟಪ್ ಅನ್ನು ಸಿಸ್ಟಮ್ cron ಸೇವೆಯ ಮೇಲಿನ ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ (monitoring) ಜೋಡಿಸಿ.

ಸಾರಾಂಶ (Bottom line): DISABLE_WP_CRON ಅನ್ನು true ಎಂದು ಸೆಟ್ ಮಾಡುವುದು WordPress ತನ್ನನ್ನು ತಾನು ping ಮಾಡುವುದನ್ನು ಮಾತ್ರ ತಡೆಯುತ್ತದೆ; ಇದು ಸಾರ್ವಜನಿಕ wp-cron.php ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಮುಚ್ಚುವುದಿಲ್ಲ. ಫೈಲ್ ಅನ್ನು web-server ನಲ್ಲಿ ಬ್ಲಾಕ್ ಮಾಡಿ, ಒಂದು mu-plugin fallback ಅನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಎಲ್ಲಾ ನಿಗದಿತ ಕೆಲಸಗಳನ್ನು WP-CLI ಮೂಲಕ system scheduler ಮೂಲಕ ರನ್ ಮಾಡಿ. ಹೀಗೆ ಮಾಡುವುದರಿಂದ ಸೈಟ್ ಸುರಕ್ಷಿತವಾಗುತ್ತದೆ, ಅನಗತ್ಯ PHP ಕೆಲಸಗಳು ಕಡಿಮೆಯಾಗುತ್ತವೆ ಮತ್ತು ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳು ಯಾವಾಗ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತವೆ ಎಂಬುದರ ಮೇಲೆ ನಿಮಗೆ ನಿಖರವಾದ ನಿಯಂತ್ರಣ ಸಿಗುತ್ತದೆ.