Paano I-disable ang wp-cron at Gumamit ng System Cron

Ano ang wp-cron at kung bakit ito pinapalitan ng system cron

Ang WP-Cron ang task scheduler na built in sa WordPress. Tumatakbo lamang ito kapag may humiling ng page. Walang awtomatikong gumigising sa loob ng WordPress. Sa bawat request na hindi sinagot mula sa cache, binabasa ng WordPress ang listahan ng mga naka-schedule na job. Kapag may due na job, nagpapadala ito ng ikalawang HTTP request pabalik sa sarili nito sa /wp-cron.php upang isagawa ang trabaho. Kapag inilipat ang job na ito sa system cron, magkakaroon ka ng isang predictable na run sa fixed schedule, kahit may isang libong bisita ang site sa minutong iyon o wala ni isa.

Dalawang linya ang aktuwal na nagsasagawa ng trabaho: isang constant sa wp-config.php at isang crontab entry. Ang lahat ng iba pa sa gabay na ito ay mga bagay na hindi ipinapakita ng dalawang linyang iyon. Kabilang dito kung aling user ang dapat magpatakbo ng job, kung paano mapapatunayang aktuwal na tumakbo ang mga naka-schedule na event, at ang tatlong paraan kung paano mabibigo ang setup nang walang anumang lumalabas sa site.

Ginagamit ng mga halimbawa ang /srv/www/example.com bilang WordPress directory at ang www-data bilang web server user. Palitan ang mga ito ng sarili mong path at user sa lahat ng bahagi ng gabay.

Sinong bisita ang nag-trigger ng cron costs sa isang abalang site

Bawat request na hindi dumaan sa cache ay nagbabayad ng check na ito. Nilo-load ng WordPress ang cron option, ikinukumpara ang mga timestamp, at kapag may due na task, tinatawag nito ang spawn_cron(). Nagpapadala ito ng non-blocking loopback request sa /wp-cron.php. Hindi naghihintay ang bisita sa resulta. Ngunit naghihintay ang isang PHP worker. Sa maliit na VPS na nagpapatakbo ng PHP-FPM na may pm.max_children = 5, inaabot ng isang mabagal na scheduled job ang isang-kalimang bahagi ng PHP capacity hangga't hindi ito natatapos. Malamang na ma-trigger ito sa pinakamataong minuto, dahil iyon ang panahong pinakamaraming page load.

Nililimitahan ng WordPress ang mga duplicate run. Kumukuha ito ng lock na may lifetime na WP_CRON_LOCK_TIMEOUT, na 60 seconds bilang default, kaya hindi magkakahiwalay na run ang sisimulan ng sabay-sabay na mga bisita. Nililimitahan ng lock ang duplication. Hindi nito inaalis ang trabaho sa request path.

Bilangin muna kung gaano ito kadalas tumatakbo sa sarili mong server bago magpasya kung mahalaga ito. Lumalabas ang bawat loopback sa web server access log:

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

Sa halip, nagsusulat ang Apache sa /var/log/apache2/access.log. Ang bilang na nasa libo bawat araw ay tunay na cost. Ito ang uri ng bilang na dapat mong sukatin sa sarili mong server sa halip na kunin sa isang article, tulad ng pag-benchmark ng VPS bago at pagkatapos ng iba pang pagbabago.

Binabago ng caching ang sitwasyon. Kapag static HTML ang isineserve ng page cache para sa karamihan ng requests, hindi tumatakbo ang PHP para sa mga request na iyon, kaya hindi rin nangyayari ang cron check. Ang isang abalang site na malakas gumamit ng cache ay nagsisimulang kumilos tulad ng tahimik na site sa ibaba.

Sinong bisita ang nag-trigger sa cron sa isang tahimik na site

Kapag walang bisita, walang cron. Ang site na ilang beses lang bisitahin bawat araw ay nagpapatakbo rin ng mga naka-schedule na job nang ilang beses lang bawat araw, sa mga random na oras kung kailan dumarating ang mga bisitang iyon.

Pare-pareho ang anyo ng mga sintomas. Ang post na naka-schedule para sa 09:00 ay nananatiling nasa listahan ng mga post at may markang Missed schedule hanggang sa may mag-load ng page. Hindi tumatakbo ang mga backup plugin sa gabi. Nahuhuli ang update checks, kaya walang ipinapakitang kailangang i-update ang dashboard kahit may nailabas nang security release. Nahuhuli ang pagpapadala ng order emails, renewal notices, at expiry warnings.

Walang error na nalo-log sa alinman dito. Sa pananaw ng WordPress, hindi nahuli ang job dahil hindi naman ito nagsimula.

Hakbang 1: i-off ang visitor trigger sa wp-config.php

Buksan ang /srv/www/example.com/wp-config.php at idagdag ang constant:

define( 'DISABLE_WP_CRON', true );

Ilagay ito sa itaas ng linyang may /* That's all, stop editing! Happy publishing. */, dahil kailangan ng linyang nasa ibaba mismo ng comment na iyon ang wp-settings.php, at sa wp-settings.php ikinakabit ng WordPress ang cron check sa init. Kapag pagkatapos ng require na iyon tinukoy ang constant, huli na ito para may mabago, kaya magmumukhang tama ang file habang patuloy na tumatakbo ang trigger.

Kumpirmahing nasa lugar ito na inaasahan mo:

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

Hindi pinipigilan ng constant ang pag-schedule ng mga event. Patuloy na nagdaragdag ang mga plugin ng mga job sa queue, gaya pa rin ng dati. Pinipigilan lamang nito ang page loads na patakbuhin ang queue, kaya hindi na tumatakbo ang queue hanggang matapos mo ang step 3.

Hindi rin nito bina-block ang mga direct request sa /wp-cron.php. Maaari pa ring i-request ng sinuman ang URL na iyon, at karaniwan itong hindi nakapipinsala dahil ang file ay nagpapatakbo lamang ng mga due na task. Opsyonal ang pag-block dito sa configuration ng web server. Kung iba-block mo ito, hindi na rin gagana ang curl fallback na nasa bandang dulo ng gabay na ito.

Hakbang 2: i-install ang WP-CLI

Ang WP-CLI ang opisyal na command line tool para sa WordPress. Kailangan nito ang PHP command line binary, na hiwalay na package sa PHP module ng web server.

php -v
sudo apt install -y php-cli

I-install ang WP-CLI mula sa phar build. Ito ang inirerekomenda ng opisyal na install guide:

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

Ipinapakita ng php wp-cli.phar --info ang path ng PHP binary, ang PHP version, at ang WP-CLI version. Kung lumabas ang tatlo, gumagana ang phar. Noong August 2026, PHP 7.2.24 ang minimum na tinutukoy ng install guide, at PHP 8.3 ang kasama sa Ubuntu 24.04. Malaki ang agwat ng kasalukuyang server sa minimum na iyon. I-update ito sa susunod gamit ang sudo wp cli update.

Patakbuhin ang WP-CLI bilang user ng site, hindi kailanman bilang root:

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

Bilang root, tumatangging magsimula ang WP-CLI:

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

Iminumungkahi nito ang --allow-root. Huwag itong gamitin dito. Ipinaliwanag ang dahilan sa unang failure mode sa ibaba.

Tandaan din na hindi gumagana ang sudo -u www-data -i dahil /usr/sbin/nologin ang login shell ng account na iyon, kaya makukuha mo ang This account is currently not available.. Kapag direktang ipinasa ang command sa sudo -u, nalalampasan ang login shell kaya gumagana ito nang maayos.

Kumpirmahin ngayon na nakikita mismo ng WordPress ang constant mula sa hakbang 1:

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

Ipinapakita nito ang bool(true). Ang fatal error tungkol sa undefined constant ay nangangahulugang hindi naaabot ang linyang define(). Karaniwan itong nangyayari kapag nailagay ang linyang iyon sa ibaba ng require.

Hakbang 3: idagdag ang cron entry bilang tamang user

Ang tamang user ay ang nagmamay-ari ng mga file na sinusulatan ng PHP. Suriin ang dalawang panig:

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

Sa default na Ubuntu install, parehong sinasagot ng www-data ang mga ito. Kung binigyan mo ang site ng sariling PHP-FPM pool na may sariling user, na karaniwang resulta ng per-site setup sa isang LAMP stack sa Ubuntu 24.04, gamitin ang user na iyon sa lahat ng susunod na hakbang.

Gumawa ng log directory na maaaring sulatan ng user na iyon:

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

I-edit ang crontab ng user na iyon:

sudo crontab -u www-data -e

Magdagdag ng isang linya:

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

Isa-isahin natin. */5 ang nagpapatakbo nito bawat limang minuto. flock -n ang kumukuha ng lock file at agad na humihinto kung hawak pa ito ng naunang run. Ang /usr/local/bin/wp ang absolute path na kailangan ng cron. Pinapahintulutan ng --path na tumakbo ang command mula sa anumang working directory. Ang --due-now ay nagpapatakbo lamang ng mga event na oras nang patakbuhin, sa halip na bawat event sa queue. Ipinapadala ng redirect ang normal na output at mga error sa isang file na maaari mong basahin.

Sa aktuwal na paggamit, hindi optional ang redirect na iyon. Ipinapadala ng cron sa user nito ang output ng job sa pamamagitan ng email, ngunit karamihan ng VPS image ay walang naka-install na mail transfer agent. Pagkatapos, nilala-log ng cron ang (CRON) info (No MTA installed, discarding output) at itinatapon ang output. Pinananatili ng file ang ebidensiya.

Suriin kung na-save ang file:

sudo crontab -u www-data -l

Para sa maraming site, gumamit ng tig-isang linya at pag-iba-ibahin ang minuto upang hindi sabay-sabay magsimula ang mga ito:

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

Patuloy na lalaki ang log hangga't hindi mo ito nire-rotate. Isulat ang /etc/logrotate.d/wp-cron:

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

Suriing tama ang parsing nito nang walang aktuwal na pagbabago: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Hakbang 4: tiyaking aktuwal na naisagawa ang mga naka-schedule na event

Walang pinatutunayan ang isang crontab line na matagumpay na na-save. Magsimula sa pinakamurang pagsusuri at umakyat hanggang sa pagsusuring makapagbibigay ng tiyak na sagot.

Una, sinimulan ba ng cron ang command? Isinusulat ng cron ang mga log nito sa journal gamit ang sarili nitong unit:

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

Ganito ang hitsura ng isang malusog na entry kapag tinanggal ang timestamp at host name sa unahan:

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)

Ibig sabihin ng linyang iyon, sinimulan ng cron ang iyong command bilang www-data. Wala itong sinasabi kung matagumpay na tumakbo ang command.

Ikalawa, may naisagawa ba ang WordPress? Basahin ang log file:

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

Nagpi-print ang WP-CLI ng isang linya para sa bawat event, at pagkatapos ay ng kabuuan:

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

Napupunta sa parehong file ang mga error, na siyang dahilan kung bakit mahalaga ang 2>&1. Karamihan sa mga run ay walang event na kailangang isagawa at kakaunti lamang ang isinusulat. Kaya basahin ang file pagkatapos ng run na alam mong may nakabinbing gawain.

Ikatlo, patunayan ito mula simula hanggang dulo. Mag-schedule ng marker event at panoorin itong mawala:

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

Maghintay ng isang interval, at pagkatapos ay patakbuhin muli ang list command. Wala na ang hook dahil inaalis sa queue ang one-off event kapag naisagawa na ito. Walang plugin na nagre-register ng callback sa pangalan ng hook na iyon, kaya wala nang ibang ginagawa ang pagtakbo nito sa site. Kung nakalista pa rin ang hook pagkalipas ng dalawang interval, hindi pinapatakbo ang queue. Ipinapakita ng unang dalawang pagsusuri kung cron o WP-CLI ang problema.

Huwag gamitin ang wp cron test para rito. Sinusuri ng command na iyon kung gumagana ang pag-spawn na na-trigger ng visitor, at nagkakaroon ito ng error kapag true ang DISABLE_WP_CRON. Sa wastong naka-configure na server, ang error ang inaasahang output at hindi ito fault.

Ang alternatibong systemd timer

Kung ang iba pang naka-iskedyul na gawain ng server ay tumatakbo na bilang systemd services at timer, ilagay din doon ang WordPress. Makikita ang bawat run sa systemctl list-timers, at mapupunta ang output sa journal sa halip na sa file na kailangan mong i-rotate.

Isulat ang /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

Pagkatapos, ang /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

Hindi magpapatakbo ang systemd ng dalawang kopya ng parehong service nang sabay, kaya hindi kailangan ng bersyong ito ang flock. Tinitiyak ng Persistent=true na hahabulin nito ang run na nalaktawan habang naka-off ang machine, na hindi kayang gawin ng crontab entry.

Piliin ang crontab o ang timer. Kapag pareho silang pinatakbo laban sa iisang site, dalawang beses nauubos ang queue, at mapapansin ng mga customer ang duplicate na pagtakbo ng email o order job.

Bakit hindi dapat tumakbo bilang root ang cron job

Ito ang una sa tatlong paraan kung paano nabibigo ang setup. Ilagay ang job sa crontab ng root at hihinto ang WP-CLI bago ito makagawa ng anuman:

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

Hindi kailanman tatakbo ang queue. Kung hindi mo ni-redirect ang output, hindi mo makikita ang mensahe. Mapanganib ang pag-aayos sa pamamagitan ng pagdaragdag ng --allow-root, dahil magiging pagmamay-ari ng root ang bawat file na isinusulat ng plugin habang tumatakbo ang job na iyon. Sa susunod na web request, tatakbo ito bilang www-data at hindi na makakasulat sa mga directory na iyon. Magsisimulang mag-ulat ang site ng mga error gaya ng:

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

Ayusin ang ownership, pagkatapos ay ilipat ang job:

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

Magkahiwalay ang mga file ng crontab ng root at ng www-data. Kaya kapag binura mo ang line sa isa, hindi maaapektuhan ang isa pa. Suriin ang dalawang ito:

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

Bakit nag-uulat ang cron ng wp: not found

Ito ang ikalawang failure. Napakaikli ng PATH na ibinibigay ng cron sa mga user job, /usr/bin:/bin. Ini-install ang WP-CLI sa /usr/local/bin, na wala sa listahang iyon. Nagsisimula ang job, nagfa-fail sa loob ng maliit na bahagi ng isang segundo, at isang linya lamang ang nasa log:

/bin/sh: 1: wp: not found

Tingnan mismo ang environment ng cron sa halip na manghula. Magdagdag ng pansamantalang linya:

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

Basahin ang /tmp/cron-env.txt pagkatapos ng isang interval, at pagkatapos ay tanggalin ang linya. Ang value ng PATH= sa file na iyon ang eksaktong nakukuha ng iyong job.

May dalawang paraan para ayusin ito. Gamitin ang absolute path na /usr/local/bin/wp, gaya sa step 3. O itakda ang PATH nang isang beses sa itaas ng crontab, bago ang bawat linya ng job:

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

Nasa isang level sa ibaba ang kaparehong problema. Nagsisimula ang wp phar sa #!/usr/bin/env php, kaya dapat mahanap din ng shell ang php. Kung nasa labas ng /usr/bin ang PHP, na nangyayari sa custom build at control panel build, makukuha mo ang:

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

Tawagin nang tahasan ang interpreter sa ganitong sitwasyon, halimbawa /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

Bakit naibabalik ng isang minutong interval ang orihinal na problema

Ito ang ikatlong failure. Mas mukhang ligtas ang * * * * * kaysa limang minuto, pero sa abalang site, ibinabalik ka nito sa dating problema. Kung mas matagal matapos ang isang run kaysa sa interval, magsisimula ang kasunod na run habang tumatakbo pa ang una. Pagkalipas ng sampung minuto, may sampung PHP process, at bawat isa ay may sariling memory at database connection.

Direktang hanapin kung may nagkakapatong na mga run:

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

Ang etimes ay ang edad ng process sa segundo. Normal ang isang linya. Kapag maraming linya na mas matanda nang malaki kaysa sa interval mo, nagkakapatong ang mga run. Sa maliit na VPS, maaari itong magdulot ng MySQL Too many connections error o mapatay ng kernel ang PHP upang magbakante ng memory. Makukumpirma mo ito gamit ang sudo dmesg -T | grep -i 'killed process'.

Direktang pinapatakbo ng WP-CLI ang mga event callback sa halip na humiling ng wp-cron.php. Kaya hindi naaangkop dito ang 60 segundong lock na ginagamit ng WordPress laban sa duplicate spawn. Ang flock -n sa entry ng step 3 ang pumipigil sa overlap ngayon. Kapag na-skip ang isang run, agad at tahimik itong lumalabas, ayon sa disenyo. Kailangan mong lutasin ang overlap sa crontab, hindi sa kernel ng host: kahit ang cache-aware na task placement na idinagdag sa Linux kernel 7.2 ay pumipili lamang kung saang core ilalagay ang isang process, at hindi kung ilang process ang sinimulan mo.

Piliin ang interval batay sa pinakamaikling schedule na talagang kailangan mo, at sukatin muna ang tagal ng isang run:

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

Makatuwirang default ang limang minuto: ang post na naka-schedule para sa 09:00 ay maipa-publish pagsapit ng 09:05. Ayos ang labinlimang minuto para sa site na walang kritikal sa oras. Para lamang sa mga store at plugin na gumagamit ng queue at talagang nangangailangan nito ang isang minuto, at dapat gamitin lamang ito kapag alam mong natatapos ang isang run sa loob ng ilang segundo.

Kung hindi mo ma-install ang WP-CLI

May mga host na nagba-block ng shell tools. Ang isang plain HTTP request sa wp-cron.php ay nagpapatakbo sa parehong queue, pero dumadaan ito sa buong web stack:

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

Mga isinusuko mo:

• Nililimitahan ang run ng mga timeout ng web server at PHP-FPM request, kaya maaaring maputol ang mahabang job sa kalagitnaan.
• Dapat valid ang certificate; kung hindi, hihinto ang curl nang may SSL certificate problem. Panatilihing gumagana ang renewal gamit ang Certbot sa nginx.
• Hindi dapat i-cache ng page caching ang wp-cron.php, kung hindi, makakakuha ang mga cron request ng naka-cache na response at walang tatakbo.
• Wala kang output sa bawat event, kaya ang tanging ebidensiyang tumakbo ang isang job ay ang naging epekto nito.

Pinananatiling tahimik ng -sS ang curl kapag matagumpay ang request, habang ipinapakita pa rin nito ang mga error. Ito ang kailangan mo sa isang cron job.

Ano pa ang dapat isama sa schedule ng server

Kapag system cron na ang namamahala sa WordPress queue, ilagay rin sa parehong lugar ang iba pang regular na gawain ng server para madali mong ma-monitor ang lahat. Dapat pamahalaan ng unattended upgrades ang mga security patch ng operating system, sa halip na ilagay ang mga ito sa cron line na mano-mano mong pinapanatili. Ibang desisyon naman ang pag-update ng WordPress plugin at theme: maaaring tuluyang masira ng wp plugin update --all sa crontab ang live site nang 3am habang walang nagmo-monitor, kaya isagawa ito nang sadya, o sa likod ng staging step at backup.

FAQ

Hihinto ba sa pag-publish ng mga naka-schedule na post ang pag-disable sa WP-Cron?

Hindi, basta may ibang nagpapatakbo ng queue. DISABLE_WP_CRON pinipigilan lamang ang page loads na mag-trigger ng queue. Naka-schedule pa rin ang mga event gaya ng dati. Ang post na naka-set para sa 09:00 ay ipa-publish sa unang cron run pagkatapos ng 09:00, kaya kung limang minuto ang interval, mai-publish ito pagsapit ng 09:05. Kung ise-set mo ang constant at hindi mo kailanman idaragdag ang cron entry, mananatili ang post sa listahang may markang Missed schedule hanggang sa may magpatakbo ng queue.

Aling user ang dapat magpatakbo ng WordPress cron job?

Ang user na nagmamay-ari ng mga file na sinusulatan ng PHP. Sa default na Ubuntu install, ito ay www-data. Suriin gamit ang stat -c '%U %G' /srv/www/example.com/wp-content/uploads at ihambing ito sa linyang user = sa configuration ng iyong PHP-FPM pool. Kapag root ang nagpatakbo ng job, hihinto ang WP-CLI at magpapakita ng YIKES error. Kapag pinilit itong patakbuhin gamit ang --allow-root, mag-iiwan ito ng mga file na root ang owner sa loob ng wp-content na hindi na masusulatan ng web server.

Gaano kadalas dapat patakbuhin ng system cron ang WordPress cron?

Ang bawat limang minuto ay angkop para sa karamihan ng mga site. Itugma ang interval sa pinakamaikling schedule na talagang kailangan mo, at panatilihin itong mas mahaba kaysa sa oras ng isang run. Masusukat mo ito sa pamamagitan ng paglalagay ng time bago ang WP-CLI command. Sa busy na site, nagsasapawan ang mga run kapag isang minuto ang interval, maliban kung pinipigilan ito ng flock.

Bakit nagfa-fail ang wp cron test pagkatapos kong i-disable ang WP-Cron?

Dahil sinusuri ng command na iyon ang pag-spawn na na-trigger ng visitor. Nag-uulat ito ng error kapag naka-set sa true ang DISABLE_WP_CRON. Ito ang tamang resulta para sa server na naka-configure sa ganitong paraan. Sa halip, suriin ang system cron path: basahin ang /var/log/wp-cron/example.log, o mag-schedule ng marker event gamit ang wp cron event schedule at tiyaking nawala ito sa wp cron event list pagkatapos ng susunod na run.

Kailangan ko ba ng WP-CLI, o sapat na ang curl papunta sa wp-cron.php?

Gumagana ang curl, at ito ang tamang opsyon kapag hindi ka makapag-install ng WP-CLI. Mas mabagal ito dahil nilo-load nito ang WordPress sa pamamagitan ng web server, at limitado ito ng request timeout. Pinapatakbo ng WP-CLI ang mga event sa command line PHP process na walang web timeout. Nagpi-print din ito ng isang linya para sa bawat event kasama ang duration nito, kaya malinaw sa log kung ano ang tumakbo at kung gaano ito katagal.