Jinsi ya kuzima WP-Cron na kutumia system cron

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

WP-Cron ni kipanga ratiba cha kazi kilichojengwa ndani ya WordPress, na hufanya kazi tu wakati mtu anapoomba ukurasa. Hakuna kitu ndani ya WordPress kinachoamka chenyewe. Kila ombi lisilotolewa kutoka kwenye cache, WordPress husoma orodha ya kazi zilizopangwa, na ikiwa kuna kazi inayotakiwa kufanyika, hutuma ombi la pili la HTTP kwenda kwenyewe kwenye /wp-cron.php ili kufanya kazi hiyo. Kuhamishia kazi hiyo kwenye system cron hukupa uendeshaji mmoja unaotabirika kwa ratiba maalum, bila kujali kama tovuti ilikuwa na wageni elfu moja kwa dakika hiyo au hakuna hata mmoja.

Mistari miwili hufanya kazi yenyewe: constant katika wp-config.php, na ingizo la crontab. Kila kitu kingine katika mwongozo huu ni sehemu ambayo mistari hiyo miwili haikuelezi. Ni mtumiaji yupi anayepaswa kuendesha kazi hiyo, jinsi ya kuthibitisha kuwa matukio yaliyopangwa yamefanyika kweli, na njia tatu ambazo usanidi huu hushindwa bila kuchapisha chochote kwenye tovuti.

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

Ni mgeni yupi anayesababisha gharama za cron kwenye tovuti yenye shughuli nyingi

Kila ombi lisilohifadhiwa kwenye cache hulipia ukaguzi huu. WordPress hupakia chaguo la cron, hulinganisha mihuri ya muda (timestamps), na wakati kitu kinapofika muda wake, huita spawn_cron(), ambayo hutuma ombi la loopback lisilozuia (non-blocking) kwenda /wp-cron.php. Mgeni hasubiri matokeo. Mfanyakazi wa PHP ndiye anayesubiri. Kwenye VPS ndogo inayoendesha PHP-FPM na pm.max_children = 5, kazi moja ya ratiba inayochelewa huchukua sehemu ya tano ya uwezo wako wa PHP kwa muda wote inaochukua, na ina uwezekano mkubwa wa kuanzishwa wakati wa dakika yako yenye shughuli nyingi zaidi, kwa sababu ndipo idadi kubwa ya kurasa zinapopakiwa.

WordPress hupunguza marudio. Huchukua lock yenye muda wa maisha wa WP_CRON_LOCK_TIMEOUT, sekunde 60 kwa chaguo-msingi, ili wageni wanaoingia kwa wakati mmoja wasianze kila mmoja utekelezaji wake. Lock hiyo huzuia marudio. Haiondoi kazi hiyo kutoka kwenye njia ya ombi.

Hesabu mara ngapi inawaka kwenye seva yako mwenyewe kabla ya kuamua kama ni muhimu. Kila loopback huonekana kwenye logi ya ufikiaji ya seva ya wavuti:

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

Apache huandika kwenye /var/log/apache2/access.log badala yake. Hesabu ya maelfu kwa siku ni gharama halisi, na ni aina ya namba unayopaswa kupima kwenye mashine yako mwenyewe badala ya kusoma kwenye makala, vilevile unavyoweza kupima utendaji wa VPS kabla na baada ya mabadiliko yoyote mengine.

Caching hubadilisha hali hiyo. Ikiwa cache ya ukurasa itahudumia maombi mengi kama HTML tuli, PHP haitaendesha kamwe kwa maombi hayo, kwa hivyo ukaguzi wa cron hautatokea kamwe. Tovuti yenye shughuli nyingi iliyohifadhiwa sana kwenye cache huanza kufanya kazi kama tovuti tulivu iliyo hapa chini.

Ni nini husababisha cron kukwama kwenye tovuti yenye wageni wachache

Kutokuwepo kwa wageni kunamaanisha hakuna cron. Tovuti inayopata wageni wachache kwa siku huendesha kazi zake zilizopangwa mara chache kwa siku, katika nyakati za nasibu ambazo wageni hao hufika.

Dalili zote zinafanana. Chapisho lililopangwa saa 09:00 linabaki kwenye orodha ya machapisho likiwa na alama ya Missed schedule hadi mtu fulani atakapopakia ukurasa. Plugin za kuhifadhi nakala (backup) huruka usiku. Ukaguzi wa masasisho huchelewa, hivyo dashibodi haionyeshi chochote cha kusasishwa wakati toleo la usalama tayari limetoka. Barua pepe za oda, arifa za kusasisha na maonyo ya muda kuisha huchelewa kutumwa.

Hakuna kati ya haya kinachorekodi hitilafu kwenye log. Kazi hiyo haikuwahi kuchelewa kwa mtazamo wa WordPress, 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 inayofafanuliwa baada ya require hiyo huwekwa kuchelewa sana ili kubadilisha chochote, na faili huonekana kuwa sahihi wakati kichochezi kinaendelea kufanya kazi.

Thibitisha kuwa mstari huo uko mahali unapodhani upo:

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

Constant hii haizuii matukio kupangwa. Plugins zitaendelea kuongeza kazi kwenye foleni, kama ilivyokuwa awali. Inazuia tu upakiaji wa kurasa kuendesha foleni hiyo, jambo linalomaanisha kuwa foleni haitaendeshwa kamwe hadi utakapomaliza hatua ya 3.

Pia haizuii maombi ya moja kwa moja kwenye /wp-cron.php. Mtu yeyote anaweza bado kuomba URL hiyo, na kwa kawaida hilo halina madhara kwa sababu faili huendesha tu kile kinachopaswa kufanyika. Kuizuia katika usanidi wa seva yako ya wavuti ni hiari. Ukizuia, njia mbadala ya curl iliyo karibu na mwisho wa mwongozo huu itaacha kufanya kazi pia.

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 command line, 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 itachapisha vyote vitatu, basi phar inafanya kazi. Kufikia Agosti 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. Sasisha baadaye kwa kutumia sudo wp cli update.

Endesha WP-CLI kama mtumiaji wa tovuti, usiiendeshe kamwe 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 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 cron entry kama mtumiaji sahihi

Mtumiaji sahihi ni yule anayemiliki faili ambazo PHP huandika. Hakikisha 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 yako PHP-FPM pool yake yenyewe yenye mtumiaji wake, hali ambayo ndiyo mwisho wa kawaida wa usanidi wa kila tovuti kwenye LAMP stack kwenye Ubuntu 24.04, tumia mtumiaji huyo kwa kila kitu hapa chini.

Tengeneza saraka ya logi ambayo mtumiaji huyo anaweza kuandika:

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

Tuchambue sehemu kwa sehemu. */5 huiendesha kila baada ya dakika tano. flock -n hutumia lock file na kuacha mara moja ikiwa mchakato wa awali bado unashikilia lock hiyo. /usr/local/bin/wp ni njia kamili (absolute path), ambayo cron inahitaji. --path inaruhusu amri kuendeshwa kutoka saraka yoyote ya kazi. --due-now huendesha tu matukio ambayo muda wake umefika, badala ya kila tukio lililopo kwenye foleni. Uelekezaji (redirect) hutuma matokeo ya kawaida na makosa kwenye faili moja unayoweza kuisoma.

Uelekezaji huo si wa hiari katika utendaji. Cron hutuma matokeo ya kazi kwa mtumiaji wake kupitia barua pepe, na picha nyingi za VPS hazina mail transfer agent iliyosakinishwa, hivyo cron huandika (CRON) info (No MTA installed, discarding output) kwenye logi na kufuta matokeo hayo. Faili huhifadhi ushahidi.

Hakikisha faili imehifadhiwa:

sudo crontab -u www-data -l

Kwa tovuti nyingi, tumia mstari mmoja kwa kila moja ukiwa na dakika zilizopishana ili zisiweze kuanza 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

Logi hukua milele isipokuwa ukiizungusha (rotate). Andika /etc/logrotate.d/wp-cron:

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

Hakikisha inasomeka bila kubadilisha chochote: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Hatua ya 4: thibitisha matukio yaliyopangwa yamefanyika kikamilifu

Mstari wa crontab uliowekwa kwa mafanikio hauhakikishi kuwa kazi imefanyika. Anza na ukaguzi rahisi kuelekea ule unaothibitisha matokeo.

Kwanza, je cron ilianzisha amri hiyo? Cron huandika kumbukumbu (logs) kwenye journal chini ya unit yake:

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

Ingizo zuri huonekana hivi, baada ya kuondoa timestamp na jina la host:

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 cron ilianzisha amri yako kama www-data. Haisemi chochote kuhusu kama amri hiyo ilifanya kazi kwa usahihi.

Pili, je WordPress ilitekeleza chochote? Soma faili ya log:

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

WP-CLI huchapisha 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.

Hitilafu huonekana kwenye faili hiyo hiyo, ambayo ndiyo sababu kuu ya kutumia 2>&1. Mara nyingi hakutakuwa na kazi ya kufanya hivyo faili itakuwa na maandishi machache, kwa hivyo soma faili hiyo baada ya muda unaojua kuwa kuna kazi iliyokuwa ikisubiri.

Tatu, thibitisha kuanzia mwanzo hadi mwisho. Panga tukio la alama (marker event) na uone likitoweka:

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 kwa muda wa interval moja, kisha endesha amri ya list tena. Hook hiyo itakuwa imetoweka, kwa sababu tukio la mara moja huondolewa kwenye foleni likishatekelezwa. Hakuna plugin inayojiandikisha kwenye jina hilo la hook, kwa hivyo kuliendesha hakutafanya jambo lingine lolote kwenye tovuti. Ikiwa hook bado inaonekana baada ya interval mbili, foleni haitekelezwi, na ukaguzi wa kwanza na wa pili utakuambia kama tatizo ni cron au WP-CLI.

Usitumie wp cron test kwa hili. Amri hiyo hukagua kama uanzishaji unaochochewa na wageni (visitor triggered spawning) unafanya kazi, na hutoa hitilafu wakati DISABLE_WP_CRON ikiwa kweli. Kwenye seva iliyosanidiwa vizuri, hitilafu hiyo ndiyo matokeo yanayotarajiwa, si tatizo.

Njia mbadala ya systemd timer

Ikiwa kazi nyingine zilizopangwa kwenye seva tayari zinaendeshwa kama systemd services and timers, weka WordPress hapo pia. Kila uendeshaji utaonekana kwenye systemctl list-timers, na matokeo yatapelekwa kwenye journal badala ya faili unayopaswa kuizungusha (rotate).

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 haitaendesha nakala mbili za huduma moja kwa wakati mmoja, kwa hivyo toleo hili halihitaji flock. Persistent=true huifanya ifuatilie kazi iliyokosa kuendeshwa wakati mashine ilikuwa imezimwa, jambo ambalo ingizo la crontab haliwezi kufanya.

Chagua kati ya crontab au timer. Kuendesha zote mbili kwa tovuti moja kunamaanisha kuwa foleni inafutwa mara mbili, na uendeshaji wa nakala za kazi za barua pepe au maagizo utaonekana kwa wateja wako.

Kwa nini cron job haipaswi kuendeshwa kama root

Hii ndiyo njia ya kwanza kati ya tatu ambazo usanidi huu hushindwa. Ukiweka job kwenye crontab ya root, WP-CLI husimama kabla ya kufanya chochote:

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

Foleni (queue) haiwahi kuendeshwa, na kama hukuelekeza pato (output) kwingine, hutaona ujumbe wowote. Suluhisho hatari ni kuongeza --allow-root, kwa sababu kila faili ambalo plugin huandika wakati wa mchakato huo litakuwa la root. Ombi la web linalofuata huendeshwa kama www-data, haliwezi kuandika kwenye saraka hizo, na tovuti huanza kutoa ripoti kama:

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

Rekebisha umiliki (ownership), kisha uhamishe job hiyo:

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 hivyo kufuta mstari kutoka kwa moja hakugusi nyingine. Angalia zote mbili:

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

Kwa nini cron inatoa ripoti ya wp: not found

Hii ni mara ya pili kutokea kwa hitilafu hii. Cron huipa kazi za mtumiaji PATH fupi sana, /usr/bin:/bin. WP-CLI husakinishwa kwenye /usr/local/bin, ambayo haimo kwenye orodha hiyo. Kazi huanza, inafeli ndani ya sehemu ndogo ya sekunde, na logi huonyesha mstari mmoja:

/bin/sh: 1: wp: not found

Angalia mazingira ya cron mwenyewe badala ya kukisia. Ongeza mstari wa muda:

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

Soma /tmp/cron-env.txt baada ya muda mmoja kupita, kisha ufute mstari huo. Thamani ya PATH= katika faili hiyo ndiyo hasa kazi yako inayoipata.

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

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

Mtego huohuo upo ngazi moja chini. Faili ya wp phar huanza na #!/usr/bin/env php, kwa hivyo shell lazima iweze kupata php pia. Ikiwa PHP ipo nje ya /usr/bin, jambo linalotokea kwenye builds maalum na zile za control panel, utapata:

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

Katika hali hiyo, ita interpreter moja kwa moja, 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 kwa hitilafu hii kutokea. * * * * * inaonekana kuwa salama zaidi kuliko dakika tano, lakini kwenye tovuti yenye shughuli nyingi, inakurudisha pale ulipoanzia. Ikiwa utekelezaji mmoja unachukua muda mrefu kuliko muda uliopangwa, utekelezaji 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 utekelezaji inamaanisha kuwa michakato inarundikana, na kwenye VPS ndogo, hii huishia kwa hitilafu ya Too many connections ya MySQL, 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, kwa hivyo lock ya sekunde 60 ambayo WordPress hutumia dhidi ya michakato inayojirudia haitumiki hapa. flock -n katika ingizo la hatua ya 3 ndiyo inayozuia mwingiliano sasa. Utekelezaji uliorukwa hutoka mara moja na kimya kimya, kama ilivyokusudiwa.

Chagua muda wa utekelezaji kulingana na ratiba fupi zaidi unayotegemea, na upime muda wa utekelezaji 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 kawaida linalofaa: chapisho lililopangwa saa 09:00 litachapishwa ifikapo 09:05. Dakika kumi na tano ni sawa kwa tovuti isiyo na mambo yanayohitaji muda sahihi. Dakika moja inafaa kwa maduka na programu jalizi (plugins) zinazotegemea foleni (queue) ambazo kwa kweli zinahitaji muda huo, na tu pale unapojua kuwa utekelezaji unakamilika ndani ya sekunde chache.

Ikiwa huwezi kusakinisha WP-CLI

Baadhi ya watoa huduma za hosting huzuia zana za shell. Ombi la kawaida la HTTP kwenda wp-cron.php huendesha foleni hiyo hiyo, likipitia kwenye stack nzima ya wavuti:

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

Mambo unayopoteza, kwa ufupi:

• Uendeshaji huo una kikomo cha muda wa request (timeouts) wa web server na PHP-FPM, kwa hivyo kazi ndefu inaweza kukatishwa katikati.
• Cheti lazima kiwe halali au curl itasimama na kutoa SSL certificate problem, kwa hivyo hakikisha ufanyaji upya wa vyeti unafanya kazi kupitia Certbot on nginx.
• Page caching haipaswi kuhifadhi wp-cron.php, vinginevyo maombi ya cron yatapata majibu yaliyohifadhiwa (cached) na hakuna kazi itakayoendelea.
• Hupati matokeo (output) kwa kila tukio, kwa hivyo ushahidi pekee wa kazi kuendeshwa ni matokeo iliyoyaleta.

-sS huifanya curl kuwa kimya ikifanikiwa huku ikichapisha makosa, jambo ambalo ndilo unalohitaji katika cron job.

Nini kingine kinapaswa kuwa kwenye ratiba ya seva

Mara tu cron ya mfumo inaposhikilia foleni ya WordPress, weka kazi nyingine za kawaida za seva mahali pamoja, ambapo unaweza kuziona. Viraka vya usalama vya mfumo wa uendeshaji vinapaswa kushughulikiwa na unattended upgrades badala ya mstari wa cron unaouhifadhi kwa mikono. Masasisho ya plugin na theme za WordPress ni uamuzi tofauti: wp plugin update --all kwenye crontab inaweza kuharibu tovuti inayofanya kazi saa 9 usiku bila mtu yeyote kuangalia, kwa hivyo endesha hayo kwa makusudi, au baada ya hatua ya staging na chelezo (backup).

FAQ

Je, kuzima WP-Cron kunazuia machapisho yaliyopangwa kuchapishwa?

Hapana, mradi kuna kitu kingine kinachoendesha foleni hiyo. DISABLE_WP_CRON inazuia tu upakiaji wa kurasa kuanzisha foleni. Matukio bado yanapangwa kama ilivyokuwa awali. Chapisho lililowekwa saa 09:00 huchapishwa kwenye cron run ya kwanza baada ya saa 09:00, kwa hivyo muda wa dakika tano huifanya ichapishwe ifikapo 09:05. Ukiiweka constant hiyo na usiongeze cron entry, chapisho hubaki kwenye orodha likiwa na alama ya Missed schedule hadi kitu kingine kianze kuendesha foleni.

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 hitilafu ya YIKES, na kuilazimisha kupitia --allow-root huacha faili zinazomilikiwa na root ndani ya wp-content ambazo seva ya wavuti 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 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 uanzishaji unaochochewa na mgeni, na inaripoti hitilafu wakati DISABLE_WP_CRON imewekwa kuwa true. Huo ndio matokeo sahihi kwenye seva iliyosanidiwa kwa njia hii. Angalia 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 seva ya wavuti, na ina mipaka ya muda wa kusubiri ombi (request timeout). WP-CLI huendesha matukio katika mchakato wa PHP wa mstari wa amri bila muda wa kusubiri wa wavuti, na huchapisha mstari mmoja kwa kila tukio pamoja na muda wake, kwa hivyo log hukuambia hasa kile kilichoendeshwa na muda kilichochukua.