WordPress में WP-Cron को System Cron से कैसे बदलें

wp-cron क्या है, और system cron इसे क्यों बदलता है

WP-Cron, WordPress में इनबिल्ट टास्क शेड्यूलर है, जो केवल तब चलता है जब कोई किसी पेज का अनुरोध (request) करता है। WordPress के भीतर कोई भी प्रक्रिया अपने आप शुरू नहीं होती है। हर उस अनुरोध पर जो कैश से सर्व नहीं होता, WordPress निर्धारित कार्यों (scheduled jobs) की सूची पढ़ता है। यदि कोई कार्य समय पर है, तो वह /wp-cron.php पर खुद को एक दूसरा HTTP अनुरोध भेजकर उस कार्य को पूरा करता है। उस कार्य को system cron पर ले जाने से आपको एक निश्चित समय-सारणी पर एक अनुमानित रन मिलता है, चाहे उस मिनट में साइट पर हजार विज़िटर आए हों या कोई भी न आया हो।

दो लाइनें वास्तविक कार्य करती हैं: wp-config.php में एक constant, और एक crontab entry। इस गाइड में बाकी सब कुछ वह हिस्सा है जो वे दो लाइनें नहीं बताती हैं। कार्य किस user के रूप में चलना चाहिए, निर्धारित इवेंट्स वास्तव में चले हैं या नहीं यह कैसे सिद्ध करें, और वे तीन तरीके जिनसे यह सेटअप बिना साइट पर कुछ भी प्रिंट किए विफल हो जाता है।

उदाहरण /srv/www/example.com को WordPress डायरेक्टरी के रूप में और www-data को वेब सर्वर user के रूप में उपयोग करते हैं। हर जगह अपने स्वयं के paths और user को बदलें।

व्यस्त साइट पर कौन सा विज़िटर cron costs को ट्रिगर करता है

प्रत्येक uncached request चेक के लिए भुगतान करती है। WordPress cron विकल्प को लोड करता है, timestamps की तुलना करता है, और जब कुछ देय होता है तो यह spawn_cron() को कॉल करता है, जो /wp-cron.php पर एक non-blocking loopback request भेजता है। विज़िटर परिणाम की प्रतीक्षा नहीं करता है। एक PHP worker प्रतीक्षा करता है। pm.max_children = 5 के साथ PHP-FPM चलाने वाले एक छोटे VPS पर, एक धीमा scheduled job आपकी PHP क्षमता का पांचवां हिस्सा उतने समय के लिए रोक लेता है जितना उसे लगता है, और इसके आपके सबसे व्यस्त मिनट के दौरान ट्रिगर होने की सबसे अधिक संभावना होती है, क्योंकि तभी सबसे अधिक page loads होते हैं।

WordPress डुप्लिकेट को सीमित करता है। यह एक lock लेता है जिसका lifetime WP_CRON_LOCK_TIMEOUT है, जो डिफ़ॉल्ट रूप से 60 सेकंड है, इसलिए एक साथ आने वाले विज़िटर प्रत्येक एक रन शुरू नहीं करते हैं। lock डुप्लिकेशन को सीमित करता है। यह काम को request path से बाहर नहीं ले जाता है।

यह तय करने से पहले कि यह मायने रखता है, अपने सर्वर पर गिनें कि यह कितनी बार फायर होता है। प्रत्येक loopback वेब सर्वर access log में दिखाई देता है:

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

Apache इसके बजाय /var/log/apache2/access.log में लिखता है। प्रति दिन हजारों की संख्या एक वास्तविक लागत है, और यह उस तरह की संख्या है जिसे आपको किसी लेख में पढ़ने के बजाय अपने स्वयं के बॉक्स पर मापना चाहिए, ठीक उसी तरह जैसे आप किसी अन्य बदलाव से पहले और बाद में benchmark a VPS करेंगे।

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

जब visitor न होने पर cron एक शांत साइट पर काम करना बंद कर देता है

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

इसके लक्षण हमेशा एक जैसे होते हैं। सुबह 09:00 बजे के लिए scheduled कोई पोस्ट तब तक पोस्ट्स की सूची में Missed schedule के रूप में चिह्नित रहती है जब तक कि कोई पेज लोड न करे। बैकअप प्लगइन्स रात का काम छोड़ देते हैं। अपडेट चेक में देरी होती है, इसलिए डैशबोर्ड पर कोई अपडेट नहीं दिखता, जबकि सुरक्षा संबंधी release पहले ही आ चुका होता है। ऑर्डर ईमेल, नवीनीकरण (renewal) नोटिस और समाप्ति (expiry) की चेतावनियां देर से भेजी जाती हैं।

इनमें से किसी भी स्थिति में कोई 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. */ वाली लाइन के ऊपर रखें, क्योंकि उस टिप्पणी के ठीक नीचे वाली लाइन को wp-settings.php की आवश्यकता होती है, और wp-settings.php वह स्थान है जहाँ WordPress cron check को init पर हुक करता है। उस require के बाद परिभाषित किया गया constant बहुत देर से सेट होता है और कोई बदलाव नहीं कर पाता, जिससे फाइल सही दिखती है लेकिन trigger चलता रहता है।

सुनिश्चित करें कि लाइन वहीं है जहाँ आप उसे समझ रहे हैं:

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

यह constant इवेंट्स को schedule होने से नहीं रोकता है। Plugins पहले की तरह ही queue में jobs जोड़ते रहते हैं। यह केवल page loads को उस queue को चलाने से रोकता है, जिसका अर्थ है कि जब तक आप चरण 3 पूरा नहीं करते, तब तक queue कभी नहीं चलेगी।

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

चरण 2: WP-CLI इंस्टॉल करें

WP-CLI, WordPress के लिए आधिकारिक कमांड लाइन टूल है। इसे PHP कमांड लाइन बाइनरी की आवश्यकता होती है, जो वेब सर्वर के PHP मॉड्यूल से एक अलग पैकेज है।

php -v
sudo apt install -y php-cli

WP-CLI को phar बिल्ड से इंस्टॉल करें, जैसा कि आधिकारिक इंस्टॉलेशन गाइड में अनुशंसित है:

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 बाइनरी पाथ, PHP वर्ज़न और WP-CLI वर्ज़न को प्रिंट करता है। यदि यह तीनों को प्रिंट करता है, तो phar सही ढंग से काम कर रहा है। अगस्त 2026 तक, इंस्टॉलेशन गाइड न्यूनतम आवश्यकता के रूप में PHP 7.2.24 बताती है, और Ubuntu 24.04 में PHP 8.3 आता है, इसलिए एक वर्तमान सर्वर इस सीमा से काफी ऊपर है। बाद में sudo wp cli update के साथ अपडेट करें।

WP-CLI को साइट के यूजर के रूप में चलाएं, कभी भी root के रूप में नहीं:

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

root के रूप में, WP-CLI शुरू होने से मना कर देता है:

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

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

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

अब पुष्टि करें कि WordPress स्वयं चरण 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() लाइन तक नहीं पहुँचा जा रहा है, जिसका आमतौर पर मतलब है कि यह require के नीचे स्थित है।

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

सही user वह है जिसके पास PHP द्वारा लिखी जाने वाली फाइलों का स्वामित्व (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

डिफ़ॉल्ट Ubuntu इंस्टॉलेशन में दोनों का उत्तर www-data होता है। यदि आपने साइट को अपना PHP-FPM pool और अपना user दिया है, जो कि Ubuntu 24.04 पर LAMP stack सेटअप में सामान्यतः होता है, तो नीचे दिए गए सभी कार्यों के लिए उसी 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

एक पंक्ति जोड़ें:

*/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 का उपयोग करता है और यदि पिछला रन अभी भी चल रहा हो, तो यह तुरंत रुक जाता है। /usr/local/bin/wp पूर्ण पथ (absolute path) है, जिसकी cron को आवश्यकता होती है। --path कमांड को किसी भी वर्किंग डायरेक्टरी से चलने की अनुमति देता है। --due-now केवल उन events को चलाता है जिनका समय आ गया है, न कि queue के हर event को। रीडायरेक्ट सामान्य आउटपुट और त्रुटियों को एक ऐसी फाइल में भेजता है जिसे आप पढ़ सकते हैं।

व्यावहारिक रूप से वह रीडायरेक्ट वैकल्पिक नहीं है। Cron किसी जॉब के आउटपुट को उसके user को मेल करता है, अधिकांश VPS इमेज में कोई mail transfer agent इंस्टॉल नहीं होता है, और फिर cron (CRON) info (No MTA installed, discarding output) लॉग करता है और आउटपुट को हटा देता है। एक फाइल सबूत को सुरक्षित रखती है।

जाँचें कि फाइल सेव हो गई है:

sudo crontab -u www-data -l

कई साइटों के लिए, प्रत्येक के लिए अलग-अलग मिनटों के साथ एक-एक पंक्ति का उपयोग करें ताकि वे सभी एक साथ शुरू न हों:

*/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 नहीं करते। /etc/logrotate.d/wp-cron लिखें:

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

जाँचें कि यह बिना किसी बदलाव के पार्स (parse) होता है: sudo logrotate --debug /etc/logrotate.d/wp-cron।

चरण 4: पुष्टि करें कि निर्धारित इवेंट वास्तव में ट्रिगर हुए

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

सबसे पहले, क्या cron ने कमांड शुरू की? Cron अपने स्वयं के यूनिट के अंतर्गत journal में लॉग करता है:

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

एक सही एंट्री ऐसी दिखती है, जिसमें शुरुआत से टाइमस्टैम्प और होस्ट नाम हटा दिया गया है:

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)

उस लाइन का मतलब है कि cron ने आपकी कमांड को www-data के रूप में शुरू किया। यह इस बारे में कुछ नहीं कहती कि कमांड ने काम किया या नहीं।

दूसरा, क्या WordPress ने कुछ निष्पादित किया? लॉग फ़ाइल पढ़ें:

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

WP-CLI प्रति इवेंट एक लाइन प्रिंट करता है, और फिर कुल योग:

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

त्रुटियां उसी फ़ाइल में दर्ज होती हैं, जो 2>&1 का मुख्य उद्देश्य है। अधिकांश रन में कोई कार्य लंबित नहीं होगा और वे बहुत कम लिखेंगे, इसलिए उस रन के बाद फ़ाइल को पढ़ें जिसके बारे में आप जानते हैं कि उसमें कार्य लंबित था।

तीसरा, एंड-टू-एंड पुष्टि करें। एक मार्कर इवेंट शेड्यूल करें और देखें कि वह गायब होता है या नहीं:

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

एक अंतराल तक प्रतीक्षा करें, फिर लिस्ट कमांड को दोबारा चलाएं। हुक गायब हो जाएगा, क्योंकि एक बार चलने वाला इवेंट चलने के बाद कतार (queue) से हटा दिया जाता है। कोई भी प्लगइन उस हुक नाम पर कॉलबैक रजिस्टर नहीं करता है, इसलिए इसे चलाने से साइट पर कोई अन्य प्रभाव नहीं पड़ता है। यदि दो अंतराल के बाद भी हुक लिस्ट में है, तो कतार नहीं चल रही है, और पहली दो जांचें आपको बता देंगी कि समस्या cron के साथ है या WP-CLI के साथ।

इसके लिए wp cron test का उपयोग न करें। वह कमांड जांचती है कि क्या विज़िटर-ट्रिगर स्पॉनिंग काम कर रही है, और जब DISABLE_WP_CRON true होता है तो यह त्रुटि देती है। सही ढंग से कॉन्फ़िगर किए गए सर्वर पर त्रुटि अपेक्षित आउटपुट है, न कि कोई खराबी।

systemd timer का विकल्प

यदि सर्वर के अन्य निर्धारित कार्य पहले से ही systemd services and timers के रूप में चल रहे हैं, तो WordPress को भी वहीं रखें। प्रत्येक रन systemctl list-timers में दिखाई देगा, और आउटपुट किसी ऐसी फाइल के बजाय 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 की दो प्रतियां एक साथ नहीं चलाएगा, इसलिए इस संस्करण में flock की आवश्यकता नहीं है। Persistent=true यह सुनिश्चित करता है कि यदि मशीन बंद होने के कारण कोई रन छूट गया है, तो यह उसे पूरा कर ले, जो crontab entry नहीं कर सकती।

Crontab या timer में से किसी एक को चुनें। एक ही साइट पर दोनों को चलाने का अर्थ है कि queue दो बार खाली की जा रही है, और ईमेल या ऑर्डर जॉब के डुप्लिकेट रन आपके ग्राहकों को दिखाई देंगे।

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

यह सेटअप के विफल होने के तीन तरीकों में से पहला है। यदि आप job को root के crontab में डालते हैं, तो WP-CLI कोई भी कार्य करने से पहले रुक जाता है:

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

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

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 अलग-अलग फ़ाइलें हैं, इसलिए एक से line हटाने पर दूसरी पर कोई प्रभाव नहीं पड़ता है। दोनों की जाँच करें:

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

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

यह दूसरी विफलता है। Cron उपयोगकर्ता के 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= मान वही है जो आपके job को मिलता है।

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

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।

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

यह तीसरी विफलता है। * * * * * पांच मिनट की तुलना में सुरक्षित लगता है, लेकिन एक व्यस्त साइट पर यह आपको वापस वहीं ले आता है जहाँ से आपने शुरुआत की थी। यदि एक रन अंतराल से अधिक समय लेता है, तो पहला रन चलते रहने के दौरान ही अगला रन शुरू हो जाता है। दस मिनट बाद दस PHP processes होती हैं, जिनमें से प्रत्येक अपनी मेमोरी और अपना डेटाबेस कनेक्शन रखती है।

सीधे pileup की जाँच करें:

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

etimes सेकंड में process की आयु है। एक पंक्ति का होना सामान्य है। आपके अंतराल से काफी अधिक आयु वाली कई पंक्तियाँ यह दर्शाती हैं कि रन एक-दूसरे के ऊपर जमा हो रहे हैं, और एक छोटे VPS पर यह MySQL Too many connections त्रुटि के रूप में समाप्त होता है, या kernel द्वारा मेमोरी वापस पाने के लिए PHP को kill करने के रूप में, जिसकी पुष्टि आप sudo dmesg -T | grep -i 'killed process' के साथ कर सकते हैं।

WP-CLI सीधे event callbacks को चलाता है, न कि wp-cron.php का अनुरोध करता है, इसलिए WordPress द्वारा duplicate spawns के खिलाफ उपयोग किया जाने वाला 60 सेकंड का lock यहाँ लागू नहीं होता है। चरण 3 की प्रविष्टि में flock -n ही वह है जो अब overlap को रोकता है। एक skipped run डिज़ाइन के अनुसार तुरंत और चुपचाप exit हो जाता है। Overlap एक ऐसी समस्या है जिसे आपको crontab में हल करना होगा, न कि जिसे host kernel आपके लिए हल करेगा: यहाँ तक कि Linux kernel 7.2 में जोड़ा गया cache aware task placement भी केवल यह तय करता है कि एक process किस core पर जाएगी, यह कभी नहीं कि आपने उनमें से कितनी शुरू की हैं।

उस अंतराल को चुनें जिस पर आप वास्तव में निर्भर हैं, और पहले एक रन को मापें:

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

पांच मिनट एक उचित डिफ़ॉल्ट है: 09:00 बजे के लिए निर्धारित पोस्ट 09:05 तक प्रकाशित हो जाती है। पंद्रह मिनट ऐसी साइट के लिए ठीक है जिस पर समय के प्रति संवेदनशील कुछ भी न हो। एक मिनट उन स्टोर और queue आधारित plugins के लिए है जिन्हें वास्तव में इसकी आवश्यकता होती है, और केवल तभी जब आप जानते हों कि एक रन कुछ ही सेकंड में पूरा हो जाता है।

यदि आप WP-CLI इंस्टॉल नहीं कर सकते हैं

कुछ होस्ट शेल टूल्स को ब्लॉक कर देते हैं। wp-cron.php पर एक साधारण HTTP अनुरोध उसी कतार (queue) को चलाता है, बस यह पूरे वेब स्टैक के माध्यम से होता है:

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

आप स्पष्ट रूप से क्या खो देते हैं:

• यह रन वेब सर्वर और PHP-FPM अनुरोध टाइमआउट द्वारा सीमित होता है, इसलिए एक लंबा कार्य बीच में ही कट सकता है।
• सर्टिफिकेट वैध होना चाहिए अन्यथा curl, SSL certificate problem के साथ रुक जाता है, इसलिए Certbot on nginx के साथ नवीनीकरण (renewals) को चालू रखें।
• पेज कैशिंग को wp-cron.php को कैश नहीं करना चाहिए, अन्यथा क्रॉन अनुरोधों को एक कैश किया गया रिस्पॉन्स मिलता है और कुछ भी रन नहीं होता है।
• आपको प्रति इवेंट कोई आउटपुट नहीं मिलता है, इसलिए कार्य चलने का एकमात्र प्रमाण वह प्रभाव है जो उसने डाला है।

-sS सफलता पर curl को शांत रखता है जबकि त्रुटियों को प्रिंट करता रहता है, जो कि आप एक क्रॉन जॉब में चाहते हैं।

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

एक बार जब system cron के पास WordPress queue का नियंत्रण आ जाता है, तो सर्वर के बाकी नियमित कार्यों को भी उसी स्थान पर रखें, जहाँ आप उन्हें देख सकें। ऑपरेटिंग सिस्टम के security patches को हाथ से 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 हो जाती है, इसलिए पांच मिनट के interval पर यह 09:05 तक publish हो जाएगी। यदि आप constant set करते हैं और cron entry नहीं जोड़ते हैं, तो post तब तक सूची में Missed schedule के रूप में चिह्नित रहेगी जब तक कि कोई queue को run न कर दे।

WordPress cron job किस user द्वारा run की जानी चाहिए?

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

System cron को WordPress cron कितनी बार run करना चाहिए?

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

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

क्योंकि वह command visitor द्वारा trigger किए गए spawning का परीक्षण करती है, और जब DISABLE_WP_CRON को true पर set किया जाता है तो वह error report करती है। इस तरह configure किए गए 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 में run करता है, और प्रत्येक event के लिए उसकी अवधि के साथ एक line print करता है, इसलिए log आपको ठीक-ठीक बताता है कि क्या run हुआ और उसमें कितना समय लगा।