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 yang dijadualkan, dan jika tiba masanya, ia akan menghantar permintaan HTTP kedua kembali kepada dirinya sendiri di /wp-cron.php untuk melaksanakan tugas tersebut. Memindahkan tugas itu ke system cron memberikan anda satu pelaksanaan yang boleh dijangka pada jadual tetap, tidak kira sama ada tapak 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 yang perlu menjalankan tugas tersebut, cara untuk membuktikan acara yang dijadualkan benar-benar telah dilaksanakan, dan tiga cara persediaan tersebut gagal tanpa mencetak apa-apa pada tapak tersebut.

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 opsyen cron, membandingkan cap masa, dan apabila tiba masanya, ia memanggil spawn_cron(), yang menghantar permintaan loopback tidak menyekat (non-blocking) ke /wp-cron.php. Pengunjung tidak perlu menunggu hasilnya. Seorang pekerja PHP yang perlu menunggunya. Pada VPS kecil yang menjalankan PHP-FPM dengan pm.max_children = 5, satu tugasan berjadual yang perlahan akan menahan satu perlima daripada kapasiti PHP anda selama proses itu berjalan, dan ia berkemungkinan besar dicetuskan semasa minit paling sibuk anda, kerana itulah waktu di mana paling banyak muatan halaman berlaku.

WordPress memang mengehadkan pendua. Ia mengambil kunci yang mempunyai jangka hayat selama 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 sebaliknya. Kiraan dalam ribuan sehari merupakan kos yang nyata, dan ia adalah jenis angka yang perlu anda ukur pada mesin anda sendiri dan bukannya dibaca dalam artikel, sama seperti cara anda menanda aras VPS sebelum dan selepas sebarang perubahan lain.

Caching mengubah gambaran ini. 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 banyak menggunakan cache akan mula berkelakuan seperti tapak yang kurang trafik di bawah.

Mengapa pelawat mencetuskan cron tergendala pada laman yang kurang trafik

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

Gejalanya adalah serupa. Hantaran yang dijadualkan pada 09:00 kekal dalam senarai hantaran dengan tanda Missed schedule sehingga seseorang memuatkan halaman. Pemalam sandaran (backup plugins) terlepas waktu malam. Semakan kemas kini menjadi perlahan, menyebabkan papan pemuka tidak menunjukkan apa-apa untuk dikemas 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. Tugas tersebut tidak pernah dianggap lewat dari sudut pandangan 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 mencangkuk (hook) semakan cron pada init. Pemalar yang ditakrifkan selepas arahan 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 ke /wp-cron.php. Sesiapa sahaja masih boleh meminta URL tersebut, dan perkara itu 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 gunakannya 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 mencetak bool(true). Ralat maut tentang 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 hujung:

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 menjawab www-data. Jika anda memberikan tapak tersebut pool PHP-FPM sendiri dengan penggunanya sendiri, iaitu keadaan biasa bagi persediaan setiap tapak pada stack 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 menyimpan bukti tersebut.

Semak fail yang disimpan:

sudo crontab -u www-data -l

Untuk beberapa tapak, gunakan satu baris bagi setiap satu 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 diparsing 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 semakan bermula daripada yang paling mudah sehingga yang paling muktamad.

Pertama, adakah cron memulakan arahan tersebut? Cron merekodkan 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 telah memulakan arahan anda sebagai www-data. Ia tidak menyatakan sama ada arahan tersebut berjaya dilaksanakan atau tidak.

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, diikuti dengan 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 bacalah 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 tersenarai selepas dua selang masa, baris gilir tidak dijalankan, dan dua semakan pertama akan memberitahu anda sama ada masalah 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 penjadual systemd

Jika tugasan berjadual lain pada pelayan sudah dijalankan sebagai systemd services and timers, letakkan WordPress di sana juga. Setiap pelaksanaan akan dipaparkan dalam systemctl list-timers, dan output akan dihantar ke journal 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 servis 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 timer. Menjalankan kedua-duanya pada tapak yang sama bermakna baris gilir (queue) akan 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 (queue) tidak akan 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 plugin semasa proses tersebut akan menjadi milik root. Permintaan web seterusnya akan dijalankan sebagai www-data, tidak dapat menulis ke dalam direktori tersebut, dan laman web akan 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 tersebut 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 tugasan pengguna, iaitu /usr/bin:/bin. WP-CLI dipasang ke dalam /usr/local/bin, yang tidak tersenarai dalam PATH tersebut. Tugasan bermula, gagal dalam masa kurang sesaat, dan log hanya mengandungi satu baris:

/bin/sh: 1: wp: not found

Lihat sendiri persekitaran cron 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 tugasan 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 tugasan:

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 mencipta semula masalah asal

Ini adalah kegagalan ketiga. * * * * * terasa lebih selamat daripada lima minit, namun pada tapak web yang sibuk, ia mengembalikan anda ke titik asal. Jika satu proses mengambil masa lebih lama daripada selang masa yang ditetapkan, proses seterusnya akan bermula semasa proses pertama masih berjalan. Sepuluh minit kemudian, terdapat sepuluh proses PHP, setiap satunya memegang memori dan sambungan pangkalan data 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 bertimbun, dan pada VPS kecil, ini berakhir dengan ralat Too many connections MySQL, atau kernel menamatkan PHP untuk mendapatkan semula memori, yang boleh anda sahkan dengan sudo dmesg -T | grep -i 'killed process'.

WP-CLI menjalankan callback acara secara terus dan bukannya meminta wp-cron.php, jadi kunci 60 saat yang digunakan WordPress untuk menghalang proses pendua 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. Pertindihan adalah masalah yang perlu anda selesaikan dalam crontab dan bukannya masalah yang diselesaikan oleh kernel hos untuk anda: malah penempatan tugas yang peka cache yang ditambah dalam kernel Linux 7.2 hanya menentukan teras mana yang akan digunakan oleh sesuatu proses, bukan berapa banyak proses yang telah anda mulakan.

Pilih selang masa berdasarkan jadual paling singkat yang benar-benar anda perlukan, dan ukur tempoh satu proses dijalankan 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 web yang tidak mempunyai keperluan masa yang kritikal. Selang masa satu minit hanya sesuai untuk kedai dan pemalam berasaskan baris gilir 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 berhenti dengan SSL certificate problem, jadi pastikan pembaharuan berfungsi dengan Certbot pada nginx.
• Cache halaman tidak boleh menyimpan wp-cron.php, jika tidak, permintaan cron akan mendapat respons yang dicache dan tiada apa-apa yang akan berjalan.
• Anda tidak mendapat output bagi setiap peristiwa, jadi satu-satunya bukti tugasan telah berjalan ialah kesan yang dihasilkannya.

-sS memastikan curl senyap jika berjaya tetapi tetap memaparkan ralat, iaitu perkara yang anda perlukan dalam tugasan cron.

Perkara lain yang perlu dimasukkan ke dalam jadual pelayan

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

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 pada 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 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 sesuai untuk kebanyakan laman. Padankan selang masa dengan jadual paling singkat yang anda benar-benar perlukan, dan pastikan ia berada pada tahap yang selesa melebihi masa yang diambil oleh satu larian, yang boleh anda ukur dengan meletakkan time di hadapan arahan WP-CLI. Selang masa satu minit akan menyebabkan larian bertindih pada laman yang sibuk melainkan flock mengawal larian tersebut.

Mengapakah 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. Semak laluan cron sistem sebaliknya: 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 memadai?

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.