I-disable ang WP-Cron at gumamit ng system cron

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

Ang WP-Cron ay task scheduler na built in sa WordPress. Tumatakbo lamang ito kapag may nag-request ng page. Walang bahagi ng WordPress na awtomatikong gumigising para magpatakbo ng mga task. Sa bawat request na hindi galing sa cache, binabasa ng WordPress ang listahan ng mga naka-schedule na job. Kung may due na job, nagpapadala ito ng pangalawang 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 nakatakdang schedule, may isang libong bisita man ang site sa minutong iyon o wala.

Dalawang linya ang aktuwal na gumagawa ng trabaho: isang constant sa wp-config.php at isang crontab entry. Lahat ng iba pa sa guide na ito ay mga detalyeng hindi ipinapakita ng dalawang linyang iyon. Kabilang dito kung aling user dapat patakbuhin ang job, kung paano mapapatunayang aktuwal na tumakbo ang mga naka-schedule na event, at ang tatlong paraan kung paano mabibigo ang setup nang walang lumalabas na mensahe sa site.

Ginagamit ng mga halimbawa ang /srv/www/example.com bilang WordPress directory at www-data bilang web server user. Palitan ang mga path at user na ito saanman ng sarili mong values.

Anong bisita ang nag-trigger ng cron cost sa isang busy na site

Bawat request na hindi galing sa cache ay nagbabayad para sa check. 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. Ang PHP worker ang naghihintay. Sa isang maliit na VPS na nagpapatakbo ng PHP-FPM na may pm.max_children = 5, maaaring ma-occupy ng isang mabagal na scheduled job ang one-fifth ng PHP capacity sa buong tagal ng execution nito. Malamang din itong ma-trigger sa pinakabusy na minuto, dahil dito pinakamaraming page load.

Nililimitahan ng WordPress ang mga duplicate. Kumukuha ito ng lock na may lifetime na WP_CRON_LOCK_TIMEOUT, na 60 seconds bilang default, kaya hindi bawat sabay-sabay na bisita ay magsisimula ng sariling run. Nililimitahan ng lock ang duplication. Hindi nito inililipat ang trabaho palabas ng 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-libo bawat araw ay tunay na cost. Ito ang uri ng bilang na dapat mong sukatin sa sarili mong server, sa halip na basahin lang sa isang article, gaya ng pag-benchmark ng VPS bago at pagkatapos ng anumang pagbabago.

Binabago ng caching ang sitwasyon. Kung static HTML ang inihahatid ng page cache para sa karamihan ng mga request, hindi tumatakbo ang PHP para sa mga request na iyon, kaya hindi rin nangyayari ang cron check. Ang isang busy na site na heavily cached ay nagsisimulang kumilos na parang tahimik na site sa ibaba.

Anong visitor ang nag-trigger sa cron sa isang tahimik na site

Walang visitor, walang cron. Ang site na kaunti lang ang bisita bawat araw ay nagpapatakbo ng mga naka-schedule na job nang kaunting beses din bawat araw, sa mga random na oras kung kailan dumating ang mga bisitang iyon.

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

Wala sa mga ito ang nagla-log ng error. Sa pananaw ng WordPress, hindi nahuli ang job dahil hindi ito kailanman nagsimula.

Hakbang 1: i-disable 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 /* That's all, stop editing! Happy publishing. */, dahil kailangan ng linyang nasa ilalim 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 dinefine ang constant, huli na ito para may mabago, kaya mukhang tama ang file ngunit patuloy pa ring tumatakbo ang trigger.

Kumpirmahing nasa inaasahang lokasyon ang linya:

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 ng dati. Pinipigilan lamang nito ang page loads na patakbuhin ang queue, kaya hindi na tatakbo ang queue hanggang matapos mo ang step 3.

Hindi rin nito hinaharangan ang mga direktang request sa /wp-cron.php. Maaari pa ring i-request ng kahit sino ang URL na iyon, at karaniwan itong ligtas dahil pinapatakbo lamang ng file ang mga due na event. Optional ang pag-block dito sa web server config. Kung i-block mo ito, hindi na rin gagana ang curl fallback malapit sa 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, gaya ng 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

Ang php wp-cli.phar --info ay nagpi-print ng path ng PHP binary, bersyon ng PHP, at bersyon ng WP-CLI. Kung lumabas ang tatlo, gumagana ang phar. Noong August 2026, PHP 7.2.24 ang minimum na nakasaad sa install guide, at PHP 8.3 ang kasama sa Ubuntu 24.04, kaya lampas dito ang kasalukuyang server. I-update ito sa ibang pagkakataon gamit ang sudo wp cli update.

Patakbuhin ang WP-CLI bilang user ng site, at 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. Ipinaliliwanag 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, nalalaktawan ang login shell kaya maayos itong tumatakbo.

Ngayon, kumpirmahing 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 );'

Ipi-print nito ang bool(true). Ang fatal error tungkol sa undefined constant ay nangangahulugang hindi naaabot ang linyang define(). Karaniwan itong nangyayari kapag nailagay ang linya 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 www-data ang sagot. Kung binigyan mo ang site ng sarili nitong 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 para 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. Kumukuha ang flock -n ng lock file at agad na humihinto kung hawak pa ito ng naunang run. Ang /usr/local/bin/wp ay ang absolute path na kailangan ng cron. Hinahayaan ng --path na tumakbo ang command mula sa anumang working directory. --due-now lamang ang nagpapatakbo sa mga event na dumating na ang oras, sa halip na sa lahat ng 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 mail, walang naka-install na mail transfer agent sa karamihan ng VPS images, at pagkatapos ay nilala-log ng cron ang (CRON) info (No MTA installed, discarding output) at itinatapon ang output. Pinananatili ng file ang ebidensiya.

Suriin ang na-save na file:

sudo crontab -u www-data -l

Para sa ilang 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 maliban kung i-rotate mo ito. 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: kumpirmahing talagang naisagawa ang mga naka-schedule na event

Walang napapatunayan ang isang crontab line na matagumpay na na-save. Magsimula sa pinakamurang check, hanggang sa check na talagang makapagpapatunay sa resulta.

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

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

Ganito ang hitsura ng isang maayos na entry, kapag inalis 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 command mo 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, kasunod ang kabuuan:

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

Sa parehong file napupunta ang mga error, at iyon ang pangunahing gamit ng 2>&1. Kadalasang walang due na event at kaunti lamang ang maisusulat sa karamihan ng mga run, kaya basahin ang file pagkatapos ng run na alam mong may nakapilang trabaho.

Ikatlo, patunayan ito mula simula hanggang dulo. Mag-schedule ng marker event at tingnan kung mawawala ito:

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, pagkatapos ay patakbuhin muli ang list command. Wala na ang hook dahil inaalis sa queue ang one-off event kapag tumakbo ito. Walang plugin na nagre-register ng callback para sa hook name na iyon, kaya wala nang ibang ginagawa sa site ang pagtakbo nito. Kung nakalista pa rin ang hook pagkalipas ng dalawang interval, hindi pinapatakbo ang queue. Ipinapakita ng unang dalawang check kung cron o WP-CLI ang may problema.

Huwag gamitin ang wp cron test para rito. Tinitingnan 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 server na tama ang configuration, ang error ang inaasahang output at hindi ito fault.

Alternatibo sa systemd timer

Kung ang iba pang scheduled work ng server ay tumatakbo na bilang systemd services at timers, ilagay din doon ang WordPress. Sa ganitong paraan, 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 hindi naisagawa habang naka-off ang machine, na hindi kayang gawin ng crontab entry.

Pumili ng crontab o timer. Kapag parehong tumatakbo laban sa iisang site, dalawang beses nade-drain ang queue, at mapapansin ng iyong mga customer ang duplicate na pagtakbo ng email o order job.

Bakit hindi dapat tumakbo bilang root ang cron job

Ito ang unang paraan kung paano nabibigo ang setup. Kapag inilagay ang job sa crontab ng root, humihinto ang WP-CLI bago ito makagawa ng anuman:

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

Hindi kailanman tumatakbo ang queue. Kung hindi mo nire-redirect ang output, hindi mo makikita ang mensahe. Delikado ang pag-aayos sa pamamagitan ng pagdaragdag ng --allow-root, dahil ang bawat file na isinusulat ng plugin habang tumatakbo ang job ay magiging pagmamay-ari ng root. Sa susunod na web request, tumatakbo ito bilang www-data at hindi makapagsulat 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 na file ang crontab ng root at crontab ng www-data. Kaya hindi maaapektuhan ang isa kapag dinelete ang line mula sa isa pa. Suriin ang dalawa:

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, nabibigo sa loob ng wala pang 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 makalipas ang isang interval, pagkatapos ay tanggalin ang linya. Ang value na 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 ng nasa step 3. O itakda ang PATH nang isang beses sa itaas ng crontab, bago ang bawat job line:

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

Nangyayari rin ang parehong problema sa isang level sa ibaba. 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 muling lumilitaw ang orihinal na problema sa one-minute interval

Ito ang ikatlong failure. Mas ligtas sa tingin ang * * * * * kaysa sa five minutes, pero sa isang busy na site, ibinabalik ka nito sa dating problema. Kung mas matagal matapos ang isang run kaysa sa interval, magsisimula ang susunod na run habang tumatakbo pa ang una. Pagkalipas ng ten minutes, may ten PHP process na, at bawat isa ay may sariling memory at sariling database connection.

Direktang tingnan kung nagkakaroon ng pileup:

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

Ang etimes ay ang edad ng process sa seconds. Healthy ang isang line. Kapag maraming line na may age na mas mataas nang malaki kaysa sa interval mo, nagsasabay-sabay ang mga run. Sa isang maliit na VPS, maaari itong humantong sa MySQL Too many connections error, o sa pagpatay ng kernel sa PHP upang makabawi ng memory. Makukumpirma mo ito gamit ang sudo dmesg -T | grep -i 'killed process'.

Direktang pinapatakbo ng WP-CLI ang event callbacks sa halip na humiling ng wp-cron.php, kaya hindi nalalapat dito ang 60-second lock na ginagamit ng WordPress laban sa duplicate spawns. Ang flock -n sa step 3 entry ang pumipigil sa overlap ngayon. Kapag may run na nalaktawan, agad at tahimik itong nag-e-exit, ayon sa disenyo.

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 five minutes: ang post na naka-schedule para sa 09:00 ay mai-publish pagsapit ng 09:05. Ayos ang fifteen minutes para sa site na walang time-critical na content. Ang one minute ay para sa mga store at queue-driven plugin na talagang nangangailangan nito, at gamitin lamang kapag alam mong natatapos ang isang run sa loob ng ilang segundo.

Kung hindi mo ma-install ang WP-CLI

Hinaharangan ng ilang host ang mga shell tool. Ang isang plain HTTP request sa wp-cron.php ay nagpapatakbo ng parehong queue, pero dumaraan ito sa buong web stack:

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

Ang mga isinusuko mo, malinaw:

• Nililimitahan ang run ng mga timeout ng web server at PHP-FPM request, kaya maaaring maputol sa kalagitnaan ang isang matagal na job.
• Dapat valid ang certificate, kung hindi ay hihinto ang curl na 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 ay cached response ang matatanggap ng mga cron request at walang tatakbo.
• Wala kang output para sa bawat event, kaya ang tanging patunay na tumakbo ang isang job ay ang naging epekto nito.

Pinananatili ng -sS na tahimik ang curl kapag matagumpay ang operasyon habang ipinapakita pa rin 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 sa parehong lugar ang iba pang regular na gawain ng server para madali mong makita at masubaybayan. Ang security patch ng operating system ay dapat pamahalaan ng unattended upgrades, hindi ng cron line na mano-mano mong pinapanatili. Ibang desisyon ang pag-update ng WordPress plugin at theme: maaaring masira ng wp plugin update --all sa crontab ang live site nang 3am habang walang nagbabantay. Isagawa ito nang planado, o pagkatapos ng staging step at backup.

FAQ

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

Hindi, basta may ibang nagpapatakbo ng queue. DISABLE_WP_CRON ay pumipigil lamang sa pag-trigger ng queue ng mga page load. Naka-schedule pa rin ang mga event gaya ng dati. Ang post na itinakda para sa 09:00 ay ipa-publish sa unang cron run pagkalipas ng 09:00, kaya kung limang minuto ang pagitan, mai-publish ito pagsapit ng 09:05. Kung ise-set mo ang constant at hindi ka magdadagdag ng cron entry, mananatili ang post sa listahan na 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, na www-data sa default na Ubuntu install. Suriin gamit ang stat -c '%U %G' /srv/www/example.com/wp-content/uploads at ikumpara ito sa linyang user = sa PHP-FPM pool config. Kapag root ang nagpatakbo ng job, hihinto ang WP-CLI at magpapakita ng YIKES error. Kapag pinilit itong patakbuhin gamit ang --allow-root, magkakaroon ng mga file na pagmamay-ari ng root sa loob ng wp-content na hindi na maisusulatan ng web server.

Gaano kadalas dapat patakbuhin ng system cron ang WordPress cron?

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

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

Dahil sinusuri ng command na iyon ang pag-trigger ng spawning mula sa visitor, at nag-uulat ito ng error kapag naka-set sa true ang DISABLE_WP_CRON. Ito ang tamang resulta sa server na ganito ang configuration. 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 na 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 nalilimitahan ito ng request timeout. Pinapatakbo ng WP-CLI ang mga event sa isang command-line PHP process na walang web timeout. Nagpi-print din ito ng isang linya para sa bawat event kasama ang duration nito, kaya eksaktong ipinapakita ng log kung ano ang tumakbo at kung gaano ito katagal.