WordPress में WP-Cron बंद करके system cron कैसे लगाएँ

WP-Cron क्या है और system cron इसे क्यों replace करता है

WP-Cron, WordPress में built-in task scheduler है। यह तभी चलता है जब कोई page request करता है। WordPress के अंदर अपने-आप कोई प्रक्रिया शुरू नहीं होती। हर ऐसी request पर, जो cache से serve नहीं होती, WordPress scheduled jobs की सूची पढ़ता है। यदि कोई job due हो, तो काम पूरा करने के लिए यह /wp-cron.php पर अपने-आप को दूसरी HTTP request भेजता है। इस job को system cron में स्थानांतरित करने से fixed schedule पर एक predictable run मिलता है, चाहे उस मिनट site पर एक हजार visitors आए हों या कोई भी नहीं आया हो।

वास्तविक काम दो lines करती हैं: wp-config.php में एक constant और crontab entry। इस guide का बाकी हिस्सा उन दो lines से बाहर की जानकारी देता है। Job किस user के रूप में चलनी चाहिए, scheduled events वास्तव में fire हुए हैं या नहीं यह कैसे verify करें, और setup किन तीन तरीकों से site पर कुछ print किए बिना fail हो सकता है।

उदाहरणों में /srv/www/example.com को WordPress directory और www-data को web server user माना गया है। हर जगह अपने paths और user रखें।

व्यस्त site पर cron की लागत किस visitor से शुरू हुई

हर uncached request इस check की लागत चुकाती है। WordPress cron option load करता है, timestamps की तुलना करता है, और जब कोई कार्य due होता है तो spawn_cron() call करता है। यह /wp-cron.php को non-blocking loopback request भेजता है। Visitor result का इंतजार नहीं करता। PHP worker करता है। pm.max_children = 5 के साथ PHP-FPM चलाने वाले छोटे VPS पर एक slow scheduled job आपकी PHP capacity का पांचवां हिस्सा उतनी देर तक रोक सकता है, जितनी देर वह job चलती है। इसके trigger होने की सबसे अधिक संभावना आपके सबसे व्यस्त minute में होती है, क्योंकि उसी समय सबसे अधिक page loads होते हैं।

WordPress duplicates को सीमित करता है। यह ऐसा lock लेता है जिसकी lifetime WP_CRON_LOCK_TIMEOUT होती है, और default रूप से 60 seconds होती है। इसलिए एक ही समय पर आने वाले visitors प्रत्येक अलग run शुरू नहीं करते। यह lock duplication को सीमित करता है। यह work को request path से बाहर नहीं ले जाता।

यह तय करने से पहले कि इसका प्रभाव महत्वपूर्ण है, अपने server पर जाँचें कि यह कितनी बार fire होता है। प्रत्येक loopback web server access log में दिखाई देता है:

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

Apache इसके बजाय /var/log/apache2/access.log में लिखता है। हर दिन thousands में count होना वास्तविक cost है। ऐसे number को किसी article में पढ़ने के बजाय अपने server पर measure करना चाहिए। यह उसी तरह है जैसे किसी अन्य change से पहले और बाद में VPS का benchmark लें।

Caching से स्थिति बदल जाती है। यदि page cache अधिकांश requests को static HTML के रूप में serve करता है, तो उन requests के लिए PHP कभी नहीं चलता। इसलिए cron check भी नहीं होता। बहुत अधिक cached busy site नीचे दिए गए quiet site जैसी व्यवहार करने लगती है।

शांत site पर cron को किस visitor ने trigger किया

कोई visitor नहीं, तो cron भी नहीं। जिस site पर प्रतिदिन केवल कुछ visits आते हैं, उसके scheduled jobs भी उतनी ही बार चलते हैं, और उन visits के आने के random समय पर चलते हैं।

लक्षण हमेशा एक जैसे होते हैं। 09:00 के लिए scheduled post, posts list में Missed schedule के रूप में तब तक रहता है, जब तक कोई page load नहीं करता। Backup plugins रात में अपना काम छोड़ देते हैं। Update checks देर से चलते हैं, इसलिए security release जारी हो जाने के बाद भी dashboard में update करने के लिए कुछ दिखाई नहीं देता। Order emails, renewal notices और expiry warnings देर से भेजे जाते हैं।

इनमें से किसी का भी log में error नहीं आता। WordPress के अनुसार job देर से नहीं चला, क्योंकि वह शुरू ही नहीं हुआ था।

चरण 1: wp-config.php में visitor trigger बंद करें

/srv/www/example.com/wp-config.php खोलें और यह constant जोड़ें:

define( 'DISABLE_WP_CRON', true );

इसे /* That's all, stop editing! Happy publishing. */ वाली पंक्ति के ऊपर रखें, क्योंकि उस comment के ठीक नीचे वाली पंक्ति में wp-settings.php आवश्यक है, और wp-settings.php वह स्थान है जहाँ WordPress cron check को init पर hook करता है। उस require के बाद define किया गया constant बहुत देर से set होता है और कोई प्रभाव नहीं डालता। फ़ाइल सही दिखती रहती है, लेकिन trigger चलता रहता है।

पुष्टि करें कि पंक्ति सही स्थान पर है:

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

यह constant scheduled events को बंद नहीं करता। Plugins पहले की तरह queue में jobs जोड़ते रहते हैं। यह केवल page loads को उस queue को चलाने से रोकता है। इसलिए step 3 पूरा करने तक queue कभी नहीं चलेगी।

यह /wp-cron.php पर direct requests को भी block नहीं करता। कोई भी उस URL का request कर सकता है। आम तौर पर यह harmless होता है, क्योंकि फ़ाइल केवल due jobs चलाती है। इसे अपने web server config में block करना optional है। यदि आप इसे block करते हैं, तो इस guide के अंत में दिया गया curl fallback भी काम करना बंद कर देगा।

चरण 2: WP-CLI install करें

WP-CLI WordPress के लिए आधिकारिक command line tool है। इसके लिए PHP command line binary आवश्यक है। यह web server के PHP module से अलग package होता है।

php -v
sudo apt install -y php-cli

WP-CLI को phar build से install करें। आधिकारिक install guide में इसी तरीके की सिफारिश की गई है:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

php wp-cli.phar --info PHP binary path, PHP version और WP-CLI version दिखाता है। यदि तीनों दिखाई दें, तो phar सही तरीके से काम कर रहा है। August 2026 तक install guide में PHP 7.2.24 को न्यूनतम version बताया गया है। Ubuntu 24.04 में PHP 8.3 मिलता है, इसलिए current server इस आवश्यकता से काफी ऊपर है। बाद में sudo wp cli update से update करें।

WP-CLI को site के user के रूप में चलाएँ। इसे कभी भी root के रूप में न चलाएँ:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

root के रूप में WP-CLI start होने से इनकार करता है:

Error: YIKES! It looks like you're running this as root.

यह --allow-root का सुझाव देता है। यहाँ इसका उपयोग न करें। इसका कारण नीचे दिए गए पहले failure mode में बताया गया है।

यह भी ध्यान दें कि sudo -u www-data -i काम नहीं करता, क्योंकि उस account का login shell /usr/sbin/nologin है और आपको This account is currently not available. मिलता है। Command को सीधे sudo -u को देने पर login shell bypass हो जाता है, इसलिए यह सही तरीके से चलता है।

अब पुष्टि करें कि WordPress स्वयं step 1 में जोड़े गए constant को देख रहा है:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

इससे bool(true) दिखाई देता है। undefined constant के बारे में fatal error का अर्थ है कि define() वाली line तक execution नहीं पहुँच रहा। आम तौर पर इसका कारण यह होता है कि वह line require के नीचे चली गई है।

चरण 3: सही user के रूप में cron entry जोड़ें

सही user वह है जिसके पास PHP द्वारा लिखी जाने वाली files का ownership है। दोनों ओर जाँच करें:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

Default Ubuntu install में दोनों का उत्तर www-data होता है। यदि आपने site के लिए अपने user वाला अलग PHP-FPM pool दिया है, जैसा कि Ubuntu 24.04 पर LAMP stack में per-site setup के लिए सामान्यतः होता है, तो नीचे दिए गए सभी कामों के लिए उसी user का उपयोग करें।

ऐसी log directory बनाएँ जिसमें वह user लिख सके:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

उस user का crontab संपादित करें:

sudo crontab -u www-data -e

एक line जोड़ें:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

इसे भागों में समझें। */5 इसे हर पाँच मिनट में चलाता है। flock -n एक lock file लेता है और यदि पिछला run अभी भी lock रखता है तो तुरंत रुक जाता है। /usr/local/bin/wp absolute path है, जिसकी cron को आवश्यकता होती है। --path command को किसी भी working directory से चलने देता है। --due-now केवल उन events को चलाता है जिनका समय आ चुका है, queue में मौजूद हर event को नहीं। Redirect सामान्य output और errors को एक ऐसी file में भेजता है जिसे आप पढ़ सकते हैं।

व्यवहार में यह redirect वैकल्पिक नहीं है। Cron job का output उसके user को mail करता है, अधिकांश VPS images में mail transfer agent installed नहीं होता, और फिर cron (CRON) info (No MTA installed, discarding output) log करके output को हटा देता है। File evidence सुरक्षित रखती है।

सुनिश्चित करें कि file save हो गई है:

sudo crontab -u www-data -l

कई sites के लिए, हर site के लिए एक line का उपयोग करें और minutes को अलग-अलग रखें, ताकि सभी एक साथ शुरू न हों:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

यदि आप इसे rotate नहीं करेंगे तो log हमेशा बढ़ती रहेगी। /etc/logrotate.d/wp-cron लिखें:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

बिना कुछ बदले यह जाँचें कि configuration parse हो रही है: sudo logrotate --debug /etc/logrotate.d/wp-cron.

चरण 4: पुष्टि करें कि scheduled events वास्तव में चले

सफलतापूर्वक save हुई crontab line से कुछ सिद्ध नहीं होता। सबसे आसान जाँच से शुरू करें और उस जाँच तक जाएँ जो वास्तव में स्थिति स्पष्ट करती है।

पहले यह देखें कि cron ने command शुरू की या नहीं। cron अपने unit के अंतर्गत journal में log लिखता है:

journalctl -u cron.service --since "15 min ago" | grep wp

सही entry इस तरह दिखती है। शुरुआत का timestamp और host name हटा दिया गया है:

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

इस line का अर्थ है कि cron ने आपकी command को www-data के रूप में शुरू किया। इससे यह पता नहीं चलता कि command सफल हुई या नहीं।

दूसरा, देखें कि WordPress ने कुछ execute किया या नहीं। log file पढ़ें:

sudo tail -n 20 /var/log/wp-cron/example.log

WP-CLI प्रत्येक event के लिए एक line और अंत में कुल संख्या print करता है:

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

Errors इसी file में लिखी जाती हैं। यही 2>&1 का उद्देश्य है। अधिकांश runs में कोई event due नहीं होगा और बहुत कम output लिखा जाएगा। इसलिए ऐसी run के बाद file पढ़ें, जिसके लिए आपको पता हो कि कोई काम pending था।

तीसरा, end-to-end पुष्टि करें। एक marker event schedule करें और देखें कि वह queue से हटता है:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

एक interval की प्रतीक्षा करें, फिर list command दोबारा चलाएँ। hook गायब हो जाएगा, क्योंकि one-off event चलने के बाद queue से हटा दिया जाता है। कोई plugin उस hook name पर callback register नहीं करता, इसलिए उसे चलाने से site पर कोई अन्य काम नहीं होगा। यदि दो intervals के बाद भी hook सूची में है, तो queue run नहीं हो रही है। पहली दो जाँचों से पता चलेगा कि समस्या cron में है या WP-CLI में।

इसके लिए wp cron test का उपयोग न करें। वह command यह जाँचती है कि visitor-triggered spawning काम करता है या नहीं। जब DISABLE_WP_CRON true होता है, तो उसमें error आता है। सही configuration वाले server पर यह error अपेक्षित output है, fault नहीं।

systemd timer का विकल्प

यदि server के बाकी scheduled tasks पहले से systemd services और timers के रूप में चल रहे हैं, तो WordPress को भी उसी व्यवस्था में रखें। इसके बाद हर run systemctl list-timers में दिखाई देगा, और output उस file के बजाय journal में जाएगा जिसे आपको rotate करना पड़ता।

/etc/systemd/system/wp-cron-example.service लिखें:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

फिर /etc/systemd/system/wp-cron-example.timer:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

systemd एक ही service की दो copies एक साथ नहीं चलाएगा, इसलिए इस version में flock की जरूरत नहीं है। Persistent=true machine बंद रहने के दौरान छूटे हुए run को पूरा कराता है, जो crontab entry नहीं कर सकती।

crontab या timer में से एक चुनें। एक ही site पर दोनों चलाने से queue दो बार process होगी। Email या order job के duplicate runs आपके customers को दिखाई देंगे।

cron job को root के रूप में क्यों नहीं चलना चाहिए

यह setup के विफल होने के तीन तरीकों में पहला है। Job को root की crontab में डालने पर WP-CLI कोई काम शुरू करने से पहले ही रुक जाता है:

Error: YIKES! It looks like you're running this as root.

Queue कभी नहीं चलती। यदि आपने output को redirect नहीं किया है, तो आपको यह message दिखाई नहीं देगा। खतरनाक समाधान में --allow-root जोड़ना शामिल है, क्योंकि उस run के दौरान plugin द्वारा लिखी गई हर file root की ownership में आ जाएगी। अगला web request www-data के रूप में चलता है, उन directories में write नहीं कर पाता, और site इस तरह के messages दिखाने लगती है:

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

Ownership ठीक करें। फिर job को स्थानांतरित करें:

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

Root की crontab और www-data की crontab अलग files हैं। इसलिए एक से line delete करने पर दूसरी प्रभावित नहीं होती। दोनों की जाँच करें:

sudo crontab -u root -l
sudo crontab -u www-data -l

Cron wp: not found क्यों रिपोर्ट करता है

यह दूसरी विफलता है। Cron user jobs के लिए बहुत छोटा PATH देता है: /usr/bin:/bin। WP-CLI, /usr/local/bin में install होता है, जो उस सूची में नहीं है। Job शुरू होती है, एक सेकंड के अंश में विफल हो जाती है और log में केवल एक पंक्ति रहती है:

/bin/sh: 1: wp: not found

अनुमान लगाने के बजाय स्वयं cron का environment देखें। अस्थायी रूप से यह पंक्ति जोड़ें:

*/5 * * * * env > /tmp/cron-env.txt 2>&1

एक interval के बाद /tmp/cron-env.txt पढ़ें और फिर वह पंक्ति हटा दें। उस file में मौजूद PATH= value ठीक वही होती है जो आपकी job को मिलती है।

इसके दो समाधान हैं। Step 3 की तरह absolute path /usr/local/bin/wp का उपयोग करें। या crontab के शीर्ष पर, सभी job lines से ऊपर, PATH एक बार set करें:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

यही समस्या एक स्तर नीचे भी होती है। wp phar की शुरुआत #!/usr/bin/env php से होती है, इसलिए shell को php भी ढूँढने में सक्षम होना चाहिए। यदि PHP, /usr/bin के बाहर मौजूद है, जो custom builds और control panel builds में होता है, तो आपको यह मिलता है:

/usr/bin/env: 'php': No such file or directory

ऐसी स्थिति में interpreter को स्पष्ट रूप से call करें, उदाहरण के लिए /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now।

एक मिनट का interval मूल समस्या को फिर क्यों पैदा करता है

यह तीसरी failure है। * * * * * पाँच मिनट से अधिक सुरक्षित लगता है, लेकिन व्यस्त site पर यह आपको फिर उसी स्थिति में पहुँचा देता है। यदि एक run पूरा होने में interval से अधिक समय लेता है, तो पहला run चल रहा होने पर ही अगला run शुरू हो जाता है। दस मिनट बाद दस PHP processes चल रहे होते हैं, और प्रत्येक process अपनी memory तथा अपना database connection रखता है।

सीधे देखें कि processes जमा तो नहीं हो रहे:

ps -eo etimes,user,args | grep '[c]ron event run'

etimes seconds में process की age है। एक line सामान्य है। आपके interval से काफी अधिक age वाली कई lines का अर्थ है कि runs एक-दूसरे पर चढ़ रहे हैं। छोटे VPS पर इसका परिणाम MySQL Too many connections error हो सकता है, या kernel memory वापस लेने के लिए PHP को बंद कर सकता है। इसकी पुष्टि sudo dmesg -T | grep -i 'killed process' से की जा सकती है।

WP-CLI event callbacks को सीधे चलाता है। वह wp-cron.php का अनुरोध नहीं करता। इसलिए duplicate spawns के विरुद्ध WordPress का 60 second lock यहाँ लागू नहीं होता। step 3 entry में flock -n अब overlap रोकता है। छोड़ा गया run design के अनुसार तुरंत और बिना किसी संदेश के exit हो जाता है।

Interval उस सबसे छोटे schedule के आधार पर चुनें जिस पर आप वास्तव में निर्भर हैं। पहले एक run का समय मापें:

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

पाँच मिनट एक उचित default है: 09:00 पर scheduled post 09:05 तक publish हो जाता है। जिस site पर कोई time-critical काम नहीं है, वहाँ पंद्रह मिनट पर्याप्त हैं। एक मिनट का interval केवल उन stores और queue driven plugins के लिए रखें जिन्हें वास्तव में इसकी आवश्यकता है, और तब ही जब आपको पता हो कि एक run कुछ seconds में पूरा हो जाता है।

यदि आप WP-CLI install नहीं कर सकते

कुछ hosts shell tools को block कर देते हैं। wp-cron.php को भेजा गया साधारण HTTP request उसी queue को चलाता है, लेकिन पूरे web stack के माध्यम से:

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

आपको स्पष्ट रूप से ये सुविधाएँ छोड़नी होंगी:

• Run web server और PHP-FPM के request timeouts से सीमित होता है, इसलिए लंबा job बीच में बंद हो सकता है।
• Certificate valid होना चाहिए, वरना curl SSL certificate problem के साथ रुक जाता है। इसलिए nginx पर Certbot के साथ renewals चालू रखें।
• Page caching को wp-cron.php cache नहीं करना चाहिए, वरना cron requests को cached response मिलता है और कुछ भी run नहीं होता।
• आपको प्रत्येक event का output नहीं मिलता। इसलिए job के run होने का एकमात्र प्रमाण उसका प्रभाव होता है।

सफलता की स्थिति में -sS curl को शांत रखता है और errors फिर भी print करता है। cron job में यही व्यवहार चाहिए।

सर्वर के शेड्यूल में और क्या शामिल होना चाहिए

जब system cron WordPress queue को संभालने लगे, तो server के बाकी नियमित कार्य भी उसी स्थान पर रखें, जहाँ आप उन्हें देख सकें। Operating system security patches के लिए आपके द्वारा manually maintain की जाने वाली cron line के बजाय unattended upgrades का उपयोग करें। WordPress plugin और theme updates का निर्णय अलग होता है: crontab में wp plugin update --all बिना किसी निगरानी के रात 3 बजे live site को आसानी से खराब कर सकता है। इसलिए इन्हें सोच-समझकर चलाएँ, या staging step और backup के बाद चलाएँ।

FAQ

क्या WP-Cron को disable करने से scheduled posts publish होना रुक जाता है?

नहीं, जब तक queue चलाने के लिए कोई दूसरी प्रक्रिया मौजूद है। DISABLE_WP_CRON केवल page loads से queue trigger होने की प्रक्रिया रोकता है। Events पहले की तरह ही schedule रहते हैं। 09:00 के लिए set किया गया post, 09:00 के बाद होने वाले पहले cron run पर publish होगा। इसलिए five minute interval होने पर वह 09:05 तक publish हो जाएगा। यदि आप constant set कर दें और cron entry कभी add न करें, तो post list में Missed schedule के रूप में marked रह जाएगा, जब तक कोई queue न चलाए।

WordPress cron job किस user को चलाना चाहिए?

उस user को जिसके पास PHP द्वारा लिखी जाने वाली files का ownership है। Default Ubuntu install में यह www-data होता है। stat -c '%U %G' /srv/www/example.com/wp-content/uploads से जाँच करें और अपने PHP-FPM pool config की user = line से इसकी तुलना करें। Job को root के रूप में चलाने पर WP-CLI YIKES error के साथ रुक जाता है। --allow-root के माध्यम से इसे जबरन चलाने पर wp-content के अंदर root owned files बन जाती हैं, जिन्हें web server बाद में लिख नहीं सकता।

system cron को WordPress cron कितनी बार चलाना चाहिए?

अधिकांश sites के लिए हर five minutes पर्याप्त है। Interval को उस सबसे छोटे schedule के अनुरूप रखें जिस पर आप वास्तव में निर्भर हैं। यह interval एक run में लगने वाले समय से पर्याप्त अधिक होना चाहिए। इस समय को WP-CLI command के आगे time लगाकर मापा जा सकता है। Busy site पर one minute intervals runs को एक-दूसरे के ऊपर stack कर सकते हैं, जब तक flock उन्हें नियंत्रित न करे।

WP-Cron disable करने के बाद wp cron test क्यों fail होता है?

क्योंकि वह command visitor triggered spawning की जाँच करता है। DISABLE_WP_CRON को true पर set करने पर वह error report करता है। इस तरह configured server पर यही सही परिणाम है। इसके बजाय system cron path की जाँच करें। /var/log/wp-cron/example.log पढ़ें, या wp cron event schedule से एक marker event schedule करें और अगले run के बाद पुष्टि करें कि वह wp cron event list से हट गया है।

क्या मुझे WP-CLI की आवश्यकता है, या wp-cron.php के लिए curl पर्याप्त है?

Curl काम करता है और जब आप WP-CLI install नहीं कर सकते, तब यह सही विकल्प है। यह धीमा है, क्योंकि यह web server के माध्यम से WordPress load करता है। यह request timeout से भी सीमित रहता है। WP-CLI events को बिना web timeout के command line PHP process में चलाता है। यह प्रत्येक event के लिए उसकी duration सहित एक line print करता है। इसलिए log से स्पष्ट पता चलता है कि कौन-सा event चला और उसे कितना समय लगा।