WP-Cron बंद करून system cron कसे वापरावे

WP-Cron म्हणजे काय आणि system cron त्याची जागा का घेतो

WP-Cron हा WordPress मध्ये समाविष्ट असलेला task scheduler आहे. तो एखाद्याने page request केल्यावरच चालतो. WordPress मध्ये स्वतःहून कोणतीही प्रक्रिया सुरू होत नाही. Cache मधून दिली न गेलेली प्रत्येक request आल्यावर WordPress scheduled jobs ची यादी वाचतो. त्यापैकी एखादे job due असल्यास, काम करण्यासाठी तो /wp-cron.php येथे स्वतःकडे दुसरी HTTP request पाठवतो. हे काम system cron कडे सोपवल्यास ठरावीक schedule नुसार एक predictable run मिळतो. त्या मिनिटाला site वर एक हजार visitors असोत किंवा एकही नसोत, run होतो.

प्रत्यक्ष काम दोन ओळी करतात: wp-config.php मधील एक constant आणि crontab entry. या मार्गदर्शकातील इतर सर्व माहिती त्या दोन ओळींमधून समजत नाही. Job कोणत्या user म्हणून चालवायचे, scheduled events खरोखर चालले हे कसे सिद्ध करायचे आणि site वर काहीही न छापता setup कोणत्या तीन प्रकारे fail होऊ शकतो, हे त्यात समाविष्ट आहे.

उदाहरणांमध्ये WordPress directory म्हणून /srv/www/example.com आणि web server user म्हणून www-data वापरले आहे. सर्व ठिकाणी तुमचे स्वतःचे paths आणि user वापरा.

व्यस्त साइटवरील कोणत्या अभ्यागतामुळे cron चा खर्च वाढतो

प्रत्येक cache नसलेल्या विनंतीसाठी ही तपासणी करावी लागते. WordPress cron पर्याय लोड करते, timestamp ची तुलना करते आणि एखादे काम due असल्यास spawn_cron() कॉल करते. हे /wp-cron.php कडे non-blocking loopback विनंती पाठवते. परिणामासाठी अभ्यागत थांबत नाही. मात्र PHP worker थांबतो. pm.max_children = 5 सह PHP-FPM चालणाऱ्या छोट्या VPS वर एक संथ scheduled job तुमच्या PHP क्षमतेचा पाचवा भाग पूर्ण होईपर्यंत व्यापून ठेवतो. हे काम सर्वाधिक व्यस्त मिनिटात सुरू होण्याची शक्यता असते, कारण त्या वेळी सर्वाधिक page loads होतात.

WordPress duplicate runs मर्यादित करते. ते WP_CRON_LOCK_TIMEOUT इतक्या कालावधीसाठी lock घेते. Default कालावधी 60 seconds आहे. त्यामुळे एकाच वेळी येणारे अभ्यागत प्रत्येक वेळी स्वतंत्र run सुरू करत नाहीत. हा lock duplicate runs ची संख्या मर्यादित करतो. मात्र तो हे काम request path मधून वेगळे करत नाही.

हे महत्त्वाचे आहे असे ठरवण्यापूर्वी तुमच्या स्वतःच्या server वर ते किती वेळा सुरू होते ते मोजा. प्रत्येक loopback विनंती web server access log मध्ये दिसते:

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

Apache त्याऐवजी /var/log/apache2/access.log मध्ये नोंद करते. दररोज हजारोंच्या संख्येने होणाऱ्या विनंत्या हा खरा खर्च आहे. इतर कोणताही बदल करण्यापूर्वी जसे तुम्ही VPS चे benchmark घ्याल, तसेच हा आकडा एखाद्या लेखातून वाचण्याऐवजी तुमच्या स्वतःच्या box वर मोजला पाहिजे.

Caching मुळे हे चित्र बदलते. Page cache बहुतेक विनंत्या static HTML म्हणून पुरवत असल्यास, त्या विनंत्यांसाठी PHP चालत नाही. त्यामुळे cron तपासणीही होत नाही. मोठ्या प्रमाणात cached असलेली व्यस्त साइट खालील शांत साइटसारखी वागू लागते.

शांत असलेल्या साइटवर कोणत्या visitor मुळे cron कार्ये बिघडतात

Visitor नसतील तर cron चालत नाही. दिवसाला मोजकेच visits मिळणारी साइट तिची scheduled jobs देखील दिवसाला तेवढ्याच मोजक्या वेळा चालवते. त्या visits ज्या अनियमित वेळी येतात, त्याच वेळी ही jobs सुरू होतात.

लक्षणे नेहमी सारखीच दिसतात. 09:00 साठी schedule केलेली post posts list मध्ये Missed schedule म्हणूनच राहते, जोपर्यंत कोणी page load करत नाही. Backup plugins रात्रीचे backup वगळतात. 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 तपासणीला init शी जोडतो. त्या require नंतर define केलेला constant काहीही बदलण्यासाठी खूप उशिरा सेट होतो. त्यामुळे फाइल योग्य दिसते, पण trigger सुरूच राहतो.

ओळ अपेक्षित ठिकाणी आहे याची खात्री करा:

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

हा constant events schedule होणे थांबवत नाही. Plugins पूर्वीप्रमाणेच queue मध्ये jobs जोडत राहतात. तो फक्त page loads कडून ती queue चालवणे थांबवतो. त्यामुळे पायरी 3 पूर्ण होईपर्यंत queue अजिबात चालणार नाही.

हा constant /wp-cron.php कडे होणाऱ्या थेट requests देखील थांबवत नाही. कोणीही त्या URL साठी request करू शकतो. हे सहसा harmless असते, कारण फाइल फक्त due असलेले काम चालवते. Web server config मध्ये ते block करणे optional आहे. तुम्ही ते block केल्यास, या मार्गदर्शकाच्या शेवटाजवळील curl fallback देखील काम करणार नाही.

पायरी 2: WP-CLI स्थापित करा

WP-CLI हे WordPress साठीचे अधिकृत command line tool आहे. यासाठी PHP command line binary आवश्यक आहे. हे web server च्या PHP module पेक्षा वेगळे package आहे.

php -v
sudo apt install -y php-cli

अधिकृत install guide मध्ये शिफारस केलेल्या phar build मधून WP-CLI स्थापित करा:

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 समाविष्ट आहे. त्यामुळे सध्याचा server या किमान मर्यादेपेक्षा बऱ्याच पुढे आहे. नंतर sudo wp cli update वापरून update करा.

WP-CLI साइटच्या user म्हणून चालवा. 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 कार्य करत नाही. कारण त्या account चा login shell /usr/sbin/nologin आहे आणि तुम्हाला This account is currently not available. मिळते. Command थेट sudo -u कडे दिल्यास login shell वगळला जातो. त्यामुळे command व्यवस्थित चालते.

आता 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() ओळ गाठली जात नाही. सामान्यतः ती ओळ require नंतर लिहिली गेली असल्याने असे होते.

पायरी 3: योग्य वापरकर्ता म्हणून cron entry जोडा

योग्य वापरकर्ता म्हणजे PHP ज्या files मध्ये लिहिते त्या files चा मालक. दोन्ही बाजू तपासा:

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 साठी स्वतंत्र PHP-FPM pool आणि स्वतंत्र user दिला असेल, तर खालील सर्व कामांसाठी तोच user वापरा. Ubuntu 24.04 वरील LAMP stack मधील per-site setup साधारणपणे अशाच प्रकारे configured असतो.

त्या user ला लिहिता येईल अशी log directory तयार करा:

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

त्या user चा crontab edit करा:

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 हे प्रत्येक पाच मिनिटांनी command चालवते. flock -n lock file घेते आणि मागील run अजूनही lock धरून असेल, तर लगेच थांबते. /usr/local/bin/wp हा absolute path आहे, जो cron ला आवश्यक असतो. --path मुळे command कोणत्याही working directory मधून चालवता येते. --due-now queue मधील प्रत्येक event ऐवजी ज्यांची वेळ आलेली आहे तेच events चालवते. Redirect मुळे normal output आणि errors तुम्ही वाचू शकता अशा एका file मध्ये पाठवले जातात.

प्रत्यक्ष वापरात हा redirect optional नाही. Cron job चे output त्या user ला mail करते. बहुतेक VPS images मध्ये mail transfer agent installed नसतो. त्यामुळे cron (CRON) info (No MTA installed, discarding output) log करते आणि output टाकून देते. File मध्ये output ठेवल्यामुळे पुरावा उपलब्ध राहतो.

File save झाली आहे का ते तपासा:

sudo crontab -u www-data -l

अनेक sites असल्यास, प्रत्येक site साठी एक line वापरा आणि minutes मध्ये अंतर ठेवा, जेणेकरून सर्व jobs एकाच वेळी सुरू होणार नाहीत:

*/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

Log rotate न केल्यास तो कायम वाढत राहतो. /etc/logrotate.d/wp-cron लिहा:

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

काहीही बदल न करता syntax parse होते का ते तपासा: sudo logrotate --debug /etc/logrotate.d/wp-cron.

पायरी 4: नियोजित घटना प्रत्यक्षात चालल्या आहेत याची खात्री करा

crontab मधील ओळ यशस्वीरीत्या जतन झाली, यावरून काहीही सिद्ध होत नाही. सर्वात सोप्या तपासणीपासून प्रत्यक्ष निष्कर्ष देणाऱ्या तपासणीपर्यंत क्रमाने पुढे जा.

सर्वप्रथम, cron ने command सुरू केला का? cron स्वतःच्या unit अंतर्गत journal मध्ये logs लिहितो:

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

समोरील timestamp आणि host name काढल्यावर निरोगी entry अशी दिसते:

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 ने तुमचा command www-data म्हणून सुरू केला. command यशस्वी झाला का, हे त्यावरून कळत नाही.

दुसरे, WordPress ने काही execute केले का? log file वाचा:

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

WP-CLI प्रत्येक event साठी एक ओळ आणि शेवटी एकूण संख्या दाखवतो:

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 वाचा.

तिसरे, सुरुवातीपासून शेवटपर्यंत याची खात्री करा. marker event schedule करा आणि तो नाहीसा होतो का ते पाहा:

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 मधून काढला जातो. त्या hook name वर कोणताही plugin callback register करत नाही. त्यामुळे तो चालवल्यावर site वर इतर कोणताही परिणाम होत नाही. दोन intervals नंतरही hook सूचीमध्ये असल्यास queue चालवली जात नाही. पहिल्या दोन तपासण्यांमुळे समस्या cron मध्ये आहे की WP-CLI मध्ये, हे कळेल.

यासाठी wp cron test वापरू नका. हा command visitor triggered spawning कार्य करते का ते तपासतो. DISABLE_WP_CRON true असल्यास तो error देतो. योग्यरित्या configured server वर हा error अपेक्षित output आहे; तो fault नाही.

systemd timer चा पर्याय

जर या मशीनवरील इतर नियोजित कामे systemd services आणि timers द्वारे आधीच चालत असतील, तर WordPress देखील त्याच पद्धतीने चालवा. त्यामुळे प्रत्येक run systemctl list-timers मध्ये दिसतो आणि output फिरवण्यासाठी स्वतंत्र file ठेवण्याऐवजी journal मध्ये पाठवला जातो.

/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 ची गरज नाही. मशीन बंद असताना चुकलेला run Persistent=true नंतर systemd भरून काढतो. crontab entry हे करू शकत नाही.

crontab किंवा timer यापैकी एक निवडा. एकाच site साठी दोन्ही चालवल्यास queue दोनदा रिकामी केली जाते. त्यामुळे email किंवा order job चे duplicate runs ग्राहकांना दिसू शकतात.

cron job root म्हणून का चालवू नये

setup अयशस्वी होण्याच्या तीन पद्धतींपैकी ही पहिली पद्धत आहे. 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 मध्ये लिहिता येत नाही. मग site खालीलप्रमाणे संदेश दाखवू लागते:

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

मालकी दुरुस्त करा आणि नंतर job हलवा:

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

root चे crontab आणि www-data चे crontab स्वतंत्र files आहेत. त्यामुळे एका file मधून line हटवल्याने दुसऱ्या file वर परिणाम होत नाही. दोन्ही तपासा:

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 होते, परंतु तो path त्या यादीत नाही. 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 ला मिळणाऱ्या value शी तंतोतंत जुळते.

यासाठी दोन उपाय आहेत. step 3 प्रमाणे absolute path /usr/local/bin/wp वापरा. किंवा crontab च्या सुरुवातीला, प्रत्येक job line च्या वर एकदाच 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.

एका मिनिटांचा interval मूळ समस्या पुन्हा का निर्माण करतो

ही तिसरी चूक आहे. * * * * * हा पाच मिनिटांपेक्षा सुरक्षित वाटतो; परंतु व्यस्त साइटवर तो तुम्हाला पुन्हा सुरुवातीच्या स्थितीत नेतो. एखादा run interval पेक्षा जास्त वेळ घेत असेल, तर पहिला run सुरू असतानाच पुढचा run सुरू होतो. दहा मिनिटांनंतर दहा PHP processes असतात. प्रत्येक process स्वतःची memory आणि स्वतःचे database connection ठेवतो.

Process एकत्र साचले आहेत का ते थेट तपासा:

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

etimes हे process चे वय seconds मध्ये दाखवते. एक line असणे सामान्य आहे. तुमच्या interval पेक्षा बरेच जास्त age असलेल्या अनेक lines दिसत असतील, तर runs एकावर एक साचत आहेत. लहान VPS वर यामुळे MySQL Too many connections error येऊ शकतो किंवा memory परत मिळवण्यासाठी kernel PHP ला बंद करू शकतो. याची खात्री sudo dmesg -T | grep -i 'killed process' ने करता येते.

WP-CLI wp-cron.php ला विनंती करण्याऐवजी event callbacks थेट चालवते. त्यामुळे duplicate spawns रोखण्यासाठी WordPress वापरत असलेला 60 seconds चा lock येथे लागू होत नाही. आता overlap रोखणारे कारण step 3 मधील entry मधील flock -n आहे. वगळलेला run design नुसार लगेच आणि शांतपणे exit होतो.

तुम्ही प्रत्यक्षात अवलंबून असलेल्या सर्वात कमी schedule वरून interval निवडा आणि आधी एक run मोजा:

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

पाच मिनिटे हा योग्य default आहे: 09:00 साठी schedule केलेले post 09:05 पर्यंत publish होते. साइटवर वेळेवर अवलंबून असलेले काहीही नसल्यास पंधरा मिनिटे पुरेशी आहेत. एक मिनिटांचा interval stores आणि queue-driven plugins साठी योग्य आहे, ज्यांना खरोखर त्याची गरज आहे. मात्र run काही seconds मध्ये पूर्ण होतो याची खात्री झाल्यानंतरच तो वापरा.

WP-CLI इंस्टॉल करता येत नसल्यास

काही hosts shell tools ब्लॉक करतात. wp-cron.php कडे केलेली साधी HTTP request संपूर्ण web stack मधून जाते, पण त्याच queue वर प्रक्रिया करते:

*/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 वैध असणे आवश्यक आहे. अन्यथा curl थांबते आणि SSL certificate problem दाखवते. त्यामुळे nginx वरील Certbot वापरून renewals कार्यरत ठेवा.
• Page caching ने wp-cron.php cache करू नये. अन्यथा cron requests ला cached response मिळतो आणि काहीही चालत नाही.
• प्रत्येक event चे output मिळत नाही. त्यामुळे एखादे job चालले याचा एकमेव पुरावा म्हणजे त्याचा परिणाम.

यशस्वी run वेळी -sS curl चे output शांत ठेवते, पण errors दाखवत राहते. cron job साठी हेच अपेक्षित आहे.

सर्व्हरच्या वेळापत्रकात आणखी कोणती कामे असावीत

WordPress queue system cron कडे सोपवल्यानंतर, सर्व्हरवरील नियमित कामेही त्याच ठिकाणी ठेवा, जेणेकरून ती सर्व एकाच ठिकाणी पाहता येतील. ऑपरेटिंग सिस्टमचे security patches तुम्ही स्वतः सांभाळत असलेल्या cron line ऐवजी unattended upgrades कडे सोपवावेत. WordPress plugin आणि theme updates हा वेगळा निर्णय आहे: crontab मधील wp plugin update --all कोणाच्याही देखरेखीशिवाय पहाटे 3 वाजता live site बिघडवू शकते. त्यामुळे ही प्रक्रिया जाणीवपूर्वक चालवा किंवा staging step आणि backup नंतर चालवा.

FAQ

अनुसूचित पोस्ट प्रकाशित होणे थांबवण्यासाठी WP-Cron अक्षम करणे पुरेसे आहे का?

नाही, जोपर्यंत queue चालवण्यासाठी दुसरी व्यवस्था आहे. DISABLE_WP_CRON मुळे page loads कडून queue सुरू होणे एवढेच थांबते. Events पूर्वीप्रमाणेच schedule केलेले राहतात. 09:00 साठी निश्चित केलेली पोस्ट 09:00 नंतरच्या पहिल्या cron run वर प्रकाशित होते. त्यामुळे पाच मिनिटांच्या interval मध्ये ती 09:05 पर्यंत प्रकाशित होते. तुम्ही constant सेट करून cron entry जोडली नाही, तर काहीतरी queue चालवेपर्यंत पोस्ट Missed schedule म्हणून चिन्हांकित यादीत राहते.

WordPress cron job कोणत्या user ने चालवावी?

PHP ज्या user च्या मालकीच्या files मध्ये लिहिते, त्या user ने चालवावी. Default Ubuntu install मध्ये हा user 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 साठी प्रत्येक पाच मिनिटांनी चालवणे योग्य आहे. तुम्ही प्रत्यक्षात वापरत असलेल्या सर्वात कमी schedule interval शी ते जुळवा. एक run पूर्ण होण्यासाठी लागणाऱ्या वेळेपेक्षा हा interval पुरेसा मोठा ठेवा. time WP-CLI command च्या आधी ठेवून हा वेळ मोजता येतो. Busy site वर एक मिनिटांचे intervals एकमेकांवर runs सुरू करू शकतात, जोपर्यंत flock त्यांना नियंत्रित करत नाही.

WP-Cron अक्षम केल्यानंतर wp cron test का fail होते?

कारण हा command visitor-triggered spawning तपासतो. DISABLE_WP_CRON true वर सेट असल्यास तो error दाखवतो. अशा प्रकारे 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 command line PHP process मध्ये चालवते. त्यावर web timeout लागू होत नाही. ते प्रत्येक event साठी duration सह एक line दाखवते. त्यामुळे कोणते event चालले आणि त्याला किती वेळ लागला हे log मधून अचूक समजते.