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 'ਤੇ ਸੈੱਟ ਕਰਨ ਨਾਲ core ਨੂੰ ਉਹ internal request ਛੱਡਣ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। Core ਵੈੱਬ-ਸਰਵਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਇਹ wp-cron.php ਵਿੱਚ ਕੋਈ authentication layer ਜੋੜਦਾ ਹੈ। ਸਕ੍ਰਿਪਟ ਇੱਕ public URL ਵਜੋਂ ਬਣੀ ਰਹਿੰਦੀ ਹੈ ਜੋ 200 status ਰਿਟਰਨ ਕਰਦੀ ਹੈ, ਭਾਵੇਂ PHP process ਅੱਧ ਵਿਚਾਲੇ ਹੀ ਰੁਕ ਜਾਵੇ।

ਇੱਕ Attacker ਜੋ URL ਲੱਭ ਲੈਂਦਾ ਹੈ, ਉਹ ਇਸਨੂੰ ਵਾਰ-ਵਾਰ ping ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਹਰ ਵਾਰ WordPress ਨੂੰ ਸਾਰੇ plugins, themes ਅਤੇ database ਲੋਡ ਕਰਨੇ ਪੈਣਗੇ। ਇੱਕ shared host ਜਾਂ ਸੀਮਤ PHP workers ਵਾਲੀ ਸਾਈਟ 'ਤੇ, ਉਹ ਇੱਕ ਸਿੰਗਲ endpoint denial-of-service vector ਬਣ ਸਕਦਾ ਹੈ।

ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

Scheduled ਕੰਮਾਂ ਨੂੰ system-level scheduler (cron, systemd-timer, ਆਦਿ) 'ਤੇ ਲਿਜਾਣ ਅਤੇ public ਦਰਵਾਜ਼ੇ ਨੂੰ ਬੰਦ ਕਰਨ ਲਈ, ਇਹਨਾਂ ਪੰਜ ਕਦਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ।

1. Internal loopback ਨੂੰ ਡਿਸੇਬਲ ਕਰੋ

wp-config.php ਵਿੱਚ ਇਹ ਲਾਈਨ ਜੋੜੋ 

define( 'DISABLE_WP_CRON', true );

ਇਹ 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 cost ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।

3. Safety net ਵਜੋਂ ਇੱਕ mu-plugin ਜੋੜੋ

ਇੱਕ must-use plugin ਬਣਾਓ (wp-content/mu-plugins ਵਿੱਚ ਰੱਖਿਆ ਹੋਇਆ) ਜੋ wp-cron.php ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੀ ਕਿਸੇ ਵੀ request ਨੂੰ log ਕਰੇ ਅਤੇ 403 ਨਾਲ ਬਾਹਰ ਨਿਕਲ ਜਾਵੇ। ਇਹ ਉਹਨਾਂ requests ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ ਜੋ ਕਿਸੇ ਤਰ੍ਹਾਂ server rule ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਜਾਂਦੇ ਹਨ—ਸ਼ਾਇਦ ਕਿਸੇ ਵੱਖਰੇ 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 ਕਰੋ

Default Action Scheduler queue runner ਨੂੰ ਹਟਾ ਦਿਓ ਜੋ wp cron hook ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ queue ਉਦੋਂ ਹੀ ਚੱਲੇ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ command line ਤੋਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ trigger ਕਰਦੇ ਹੋ।

ਕੰਮਾਂ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਣਾ

Public endpoint ਨੂੰ ਬੰਦ ਕਰਨ ਤੋਂ ਬਾਅਦ, WP-CLI ਰਾਹੀਂ ਹਰ ਮਿੰਟ ਵਿੱਚ (ਜਾਂ ਜਿੰਨੀ ਵਾਰ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇ) WordPress ਨੂੰ ਚਲਾਉਣ ਲਈ system scheduler ਦੀ ਵਰਤੋਂ ਕਰੋ:

wp cron event run --due-now

ਉਹ ਇੱਕ ਸਿੰਗਲ command ਇੱਕ controlled environment ਵਿੱਚ core cron events ਅਤੇ Action Scheduler queue ਨੂੰ process ਕਰਦੀ ਹੈ, ਉਸੇ PHP process ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ CLI task ਲਈ ਵਰਤਦੇ ਹੋ।

ਫਾਇਦੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਮਾਪ ਸਕਦੇ ਹੋ

  • Security – ਕੋਈ ਵੀ unauthenticated user ਭਾਰੀ background work ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦਾ।
  • Performance – PHP workers ਅਸਲੀ ਵਿਜ਼ਿਟਰਾਂ ਲਈ ਉਪਲਬਧ ਰਹਿੰਦੇ ਹਨ; stray cron hits ਕਾਰਨ ਹੋਣ ਵਾਲੇ memory spikes ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ।
  • Reliability – Scheduling proactive ਬਣ ਜਾਂਦੀ ਹੈ; ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੋਈ job ਕਦੋਂ ਚੱਲਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ system ਦੇ cron ਦੁਆਰਾ ਚਲਾਈ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਕਿਸੇ ਵਿਜ਼ਿਟਰ ਦੇ page load ਦੁਆਰਾ।

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕਿਸ ਚੀਜ਼ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣੀ ਹੈ

wp-cron.php ਦੇ HTTP status code 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ; PHP ਦੁਆਰਾ ਬਲੌਕ ਕੀਤੇ ਜਾਣ 'ਤੇ ਵੀ ਇਹ 200 ਰਿਟਰਨ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ:

  • Action Scheduler queue ਦੇ ਆਕਾਰ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ। ਵਧਦੀ ਹੋਈ queue ਅਕਸਰ missed runs ਦਾ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ।
  • wp-cron.php location block ਤੋਂ “403” entries ਲਈ server logs ਚੈੱਕ ਕਰੋ।
  • Load ਘਟ ਗਿਆ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ peak traffic ਦੌਰਾਨ PHP-FPM ਜਾਂ FastCGI process counts ਨੂੰ ਦੇਖੋ।

ਸਾਵਧਾਨੀ ਲਈ ਇੱਕ ਨੋਟ

ਕੁਝ administrators DISABLE_WP_CRON ਨੂੰ false ਰੱਖਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ low-traffic साइटਾਂ 'ਤੇ cron ਨੂੰ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ trigger ਕਰਨ ਲਈ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਉਪਰੋਕਤ ਤਰੀਕਾ ਉਸ ਨਿਰਭਰਤਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ maintenance step ਜੋੜਦਾ ਹੈ: ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ system scheduler ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚੱਲੇ। ਜੇਕਰ ਸਰਵਰ ਦਾ cron daemon ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ scheduled jobs ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ। ਇਸ ਮੁਸੀਬਤ ਤੋਂ ਬਚਣ ਲਈ setup ਨੂੰ system cron service ਦੀ ਨਿਗਰਾਨੀ ਦੇ ਨਾਲ ਜੋੜੋ।

Bottom line: DISABLE_WP_CRON ਨੂੰ true 'ਤੇ ਸੈੱਟ ਕਰਨ ਨਾਲ ਸਿਰਫ਼ WordPress ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ping ਕਰਨ ਤੋਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ; ਇਹ public wp-cron.php endpoint ਨੂੰ ਬੰਦ ਨਹੀਂ ਕਰਦਾ। ਫਾਈਲ ਨੂੰ web-server 'ਤੇ ਬਲੌਕ ਕਰੋ, ਇੱਕ mu-plugin fallback ਜੋੜੋ, ਅਤੇ ਸਾਰੇ scheduled ਕੰਮਾਂ ਨੂੰ WP-CLI ਰਾਹੀਂ system scheduler ਰਾਹੀਂ ਰੂਟ ਕਰੋ। ਅਜਿਹਾ ਕਰਨ ਨਾਲ ਸਾਈਟ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ, ਬੇਲੋੜਾ PHP ਕੰਮ ਘਟਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਇਸ ਉੱਤੇ ਸਹੀ ਕੰਟਰੋਲ ਮਿਲਦਾ ਹੈ ਕਿ background tasks ਕਦੋਂ ਚੱਲਣੀਆਂ ਹਨ।