Jinsi ya kuzima WP-Cron na kutumia system cron

WP-Cron ni nini, na kwa nini system cron huchukua nafasi yake

WP-Cron ni kipangaji cha kazi kilichojengwa ndani ya WordPress, na huendesha kazi tu mtu anapoomba ukurasa. Hakuna kitu ndani ya WordPress kinachoiamsha chenyewe. Kwenye kila ombi ambalo halijatolewa kutoka kwenye cache, WordPress husoma orodha ya kazi zilizopangwa. Ikiwa kuna kazi iliyofikia muda wake, hutuma ombi la pili la HTTP kurudi kwake kwenye /wp-cron.php ili kutekeleza kazi hiyo. Kuhamisha kazi hiyo kwenye system cron hukupa uendeshaji mmoja unaotabirika kwa ratiba maalumu, bila kujali kama tovuti ilikuwa na wageni elfu moja katika dakika hiyo au haikuwa na mgeni yeyote.

Mistari miwili hufanya kazi halisi: constant ndani ya wp-config.php, na ingizo la crontab. Kila kitu kingine katika mwongozo huu kinahusu mambo ambayo mistari hiyo miwili haikuelezi. Ni mtumiaji gani anayepaswa kuendesha kazi hiyo, jinsi ya kuthibitisha kuwa matukio yaliyopangwa yalitekelezwa, na njia tatu ambazo usanidi huu unaweza kushindwa bila kuonyesha ujumbe wowote kwenye tovuti.

Mifano inatumia /srv/www/example.com kama saraka ya WordPress na www-data kama mtumiaji wa web server. Badilisha paths na user zako kila mahali.

Mgeni gani alianzisha gharama za cron kwenye tovuti yenye shughuli nyingi

Kila ombi lisilotolewa kutoka kwenye cache hulipia ukaguzi huu. WordPress hupakia option ya cron, hulinganisha timestamps, na kitu kinapokuwa tayari kutekelezwa, huita spawn_cron(), ambayo hutuma ombi la loopback lisilozuia kwenda /wp-cron.php. Mgeni hasubiri matokeo. PHP worker ndiye husubiri. Kwenye VPS ndogo inayotumia PHP-FPM yenye pm.max_children = 5, job moja ya ratiba iliyochelewa hushikilia sehemu ya tano ya uwezo wako wa PHP kwa muda wote unaohitajika. Pia kuna uwezekano mkubwa ianzishwe wakati wa dakika yenye shughuli nyingi zaidi, kwa sababu hapo ndipo page loads huwa nyingi zaidi.

WordPress huzuia nakala zinazorudiwa. Huchukua lock yenye muda wa uhai wa WP_CRON_LOCK_TIMEOUT, ambao ni sekunde 60 kwa chaguo-msingi, ili wageni wanaofika kwa wakati mmoja wasianzishe run tofauti kila mmoja. Lock hiyo hupunguza urudufu. Haihamishi kazi hiyo kutoka kwenye njia ya ombi.

Hesabu mara ngapi cron inaendeshwa kwenye seva yako mwenyewe kabla ya kuamua kama ina umuhimu. Kila loopback huonekana kwenye access log ya web server:

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

Apache huandika kwenye /var/log/apache2/access.log badala yake. Idadi ya maelfu kwa siku ni gharama halisi. Hii ni aina ya kipimo unachopaswa kufanya kwenye seva yako mwenyewe badala ya kusoma kwenye makala, kama vile ungefanya benchmark ya VPS kabla na baada ya mabadiliko mengine yoyote.

Caching hubadilisha hali hii. Page cache ikitoa maombi mengi kama static HTML, PHP haiendeshwi kwa maombi hayo. Kwa hiyo, ukaguzi wa cron haufanyiki. Tovuti yenye shughuli nyingi inayotumia caching kwa kiwango kikubwa huanza kufanya kazi kama tovuti tulivu iliyo hapa chini.

Mgeni gani alianzisha hitilafu za cron kwenye tovuti yenye watembeleaji wachache

Hakuna watembeleaji, hakuna cron. Tovuti inayopokea matembezi machache kwa siku huendesha kazi zake zilizopangwa mara chache hizo kwa siku, katika muda wowote wa nasibu ambao matembezi hayo hutokea.

Dalili huwa za aina ileile. Chapisho lililopangwa kuchapishwa saa 09:00 hubaki kwenye orodha ya machapisho likiwa na alama Missed schedule hadi mtu afungue ukurasa. Plugins za backup huruka kazi za usiku. Ukaguzi wa masasisho huchelewa, hivyo dashboard haionyeshi chochote cha kusasishwa ingawa security release tayari imetolewa. Barua pepe za oda, arifa za renewal na maonyo ya expiry hutumwa kwa kuchelewa.

Hakuna kati ya haya inayorekodi error. Kwa mtazamo wa WordPress, job haikuwahi kuchelewa, kwa sababu haikuwahi kuanzishwa.

Hatua ya 1: zima kichochezi cha wageni katika wp-config.php

Fungua /srv/www/example.com/wp-config.php na uongeze constant hii:

define( 'DISABLE_WP_CRON', true );

Iweke juu ya mstari unaosomeka /* That's all, stop editing! Happy publishing. */, kwa sababu mstari ulio chini ya maoni hayo unahitaji wp-settings.php, na wp-settings.php ndipo WordPress inapounganisha ukaguzi wa cron kwenye init. Constant iliyowekwa baada ya require hiyo huwekwa ikiwa imechelewa sana kubadilisha chochote, na faili huonekana kuwa sahihi huku kichochezi kikiendelea kufanya kazi.

Thibitisha kuwa mstari uko mahali unapodhani:

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

Constant hii haizuii matukio kuratibiwa. Plugins zitaendelea kuongeza kazi kwenye foleni kama hapo awali. Inazuia tu upakiaji wa kurasa kuendesha foleni hiyo. Kwa hiyo, foleni haitawahi kuendeshwa hadi ukamilishe hatua ya 3.

Pia haizuii maombi ya moja kwa moja kwenda /wp-cron.php. Mtu yeyote bado anaweza kuomba URL hiyo, na kwa kawaida hilo si tatizo kwa sababu faili huendesha tu kazi ambazo muda wake umefika. Kuzuia URL hiyo katika usanidi wa web server ni hiari. Ukiizuia, fallback ya curl iliyo karibu na mwisho wa mwongozo huu pia itaacha kufanya kazi.

Hatua ya 2: kusakinisha WP-CLI

WP-CLI ni zana rasmi ya mstari wa amri (command line) kwa ajili ya WordPress. Inahitaji binary ya PHP ya mstari wa amri, ambayo ni kifurushi tofauti na moduli ya PHP ya seva ya wavuti.

php -v
sudo apt install -y php-cli

Sakinisha WP-CLI kutoka kwenye phar build, ambayo ndiyo njia inayopendekezwa na mwongozo rasmi wa usakinishaji:

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 huchapisha njia ya binary ya PHP, toleo la PHP, na toleo la WP-CLI. Ikiwa inachapisha vyote vitatu, basi phar inafanya kazi. Kufikia Oktoba 2026, mwongozo wa usakinishaji unaweka PHP 7.2.24 kama kiwango cha chini, na Ubuntu 24.04 inakuja na PHP 8.3, kwa hivyo seva ya sasa inakidhi mahitaji hayo kwa urahisi. Sasisha baadaye kwa kutumia sudo wp cli update.

Endesha WP-CLI kama mtumiaji wa tovuti, kamwe usiiendeshe kama root:

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

Kama root, WP-CLI inakataa kuanza:

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

Inapendekeza --allow-root. Usitumie amri hiyo hapa. Sababu iko kwenye hali ya kwanza ya hitilafu hapa chini.

Pia kumbuka kuwa sudo -u www-data -i haifanyi kazi, kwa sababu login shell ya akaunti hiyo ni /usr/sbin/nologin na utapata This account is currently not available.. Kupitisha amri moja kwa moja kwenye sudo -u huruka login shell, kwa hivyo inaendesha vizuri.

Sasa thibitisha kuwa WordPress yenyewe inaona constant kutoka hatua ya 1:

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

Hiyo huchapisha bool(true). Hitilafu mbaya (fatal error) kuhusu constant isiyofafanuliwa inamaanisha kuwa mstari wa define() haufikiwi, jambo ambalo kwa kawaida linamaanisha kuwa iliwekwa chini ya require.

Hatua ya 3: ongeza ingizo la cron kwa mtumiaji sahihi

Mtumiaji sahihi ni yule anayemiliki faili ambazo PHP huandika. Kagua pande zote mbili:

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

Kwenye usakinishaji wa kawaida wa Ubuntu, majibu yote mawili ni www-data. Ikiwa uliipa tovuti pool yake ya PHP-FPM yenye mtumiaji wake, kama inavyokuwa kwa kawaida kwenye usanidi wa kila tovuti katika LAMP stack kwenye Ubuntu 24.04, tumia mtumiaji huyo kwa kila kitu hapa chini.

Unda saraka ya log ambayo mtumiaji huyo anaweza kuiandikia:

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

Hariri crontab ya mtumiaji huyo:

sudo crontab -u www-data -e

Ongeza mstari mmoja:

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

Sehemu kwa sehemu. */5 huiendesha kila baada ya dakika tano. flock -n huchukua lock file na huacha mara moja ikiwa mchakato wa awali bado unaishikilia. /usr/local/bin/wp ni absolute path, ambayo cron inahitaji. --path huruhusu command kuendeshwa kutoka working directory yoyote. --due-now huendesha matukio ambayo muda wake umefika pekee, badala ya kila tukio lililo kwenye queue. Redirect hutuma output ya kawaida na errors kwenye faili moja unayoweza kusoma.

Kwa matumizi ya kawaida, redirect hiyo si ya hiari. Cron hutuma output ya job kwa mtumiaji wake kupitia barua pepe, lakini VPS images nyingi hazina mail transfer agent iliyosakinishwa. Kisha cron huandika (CRON) info (No MTA installed, discarding output) kwenye log na kutupa output hiyo. Faili huhifadhi ushahidi.

Kagua faili iliyohifadhiwa:

sudo crontab -u www-data -l

Kwa tovuti kadhaa, tumia mstari mmoja kwa kila tovuti na panga dakika kwa vipindi tofauti ili zisiondoke zote kwa wakati mmoja:

*/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 hukua bila kikomo usipoizungusha. Andika /etc/logrotate.d/wp-cron:

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

Kagua kuwa inasomeka bila kugusa kitu chochote: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Hatua ya 4: thibitisha kuwa matukio yaliyoratibiwa yalitekelezwa

Mstari wa crontab uliohifadhiwa bila hitilafu hauthibitishi chochote. Anza na ukaguzi rahisi zaidi, kisha endelea hadi kwenye ukaguzi unaothibitisha hali halisi.

Kwanza, je, cron ilianzisha command? Cron huandika kumbukumbu kwenye journal chini ya unit yake yenyewe:

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

Ingizo sahihi linaonekana hivi, baada ya kuondoa timestamp na jina la host mwanzoni:

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)

Mstari huo unamaanisha kuwa cron ilianzisha command yako kama www-data. Hauthibitishi kama command ilifanikiwa.

Pili, je, WordPress ilitekeleza chochote? Soma log file:

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

WP-CLI huandika mstari mmoja kwa kila tukio, kisha jumla:

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

Errors huandikwa kwenye file hilohilo, ambalo ndilo kusudi la 2>&1. Runs nyingi hazitakuwa na matukio ya kutekelezwa na zitaandika taarifa chache sana. Kwa hiyo, soma file baada ya run unayojua kuwa ilikuwa na kazi iliyosubiri.

Tatu, thibitisha mchakato mzima. Ratibu tukio la marker kisha ulitazame likiondoka:

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

Subiri interval moja, kisha endesha list command tena. Hook imeondoka kwa sababu tukio la mara moja huondolewa kwenye queue linapotekelezwa. Hakuna plugin inayosajili callback kwenye jina hilo la hook, kwa hiyo kuiendesha hakufanyi mabadiliko mengine kwenye site. Ikiwa hook bado imeorodheshwa baada ya intervals mbili, queue haiendeshwi. Ukaguzi miwili ya kwanza itakuonyesha kama tatizo liko kwenye cron au WP-CLI.

Usitumie wp cron test kwa hili. Command hiyo hukagua kama spawning iliyoanzishwa na visitor inafanya kazi, na hutoa error wakati DISABLE_WP_CRON ni true. Kwenye seva iliyosanidiwa kwa usahihi, error hiyo ndiyo output inayotarajiwa, si hitilafu.

Mbadala wa systemd timer

Ikiwa kazi nyingine za ratiba za seva tayari zinaendeshwa kama systemd services na timers, weka WordPress huko pia. Kila utekelezaji utaonekana kwenye systemctl list-timers, na output itaenda kwenye journal badala ya faili ambalo lazima ulifanyie rotation.

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

Kisha /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 haitatekeleza nakala mbili za service ileile kwa wakati mmoja, kwa hiyo toleo hili halihitaji flock. Persistent=true huifanya itekeleze kazi iliyokosa wakati mashine ilikuwa imezimwa, jambo ambalo crontab entry haiwezi kufanya.

Chagua crontab au timer. Kuendesha zote mbili dhidi ya site ileile kunamaanisha queue inachakatwa mara mbili, na utekelezaji wa duplicate wa email au order job utaonekana kwa wateja wako.

Kwa nini cron job haipaswi kuendeshwa kama root

Hii ndiyo sababu ya kwanza kati ya tatu zinazofanya usanidi ushindwe. Ukiweka job kwenye crontab ya root, WP-CLI husitisha kabla haijafanya chochote:

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

Foleni haiendeshwi. Ikiwa hukuelekeza output kwingine, huwezi kuona ujumbe. Suluhisho hatari ni kuongeza --allow-root, kwa sababu kila faili ambayo plugin inaandika wakati wa uendeshaji huo itakuwa ya root. Ombi linalofuata la wavuti huendeshwa kama www-data, haliwezi kuandika kwenye saraka hizo, na site huanza kuripoti ujumbe kama huu:

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

Rekebisha ownership, kisha hamisha job:

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

Crontab ya root na crontab ya www-data ni faili tofauti. Kwa hiyo, kufuta mstari kutoka kwenye faili moja hakubadili nyingine. Kagua zote mbili:

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

Kwa nini cron inaripoti wp: not found

Hii ndiyo hitilafu ya pili. Cron huwapa kazi za watumiaji PATH fupi sana, /usr/bin:/bin. WP-CLI husakinishwa kwenye /usr/local/bin, ambayo haipo kwenye orodha hiyo. Kazi huanza, hushindwa ndani ya sehemu ndogo ya sekunde, na log huwa na mstari mmoja:

/bin/sh: 1: wp: not found

Kagua mazingira ya cron moja kwa moja badala ya kukisia. Ongeza mstari wa muda:

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

Soma /tmp/cron-env.txt baada ya muda mmoja wa utekelezaji, kisha ufute mstari huo. Thamani ya PATH= iliyo kwenye faili hiyo ndiyo hasa ambayo kazi yako hupokea.

Kuna marekebisho mawili. Tumia path kamili /usr/local/bin/wp, kama ilivyo katika hatua ya 3. Au weka PATH mara moja juu ya crontab, kabla ya kila mstari wa kazi:

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

Mtego huo huo upo hatua moja chini. wp phar huanza na #!/usr/bin/env php, kwa hiyo shell lazima iweze kupata php pia. Ikiwa PHP iko nje ya /usr/bin, jambo linalotokea kwenye builds maalum na builds za control panel, utapata:

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

Taja interpreter moja kwa moja katika hali hiyo, kwa mfano /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

Kwa nini muda wa dakika moja unarejesha tatizo la awali

Hii ni mara ya tatu ya kufeli. * * * * * inaonekana kuwa salama zaidi kuliko dakika tano, lakini kwenye tovuti yenye shughuli nyingi, inakurudisha pale ulipoanzia. Ikiwa mchakato mmoja unachukua muda mrefu kuliko muda uliopangwa, mchakato unaofuata huanza wakati ule wa kwanza bado unaendelea. Baada ya dakika kumi, kutakuwa na michakato kumi ya PHP, kila moja ikishikilia kumbukumbu yake na muunganisho wake wa database.

Tafuta mkusanyiko wa michakato moja kwa moja:

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

etimes ni umri wa mchakato kwa sekunde. Mstari mmoja unaonyesha hali nzuri. Mistari kadhaa yenye umri mkubwa zaidi ya muda wako wa interval inamaanisha michakato inarundikana, na kwenye VPS ndogo, hii huishia kwenye kosa la MySQL Too many connections, au kernel kuua PHP ili kurejesha kumbukumbu, jambo unaloweza kulithibitisha kwa sudo dmesg -T | grep -i 'killed process'.

WP-CLI huendesha callbacks za tukio moja kwa moja badala ya kuomba wp-cron.php, lakini kwa --due-now, WP-CLI ya sasa bado inaheshimu transient ya doing_cron, ambayo ni lock ileile inayotumiwa na WordPress kuzuia michakato inayofanana kuanza mara mbili. Huweka lock hiyo wakati mchakato unapoanza, na ikiwa mchakato mwingine tayari unaishikilia, mchakato mpya huandika Warning: A cron event run is already in progress; skipping. kwenye log yako na kusimama. Lock hiyo hudumu kwa WP_CRON_LOCK_TIMEOUT pekee, sekunde 60 kwa kawaida, hivyo mchakato unaochukua muda mrefu zaidi ya dakika moja huacha kulindwa nayo na mchakato unaofuata unaweza kuanza sambamba nao. flock -n katika hatua ya 3 inashikilia lock yake kwa muda wote ambao mchakato unaishi, jambo ambalo huzuia mwingiliano kwa michakato ya polepole. Mchakato unaorukwa na flock huacha kufanya kazi mara moja na kimya kimya, kwa mujibu wa usanifu wake. Mwingiliano ni tatizo ambalo lazima ulitatue kwenye crontab badala ya kutegemea kernel ya seva ikutatulie: hata cache aware task placement iliyoongezwa kwenye Linux kernel 7.2 huamua tu ni core ipi mchakato utakaa, kamwe haiamui ni mingapi uliyoianzisha.

Chagua muda wa interval kulingana na ratiba fupi zaidi unayotegemea, na pima muda wa mchakato kwanza:

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

Dakika tano ni chaguo la msingi linalofaa: chapisho lililopangwa saa 09:00 kwa kawaida huchapishwa ifikapo 09:05, mradi mchakato uliotangulia umemalizika. Ikiwa mchakato wa awali bado unashikilia lock ifikapo 09:05, mwito huo hurukwa na chapisho husubiri mchakato unaofuata utakaopata lock. Dakika kumi na tano ni sawa kwa tovuti isiyo na mambo ya dharura. Dakika moja inafaa kwa maduka na programu jalizi (plugins) zinazotegemea queue ambazo zinahitaji muda huo kikweli, na tu pale unapojua kuwa mchakato unamalizika ndani ya sekunde chache.

Usipoweza kusakinisha WP-CLI

Baadhi ya watoa huduma huzuia zana za shell. Ombi la kawaida la HTTP kwenda wp-cron.php huendesha foleni hiyo hiyo, lakini kupitia stack nzima ya web:

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

Mambo unayokosa, kwa uwazi:

• Uendeshaji una kikomo cha timeout za maombi za web server na PHP-FPM, hivyo job ndefu inaweza kukatizwa katikati.
• Certificate lazima iwe halali, vinginevyo curl husitisha kwa SSL certificate problem. Kwa hiyo, endelea kufanya renewal kwa Certbot kwenye nginx.
• Page caching haipaswi kuweka wp-cron.php kwenye cache, vinginevyo maombi ya cron yatapata response iliyohifadhiwa na hakuna kitakachoendeshwa.
• Hupati output ya kila tukio, kwa hiyo ushahidi pekee kwamba job iliendeshwa ni athari iliyosababisha.

-sS huifanya curl iwe kimya inapofaulu, huku ikiendelea kuchapisha errors. Hilo ndilo linalohitajika kwenye cron job.

Ni nini kingine kinachopaswa kuwa kwenye ratiba ya seva

Baada ya system cron kusimamia foleni ya WordPress, weka kazi nyingine za kawaida za server hiyo katika sehemu hiyo hiyo ili uweze kuziona. Patches za usalama za operating system zinapaswa kushughulikiwa na unattended upgrades, badala ya cron line unayodumisha mwenyewe. Kusasisha plugins na themes za WordPress ni uamuzi tofauti: wp plugin update --all kwenye crontab inaweza kuvuruga bila tahadhari site inayotumika saa 3 asubuhi, bila mtu anayefuatilia. Kwa hiyo, endesha kazi hiyo kwa makusudi, au iwe nyuma ya hatua ya staging na backup.

FAQ

Je, kuzima WP-Cron kunazuia machapisho yaliyopangwa kuchapishwa?

Hapana, mradi kitu kingine kiendeshe foleni hiyo. DISABLE_WP_CRON inazuia tu kurasa zinapopakiwa kuanzisha foleni hiyo. Matukio bado yanapangwa kama ilivyokuwa awali. Chapisho lililowekwa saa 09:00 huchapishwa kwenye cron run ya kwanza baada ya saa 09:00 inayopata lock, kwa hivyo muda wa dakika tano kwa kawaida huchapisha chapisho hilo ifikapo 09:05. Ikiwa run ya awali ya polepole bado inashikilia lock, invocation hiyo hurukwa na uchapishaji husubiri run inayofuata. Ikiwa utaweka constant hiyo na usiongeze cron entry, chapisho hubaki kwenye orodha likiwa na alama ya Missed schedule hadi kitu kingine kiendeshe foleni hiyo.

Ni mtumiaji yupi anayepaswa kuendesha WordPress cron job?

Mtumiaji anayemiliki faili ambazo PHP huandika, ambaye ni www-data kwenye usakinishaji wa kawaida wa Ubuntu. Hakiki na stat -c '%U %G' /srv/www/example.com/wp-content/uploads na ulinganishe na mstari wa user = katika usanidi wa pool ya PHP-FPM. Kuendesha job kama root husababisha WP-CLI kusimama na kutoa error ya YIKES, na kuilazimisha kupitia --allow-root huacha faili zinazomilikiwa na root ndani ya wp-content ambazo web server haiwezi kuziandika baadaye.

Ni mara ngapi system cron inapaswa kuendesha WordPress cron?

Kila dakika tano inafaa tovuti nyingi. Linganisha muda huo na ratiba fupi zaidi unayotegemea, na uiweke juu kidogo ya muda ambao run moja huchukua, jambo unaloweza kupima kwa kuweka time mbele ya amri ya WP-CLI. Muda wa dakika moja husababisha run kurundikana juu ya nyingine kwenye tovuti yenye shughuli nyingi isipokuwa kama flock itazizuia.

Kwa nini wp cron test inafeli baada ya kuzima WP-Cron?

Kwa sababu amri hiyo hujaribu spawning inayochochewa na mgeni, na inaripoti error wakati DISABLE_WP_CRON imewekwa kuwa true. Hilo ndilo matokeo sahihi kwenye seva iliyosanidiwa kwa njia hii. Hakiki njia ya system cron badala yake: soma /var/log/wp-cron/example.log, au panga tukio la alama na wp cron event schedule na uthibitishe kuwa limetoweka kutoka wp cron event list baada ya run inayofuata.

Je, ninahitaji WP-CLI, au curl kwenda wp-cron.php inatosha?

Curl inafanya kazi, na ndiyo jibu sahihi wakati huwezi kusakinisha WP-CLI. Ni polepole, kwa sababu hupakia WordPress kupitia web server, na ina mipaka ya request timeout. WP-CLI huendesha matukio katika command line ya mchakato wa PHP bila web timeout, na huchapisha mstari mmoja kwa kila tukio pamoja na muda wake, kwa hivyo log inakuambia hasa kile kilichoendeshwa na muda uliotumika.