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 पाठवतो. हे job system cron कडे हलवल्यास ठरावीक schedule नुसार एक predictable run मिळतो. त्या मिनिटाला site वर हजार visitors असोत किंवा एकही नसोत, त्याचा फरक पडत नाही.

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

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

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

प्रत्येक uncached request साठी ही तपासणी करण्याचा खर्च होतो. WordPress cron option लोड करते, 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 duplicate runs मर्यादित करते. ते WP_CRON_LOCK_TIMEOUT इतक्या कालावधीसाठी lock घेते; default म्हणून हा कालावधी 60 seconds आहे. त्यामुळे एकाच वेळी येणारे अभ्यागत प्रत्येकजण स्वतंत्र run सुरू करत नाहीत. हा lock duplication मर्यादित करतो. मात्र तो हे काम request path बाहेर हलवत नाही.

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

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

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

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

शांत साइटवर कोणत्या visitor मुळे cron सुरू होते

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

लक्षणे नेहमी सारखीच दिसतात. 09:00 वाजता प्रकाशित होण्यासाठी scheduled केलेली post कोणी page load करेपर्यंत posts list मध्ये Missed schedule अशीच राहते. Backup plugins रात्रीचे काम वगळतात. Update checks उशिरा होतात. त्यामुळे security release उपलब्ध झालेली असतानाही dashboard मध्ये update करण्यास काहीही दिसत नाही. Order emails, renewal notices आणि expiry warnings उशिरा पाठवले जातात.

यापैकी कोणतीही बाब error log मध्ये नोंदली जात नाही. 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 नंतर constant define केल्यास ते बदल करण्यासाठी खूप उशिरा सेट होते. त्यामुळे फाइल योग्य दिसत असली तरी 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 कधीही चालणार नाही.

यामुळे /wp-cron.php कडे केलेल्या direct requests देखील block होत नाहीत. कोणीही त्या URL साठी request करू शकते. हे सहसा harmless असते, कारण फाइल फक्त due असलेले jobs चालवते. तुमच्या web server configuration मध्ये ते block करणे optional आहे. तुम्ही ते block केल्यास, या guide च्या शेवटाजवळील 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 ही किमान आवृत्ती दिली आहे. Ubuntu 24.04 मध्ये PHP 8.3 समाविष्ट असल्याने सध्याचा 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 सुरू होण्यास नकार देते:

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() ही line पोहोचली जात नाही. साधारणपणे याचा अर्थ ती require च्या खाली गेली आहे.

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

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

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 साधारणपणे याच स्थितीत असतो.

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

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

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

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

sudo crontab -u www-data -l

अनेक sites असल्यास, प्रत्येकासाठी एक ओळ वापरा आणि 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

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 मध्ये चालवण्यासाठी काहीही due नसते आणि फारच थोडे output लिहिले जाते. त्यामुळे काम प्रलंबित असल्याची खात्री असलेल्या run नंतर file वाचा.

तिसरे, सुरुवातीपासून शेवटपर्यंत खात्री करा. एक 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 चालवली जात नाही. पहिल्या दोन तपासण्यांमधून समस्या cron मध्ये आहे की WP-CLI मध्ये, हे समजते.

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

systemd timer हा पर्याय

सर्व्हरवरील इतर नियोजित कामे आधीपासून systemd services and timers वापरून चालत असतील, तर WordPress देखील त्याच पद्धतीने चालवा. त्यानंतर प्रत्येक run systemctl list-timers मध्ये दिसतो आणि output rotate कराव्या लागणाऱ्या 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 च्या दोन copies एकाच वेळी चालवत नाही. त्यामुळे या आवृत्तीला flock आवश्यक नाही. Persistent=true मुळे मशीन बंद असताना चुकलेला run systemd नंतर भरून काढतो. crontab entry हे करू शकत नाही.

crontab किंवा timer यापैकी एक निवडा. त्याच site विरुद्ध दोन्ही चालवल्यास queue दोनदा रिकामी केली जाते. त्यामुळे 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 च्या मालकीची होते. पुढील web request www-data म्हणून चालते, त्या directories मध्ये लिहू शकत नाही आणि site खालीलप्रमाणे errors दाखवू लागते:

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 आहेत. त्यामुळे एका file मधील line delete केल्याने दुसऱ्या 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 सुरू होते, सेकंदाच्या अंशात fail होते आणि log मध्ये एकच ओळ राहते:

/bin/sh: 1: wp: not found

अंदाज करण्याऐवजी cron चे environment स्वतः तपासा. तात्पुरती ओळ जोडा:

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

एक interval पूर्ण झाल्यानंतर /tmp/cron-env.txt वाचा आणि ती ओळ delete करा. त्या file मधील PATH= value तुमच्या job ला मिळणाऱ्या value सारखीच असते.

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

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

थेट एकत्रित साठलेले processes शोधा:

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

etimes म्हणजे process चे वय seconds मध्ये. एक ओळ असल्यास स्थिती योग्य आहे. तुमच्या interval पेक्षा बरेच जास्त age असलेल्या अनेक ओळी दिसत असल्यास 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 येथे लागू होत नाही. step 3 मधील entry मधील flock -n आता overlap रोखतो. वगळलेला run रचना अशी असल्यामुळे त्वरित आणि शांतपणे exit होतो. Overlap ही समस्या crontab मध्ये सोडवावी लागते; host kernel ती तुमच्यासाठी सोडवत नाही. Linux kernel 7.2 मध्ये जोडलेले cache-aware task placement process कोणत्या core वर चालेल एवढेच ठरवते; तुम्ही किती processes सुरू केले हे ते ठरवत नाही.

तुम्ही प्रत्यक्षात अवलंबून असलेल्या सर्वात कमी 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 साठी scheduled केलेला post 09:05 पर्यंत publish होतो. साइटवर time-critical काहीही नसल्यास पंधरा मिनिटे योग्य आहेत. एक मिनिटांचा 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 शांत ठेवते आणि errors मात्र दाखवत राहते. cron job साठी हेच अपेक्षित आहे.

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

system cron कडे WordPress queue ची जबाबदारी दिल्यानंतर, सर्व्हरवरील उर्वरित नियमित कामेही त्याच ठिकाणी ठेवा, जेणेकरून ती दिसत राहतील. ऑपरेटिंग सिस्टमचे 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 load वरून 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 पुरेसा मोठा ठेवा. हा वेळ मोजण्यासाठी WP-CLI command च्या आधी time लावा. Busy site वर एक मिनिटांचे intervals एकमेकांवर runs जमा करू शकतात, जोपर्यंत flock त्यांना नियंत्रित करत नाही.

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

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