Cara Disable wp-cron dan Guna System Cron Linux

Apakah itu wp-cron, dan mengapa system cron menggantikannya

WP-Cron ialah penjadual tugas yang terbina dalam WordPress, dan ia hanya berjalan apabila seseorang meminta sesuatu halaman. Tiada apa-apa di dalam WordPress yang akan aktif dengan sendirinya. Pada setiap permintaan yang tidak dihidangkan daripada cache, WordPress membaca senarai tugas berjadual, dan jika ada tugas yang perlu dilaksanakan, ia akan menghantar permintaan HTTP kedua kepada dirinya sendiri di /wp-cron.php untuk melakukan kerja tersebut. Memindahkan tugas itu ke system cron memberikan anda satu pelaksanaan yang boleh diramal pada jadual tetap, tidak kira sama ada laman web tersebut mempunyai seribu pelawat pada minit itu atau tiada langsung.

Dua baris kod melakukan kerja sebenar: satu pemalar dalam wp-config.php, dan satu entri crontab. Segala perkara lain dalam panduan ini adalah bahagian yang tidak dinyatakan oleh kedua-dua baris tersebut. Pengguna mana yang perlu menjalankan tugas tersebut, cara membuktikan acara berjadual benar-benar telah dilaksanakan, dan tiga cara persediaan ini gagal tanpa mencetak apa-apa pada laman web.

Contoh-contoh ini menggunakan /srv/www/example.com sebagai direktori WordPress dan www-data sebagai pengguna pelayan web. Gantikan dengan laluan dan pengguna anda sendiri di mana-mana bahagian.

Pengunjung manakah yang mencetuskan kos cron pada tapak sibuk

Setiap permintaan yang tidak dicache akan menanggung kos semakan tersebut. WordPress memuatkan pilihan cron, membandingkan cap masa, dan apabila tiba masanya, ia memanggil spawn_cron(), yang menghantar permintaan loopback tidak menyekat ke /wp-cron.php. Pengunjung tidak menunggu hasilnya. Sebaliknya, pekerja PHP yang melakukannya. Pada VPS kecil yang menjalankan PHP-FPM dengan pm.max_children = 5, satu tugasan berjadual yang perlahan akan memegang satu perlima daripada kapasiti PHP anda selama tempoh ia berjalan, dan ia berkemungkinan besar dicetuskan semasa minit paling sibuk anda, kerana itulah waktu muat halaman paling kerap berlaku.

WordPress memang mengehadkan pendua. Ia mengambil kunci yang mempunyai jangka hayat WP_CRON_LOCK_TIMEOUT, iaitu 60 saat secara lalai, supaya pengunjung yang datang serentak tidak memulakan proses yang sama. Kunci ini mengehadkan penduaan. Ia tidak mengalihkan beban kerja tersebut keluar daripada laluan permintaan.

Kira kekerapan ia dicetuskan pada pelayan anda sendiri sebelum membuat keputusan sama ada ia penting. Setiap loopback akan muncul dalam log akses pelayan web:

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

Apache menulis ke /var/log/apache2/access.log sebagai gantinya. Kiraan dalam ribuan sehari merupakan kos yang nyata, dan ia adalah jenis angka yang perlu anda ukur pada mesin anda sendiri dan bukannya sekadar membaca dalam artikel, sama seperti cara anda menanda aras VPS sebelum dan selepas melakukan sebarang perubahan lain.

Caching mengubah keadaan. Jika cache halaman melayani kebanyakan permintaan sebagai HTML statik, PHP tidak akan berjalan untuk permintaan tersebut, jadi semakan cron tidak akan berlaku. Tapak sibuk yang mempunyai cache yang berat akan mula berkelakuan seperti tapak yang kurang trafik di bawah.

Mengapa cron yang dicetuskan pelawat tergendala pada laman yang kurang trafik

Tiada pelawat bermakna tiada cron. Laman yang hanya menerima segelintir kunjungan sehari akan menjalankan tugasan berjadualnya hanya beberapa kali sehari, pada saat rawak apabila kunjungan tersebut berlaku.

Gejala yang dialami adalah serupa. Catatan yang dijadualkan pada 09:00 kekal dalam senarai catatan dengan tanda Missed schedule sehingga seseorang memuatkan halaman. Pemalam sandaran (backup plugins) tidak berjalan pada waktu malam. Semakan kemas kini menjadi perlahan, menyebabkan papan pemuka tidak menunjukkan sebarang kemas kini walaupun keluaran keselamatan sudah tersedia. E-mel pesanan, notis pembaharuan dan amaran tamat tempoh dihantar lewat.

Tiada satu pun daripada perkara ini mencatatkan ralat. Tugasan tersebut tidak dianggap lewat oleh WordPress, kerana ia tidak pernah dimulakan.

Langkah 1: matikan pencetus pelawat dalam wp-config.php

Buka /srv/www/example.com/wp-config.php dan tambah pemalar berikut:

define( 'DISABLE_WP_CRON', true );

Letakkannya di atas baris yang tertulis /* That's all, stop editing! Happy publishing. */, kerana baris tepat di bawah komen tersebut memerlukan wp-settings.php, dan wp-settings.php ialah tempat WordPress menyangkut (hook) semakan cron pada init. Pemalar yang ditakrifkan selepas require tersebut ditetapkan terlalu lewat untuk mengubah apa-apa, dan fail tersebut kelihatan betul sedangkan pencetus terus berjalan.

Sahkan baris tersebut berada di tempat yang anda sangkakan:

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

Pemalar ini tidak menghentikan penjadualan acara. Pemalam akan terus menambah tugasan ke dalam baris gilir, sama seperti sebelumnya. Ia hanya menghalang muatan halaman daripada menjalankan baris gilir tersebut, yang bermaksud baris gilir itu tidak akan berjalan sehingga anda menyelesaikan langkah 3.

Ia juga tidak menyekat permintaan terus kepada /wp-cron.php. Sesiapa sahaja masih boleh meminta URL tersebut, dan perkara ini biasanya tidak berbahaya kerana fail tersebut hanya menjalankan apa yang perlu. Menyekatnya dalam konfigurasi pelayan web anda adalah pilihan. Jika anda menyekatnya, mekanisme sandaran curl berhampiran penghujung panduan ini juga akan berhenti berfungsi.

Langkah 2: memasang WP-CLI

WP-CLI ialah alat baris perintah rasmi untuk WordPress. Ia memerlukan binari baris perintah PHP, iaitu pakej yang berasingan daripada modul PHP pelayan web.

php -v
sudo apt install -y php-cli

Pasang WP-CLI daripada binaan phar, seperti yang disyorkan oleh panduan pemasangan rasmi:

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 mencetak laluan binari PHP, versi PHP dan versi WP-CLI. Jika ia mencetak ketiga-tiganya, phar tersebut berfungsi. Setakat Ogos 2026, panduan pemasangan menetapkan PHP 7.2.24 sebagai minimum, dan Ubuntu 24.04 membekalkan PHP 8.3, jadi pelayan semasa sudah melepasi keperluan tersebut. Kemas kini kemudian dengan sudo wp cli update.

Jalankan WP-CLI sebagai pengguna tapak, jangan sekali-kali sebagai root:

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

Sebagai root, WP-CLI enggan bermula:

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

Ia mencadangkan --allow-root. Jangan gunakan arahan itu di sini. Sebabnya dinyatakan dalam mod kegagalan pertama di bawah.

Perhatikan juga bahawa sudo -u www-data -i tidak berfungsi, kerana shell log masuk akaun tersebut ialah /usr/sbin/nologin dan anda akan mendapat This account is currently not available.. Menghantar arahan terus kepada sudo -u melangkau shell log masuk, jadi ia berjalan dengan lancar.

Sekarang, sahkan bahawa WordPress sendiri melihat pemalar daripada langkah 1:

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

Ia akan mencetak bool(true). Ralat maut mengenai pemalar yang tidak ditakrifkan bermakna baris define() tidak dicapai, yang biasanya bermaksud ia diletakkan di bawah require.

Langkah 3: tambah entri cron sebagai pengguna yang betul

Pengguna yang betul ialah pemilik fail yang ditulis oleh PHP. Semak kedua-dua pihak:

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

Pada pemasangan lalai Ubuntu, kedua-duanya memberikan jawapan www-data. Jika anda memberikan tapak tersebut pool PHP-FPM sendiri dengan pengguna tersendiri, yang merupakan pengakhiran biasa bagi persediaan setiap tapak pada timbunan LAMP pada Ubuntu 24.04, gunakan pengguna tersebut untuk semua langkah di bawah.

Buat direktori log yang boleh ditulis oleh pengguna tersebut:

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

Edit crontab pengguna tersebut:

sudo crontab -u www-data -e

Tambah satu baris:

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

Satu demi satu. */5 menjalankannya setiap lima minit. flock -n mengambil fail kunci dan berhenti serta-merta jika proses sebelumnya masih memegangnya. /usr/local/bin/wp ialah laluan mutlak, yang diperlukan oleh cron. --path membolehkan arahan dijalankan dari mana-mana direktori kerja. --due-now hanya menjalankan acara yang telah tiba masanya, bukannya setiap acara dalam baris gilir. Ubah hala tersebut menghantar output biasa dan ralat ke satu fail yang boleh anda baca.

Ubah hala itu sebenarnya bukanlah pilihan. Cron menghantar output kerja ke e-mel penggunanya, kebanyakan imej VPS tidak mempunyai ejen pemindahan mel yang dipasang, dan cron kemudian merekodkan (CRON) info (No MTA installed, discarding output) serta membuang output tersebut. Fail log menyimpan bukti tersebut.

Semak fail yang disimpan:

sudo crontab -u www-data -l

Untuk beberapa tapak, gunakan satu baris bagi setiap tapak dengan minit yang diselang-selikan supaya ia tidak bermula serentak:

*/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 akan terus membesar kecuali anda melakukan rotasi. Tulis /etc/logrotate.d/wp-cron:

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

Semak sama ada ia diurai tanpa mengubah apa-apa: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Langkah 4: sahkan acara berjadual benar-benar dijalankan

Baris crontab yang disimpan dengan jayanya tidak membuktikan apa-apa. Lakukan pemeriksaan bermula daripada yang paling mudah sehingga yang paling muktamad.

Pertama, adakah cron memulakan arahan tersebut? Cron mencatat log ke dalam journal di bawah unitnya sendiri:

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

Entri yang sihat kelihatan seperti ini, dengan cap masa dan nama hos dibuang daripada bahagian hadapan:

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)

Baris tersebut bermaksud cron memulakan arahan anda sebagai www-data. Ia tidak menyatakan sama ada arahan tersebut berjaya dilaksanakan.

Kedua, adakah WordPress melaksanakan apa-apa? Baca fail log:

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

WP-CLI mencetak satu baris bagi setiap acara, kemudian jumlah keseluruhan:

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

Ralat akan direkodkan dalam fail yang sama, itulah tujuan utama 2>&1. Kebanyakan pelaksanaan tidak akan mempunyai tugasan yang perlu dilakukan dan hanya menulis sedikit maklumat, jadi baca fail tersebut selepas satu sesi pelaksanaan yang anda tahu mempunyai tugasan menunggu.

Ketiga, buktikan ia dari hujung ke hujung. Jadualkan satu acara penanda dan perhatikan ia hilang:

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

Tunggu selama satu selang masa, kemudian jalankan arahan senarai sekali lagi. Hook tersebut telah hilang, kerana acara sekali jalan akan dialih keluar daripada baris gilir apabila ia dijalankan. Tiada pemalam yang mendaftarkan callback pada nama hook tersebut, jadi menjalankannya tidak akan melakukan apa-apa lagi pada laman web. Jika hook tersebut masih disenaraikan selepas dua selang masa, baris gilir tidak dijalankan, dan dua pemeriksaan pertama akan memberitahu anda sama ada masalahnya berpunca daripada cron atau WP-CLI.

Jangan gunakan wp cron test untuk tujuan ini. Arahan tersebut menyemak sama ada pencetusan oleh pelawat berfungsi, dan ia akan mengeluarkan ralat apabila DISABLE_WP_CRON bernilai true. Pada pelayan yang dikonfigurasikan dengan betul, ralat tersebut adalah output yang dijangkakan, bukannya satu kegagalan.

Alternatif pemasa systemd

Jika tugasan berjadual lain pada pelayan sudah dijalankan sebagai perkhidmatan dan pemasa systemd, letakkan juga WordPress di sana. Setiap pelaksanaan akan dipaparkan dalam systemctl list-timers, dan output akan dihantar ke jurnal dan bukannya ke fail yang perlu anda putarkan (rotate).

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

Kemudian /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 tidak akan menjalankan dua salinan perkhidmatan yang sama pada satu masa, jadi versi ini tidak memerlukan flock. Persistent=true membolehkan ia melaksanakan tugasan yang terlepas semasa mesin dimatikan, sesuatu yang tidak boleh dilakukan oleh entri crontab.

Pilih sama ada crontab atau pemasa. Menjalankan kedua-duanya pada tapak yang sama bermakna baris gilir dikosongkan dua kali, dan pelaksanaan pendua bagi tugasan e-mel atau pesanan akan dapat dilihat oleh pelanggan anda.

Mengapa cron job tidak boleh dijalankan sebagai root

Ini adalah cara pertama daripada tiga cara persediaan ini gagal. Letakkan tugasan tersebut dalam crontab milik root dan WP-CLI akan berhenti sebelum ia melakukan sebarang tindakan:

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

Baris gilir tidak pernah berjalan, dan jika anda tidak mengubah hala output, anda tidak akan melihat mesej tersebut. Penyelesaian yang berbahaya adalah dengan menambah --allow-root, kerana setiap fail yang ditulis oleh pemalam semasa proses itu akan menjadi milik root. Permintaan web seterusnya berjalan sebagai www-data, tidak boleh menulis ke dalam direktori tersebut, dan tapak web mula melaporkan perkara seperti:

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

Baiki pemilikan fail, kemudian pindahkan tugasan tersebut:

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

Crontab milik root dan crontab milik www-data adalah fail yang berasingan, jadi memadamkan baris daripada satu fail tidak akan menjejaskan fail yang lain. Semak kedua-duanya:

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

Mengapa cron melaporkan wp: not found

Ini adalah kegagalan kali kedua. Cron memberikan PATH yang sangat terhad kepada tugas pengguna, iaitu /usr/bin:/bin. WP-CLI dipasang ke dalam /usr/local/bin, yang tidak tersenarai dalam PATH tersebut. Tugas dimulakan, gagal dalam sekelip mata, dan log hanya mengandungi satu baris:

/bin/sh: 1: wp: not found

Semak persekitaran cron sendiri daripada meneka. Tambahkan satu baris sementara:

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

Baca /tmp/cron-env.txt selepas satu selang masa, kemudian padamkan baris tersebut. Nilai PATH= dalam fail itu adalah tepat apa yang diterima oleh tugas anda.

Terdapat dua cara penyelesaian. Gunakan laluan mutlak /usr/local/bin/wp, seperti dalam langkah 3. Atau tetapkan PATH sekali sahaja di bahagian atas crontab, di atas setiap baris tugas:

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

Perangkap yang sama wujud satu tahap di bawah. Fail phar wp bermula dengan #!/usr/bin/env php, jadi shell mesti dapat mencari php juga. Jika PHP berada di luar /usr/bin, yang sering berlaku pada binaan tersuai dan binaan panel kawalan, anda akan mendapat:

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

Panggil interpreter secara eksplisit dalam kes tersebut, contohnya /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

Mengapa selang masa satu minit menghasilkan semula masalah asal

Ini adalah kegagalan ketiga. * * * * * terasa lebih selamat daripada lima minit, dan pada tapak yang sibuk, ia mengembalikan anda ke titik permulaan. Jika satu proses mengambil masa lebih lama daripada selang masa tersebut, proses seterusnya akan bermula semasa proses pertama masih berjalan. Sepuluh minit kemudian, terdapat sepuluh proses PHP, setiap satunya memegang memori dan sambungan pangkalan datanya sendiri.

Cari timbunan proses secara terus:

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

etimes ialah usia proses dalam saat. Satu baris menunjukkan keadaan yang sihat. Beberapa baris dengan usia yang jauh melebihi selang masa anda bermakna proses sedang bertindan, dan pada VPS kecil, ini berakhir dengan ralat Too many connections MySQL, atau kernel menamatkan PHP untuk menuntut semula memori, yang boleh anda sahkan dengan sudo dmesg -T | grep -i 'killed process'.

WP-CLI menjalankan panggil balik acara (event callbacks) secara terus dan bukannya meminta wp-cron.php, jadi kunci 60 saat yang digunakan WordPress untuk menghalang pertindihan proses tidak terpakai di sini. flock -n dalam entri langkah 3 adalah perkara yang menghalang pertindihan sekarang. Proses yang dilangkau akan keluar serta-merta dan secara senyap, mengikut reka bentuknya.

Pilih selang masa berdasarkan jadual paling singkat yang benar-benar anda perlukan, dan ukur tempoh proses terlebih dahulu:

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

Lima minit ialah tetapan lalai yang munasabah: hantaran yang dijadualkan pada 09:00 akan diterbitkan menjelang 09:05. Lima belas minit adalah memadai untuk tapak yang tidak mempunyai keperluan kritikal dari segi masa. Satu minit hanya sesuai untuk kedai dan pemalam berasaskan baris gilir (queue-driven) yang benar-benar memerlukannya, dan hanya selepas anda mengetahui bahawa satu proses selesai dalam beberapa saat.

Jika anda tidak dapat memasang WP-CLI

Sesetengah hos menyekat alatan shell. Permintaan HTTP biasa ke wp-cron.php menjalankan baris gilir yang sama, cuma ia melalui keseluruhan tindanan web:

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

Perkara yang anda korbankan, secara jelas:

• Pelaksanaan dihadkan oleh tamat masa permintaan pelayan web dan PHP-FPM, jadi tugasan yang panjang boleh terputus di tengah jalan.
• Sijil mestilah sah atau curl akan terhenti dengan SSL certificate problem, jadi pastikan pembaharuan berfungsi dengan Certbot pada nginx.
• Penimbalan halaman (page caching) tidak boleh menimbal wp-cron.php, jika tidak permintaan cron akan mendapat respons tertimbal dan tiada apa-apa yang akan berjalan.
• Anda tidak mendapat output bagi setiap peristiwa, jadi satu-satunya bukti tugasan telah berjalan adalah kesan yang dihasilkannya.

-sS memastikan curl senyap apabila berjaya sambil tetap mencetak ralat, iaitu perkara yang anda perlukan dalam tugasan cron.

Perkara lain yang perlu dimasukkan ke dalam jadual pelayan

Apabila cron sistem menguruskan baris gilir WordPress, letakkan semua kerja rutin pelayan yang lain di tempat yang sama supaya ia mudah dipantau. Tampalan keselamatan sistem pengendalian harus diuruskan oleh unattended upgrades dan bukannya melalui baris cron yang diselenggara secara manual. Kemas kini pemalam dan tema WordPress memerlukan pertimbangan berbeza: wp plugin update --all di dalam crontab boleh menyebabkan tapak web yang sedang beroperasi tergendala pada pukul 3 pagi tanpa disedari. Oleh itu, jalankan kemas kini tersebut secara sengaja, atau lakukan melalui langkah staging dan sandaran terlebih dahulu.

FAQ

Adakah melumpuhkan WP-Cron menghalang hantaran berjadual daripada diterbitkan?

Tidak, selagi ada proses lain yang menjalankan baris gilir tersebut. DISABLE_WP_CRON hanya menghentikan pemuatan halaman daripada mencetuskan baris gilir. Acara masih dijadualkan seperti biasa. Hantaran yang ditetapkan untuk 09:00 akan diterbitkan pada larian cron pertama selepas 09:00, jadi selang masa lima minit akan menerbitkannya menjelang 09:05. Jika anda menetapkan pemalar tersebut tetapi tidak menambah entri cron, hantaran itu akan kekal dalam senarai dengan tanda Missed schedule sehingga sesuatu menjalankan baris gilir tersebut.

Pengguna manakah yang harus menjalankan kerja cron WordPress?

Pengguna yang memiliki fail yang ditulis oleh PHP, iaitu www-data pada pemasangan Ubuntu lalai. Semak dengan stat -c '%U %G' /srv/www/example.com/wp-content/uploads dan bandingkan dengan baris user = dalam konfigurasi pool PHP-FPM anda. Menjalankan kerja sebagai root akan menyebabkan WP-CLI berhenti dengan ralat YIKES, dan memaksanya berjalan dengan --allow-root akan meninggalkan fail milik root di dalam wp-content yang tidak boleh ditulis oleh pelayan web selepas itu.

Berapa kerap sistem cron harus menjalankan cron WordPress?

Setiap lima minit adalah memadai untuk kebanyakan laman. Padankan selang masa dengan jadual paling singkat yang anda benar-benar perlukan, dan pastikan ia berada pada tempoh yang selesa melebihi masa yang diambil untuk satu larian, yang boleh anda ukur dengan meletakkan time di hadapan arahan WP-CLI. Selang masa satu minit akan menyebabkan larian bertindih antara satu sama lain pada laman yang sibuk melainkan flock mengawal larian tersebut.

Mengapa wp cron test gagal selepas saya melumpuhkan WP-Cron?

Kerana arahan tersebut menguji pencetusan yang dipacu oleh pelawat, dan ia melaporkan ralat apabila DISABLE_WP_CRON ditetapkan kepada true. Itu adalah hasil yang betul pada pelayan yang dikonfigurasikan dengan cara ini. Sebaliknya, semak laluan cron sistem: baca /var/log/wp-cron/example.log, atau jadualkan acara penanda dengan wp cron event schedule dan sahkan bahawa ia telah hilang daripada wp cron event list selepas larian seterusnya.

Adakah saya memerlukan WP-CLI, atau adakah curl ke wp-cron.php sudah mencukupi?

Curl berfungsi, dan ia adalah jawapan yang tepat apabila anda tidak boleh memasang WP-CLI. Ia lebih perlahan kerana ia memuatkan WordPress melalui pelayan web, dan ia dihadkan oleh tamat masa permintaan (request timeout). WP-CLI menjalankan acara dalam proses PHP baris arahan tanpa tamat masa web, dan mencetak satu baris bagi setiap acara berserta tempohnya, jadi log memberitahu anda dengan tepat apa yang telah dijalankan dan berapa lama masa yang diambil.