Tắt WP-Cron, chạy WordPress bằng system cron

WP-Cron là gì và vì sao system cron thay thế nó

WP-Cron là bộ lập lịch tác vụ tích hợp trong WordPress và chỉ chạy khi có người yêu cầu một trang. Không có thành phần nào trong WordPress tự thức dậy để chạy. Với mỗi request không được phục vụ từ cache, WordPress đọc danh sách các job đã lập lịch. Nếu có job đến hạn, WordPress gửi một HTTP request thứ hai đến chính nó tại /wp-cron.php để thực hiện công việc. Chuyển job này sang system cron giúp job chạy một lần theo lịch cố định và có thể dự đoán được, bất kể trong phút đó website có một nghìn lượt truy cập hay không có lượt nào.

Hai dòng thực hiện công việc chính: một constant trong wp-config.php và một mục crontab. Mọi nội dung khác trong hướng dẫn này giải thích những phần mà hai dòng đó không thể hiện. Job phải chạy dưới user nào, cách xác nhận các scheduled event thực sự đã chạy và ba trường hợp khiến cấu hình thất bại mà không in ra bất kỳ thông báo nào trên website.

Các ví dụ sử dụng /srv/www/example.com làm thư mục WordPress và www-data làm user của web server. Hãy thay thế bằng path và user của bạn ở mọi vị trí.

Lượt truy cập nào kích hoạt cron và gây tốn tài nguyên trên site có nhiều traffic

Mỗi request không có trong cache đều phải thực hiện bước kiểm tra này. WordPress tải option cron, so sánh timestamp, và khi có tác vụ đến hạn, nó gọi spawn_cron(). Hàm này gửi một loopback request không chặn đến /wp-cron.php. Visitor không phải chờ kết quả. Nhưng một PHP worker thì có. Trên VPS nhỏ chạy PHP-FPM với pm.max_children = 5, một scheduled job chậm có thể giữ 1/5 năng lực xử lý PHP trong suốt thời gian job chạy. Job này nhiều khả năng được kích hoạt vào phút có nhiều traffic nhất, vì đó là lúc có nhiều page load nhất.

WordPress có giới hạn việc chạy trùng. Nó tạo một lock có thời hạn WP_CRON_LOCK_TIMEOUT, mặc định là 60 giây, để các visitor truy cập đồng thời không cùng khởi chạy một lần chạy. Lock này giới hạn việc chạy trùng. Nó không đưa tác vụ ra khỏi request path.

Hãy đếm tần suất nó chạy trên chính server của bạn trước khi quyết định mức độ ảnh hưởng. Mỗi loopback request xuất hiện trong access log của web server:

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

Apache ghi vào /var/log/apache2/access.log thay vào đó. Nếu số lượng lên đến hàng nghìn mỗi ngày thì đó là một chi phí thực tế. Bạn nên đo con số này trên chính server của mình thay vì chỉ đọc trong một bài viết, giống như khi bạn benchmark VPS trước và sau các thay đổi khác.

Caching làm thay đổi tình hình. Nếu page cache phục vụ hầu hết request dưới dạng HTML tĩnh, PHP không chạy cho các request đó, nên bước kiểm tra cron cũng không xảy ra. Một site có nhiều traffic và được cache tốt sẽ bắt đầu hoạt động giống site ít traffic ở phần dưới.

Cron bị kích hoạt bởi visitor nào trên một site ít truy cập

Không có visitor thì không có cron. Một site chỉ có vài lượt truy cập mỗi ngày sẽ chạy các scheduled job tương ứng vài lần mỗi ngày, vào những thời điểm ngẫu nhiên khi các lượt truy cập đó xảy ra.

Các triệu chứng đều giống nhau. Một bài viết được lên lịch lúc 09:00 vẫn nằm trong danh sách bài viết với trạng thái Missed schedule cho đến khi có người tải một page. Plugin backup bỏ qua lần chạy ban đêm. Việc kiểm tra update bị chậm, nên dashboard không hiển thị update nào trong khi một bản security release đã được phát hành. Email đơn hàng, thông báo gia hạn và cảnh báo hết hạn đều được gửi trễ.

Không có lỗi nào được ghi vào log. Theo cách WordPress nhìn nhận, job không hề bị trễ vì nó chưa bao giờ được khởi chạy.

Bước 1: tắt trigger từ visitor trong wp-config.php

Mở /srv/www/example.com/wp-config.php và thêm constant sau:

define( 'DISABLE_WP_CRON', true );

Đặt constant này bên trên dòng có nội dung /* That's all, stop editing! Happy publishing. */, vì dòng ngay bên dưới comment đó yêu cầu wp-settings.php, còn wp-settings.php là nơi WordPress gắn việc kiểm tra cron vào init. Nếu định nghĩa constant sau lệnh require đó thì đã quá muộn để thay đổi hành vi. File vẫn trông đúng, nhưng trigger vẫn tiếp tục chạy.

Xác nhận dòng này nằm đúng vị trí bạn mong muốn:

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

Constant này không ngăn các event được schedule. Plugin vẫn tiếp tục thêm job vào queue như trước. Nó chỉ ngăn page load chạy queue đó. Vì vậy, queue sẽ không chạy nữa cho đến khi bạn hoàn tất bước 3.

Constant này cũng không chặn request trực tiếp đến /wp-cron.php. Bất kỳ ai vẫn có thể request URL đó. Việc này thường không gây vấn đề vì file chỉ chạy các job đã đến hạn. Chặn URL này trong cấu hình web server là tùy chọn. Nếu bạn chặn, cơ chế fallback curl ở gần cuối hướng dẫn này cũng sẽ không hoạt động.

Bước 2: cài đặt WP-CLI

WP-CLI là công cụ dòng lệnh chính thức cho WordPress. Nó cần binary PHP dòng lệnh, đây là một gói riêng biệt với module PHP của web server.

php -v
sudo apt install -y php-cli

Cài đặt WP-CLI từ bản build phar, đây là cách mà hướng dẫn cài đặt chính thức khuyến nghị:

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 in ra đường dẫn binary PHP, phiên bản PHP và phiên bản WP-CLI. Nếu nó in ra đủ cả ba, file phar hoạt động bình thường. Tính đến tháng 10 năm 2026, hướng dẫn cài đặt yêu cầu tối thiểu PHP 7.2.24, và Ubuntu 24.04 đi kèm với PHP 8.3, vì vậy một máy chủ hiện tại hoàn toàn đáp ứng yêu cầu này. Cập nhật sau đó bằng sudo wp cli update.

Chạy WP-CLI dưới quyền người dùng của trang web, không bao giờ chạy dưới quyền root:

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

Nếu chạy dưới quyền root, WP-CLI sẽ từ chối khởi động:

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

Nó gợi ý dùng --allow-root. Đừng sử dụng tùy chọn đó ở đây. Lý do nằm ở chế độ lỗi đầu tiên dưới đây.

Cũng cần lưu ý rằng sudo -u www-data -i không hoạt động, vì login shell của tài khoản đó là /usr/sbin/nologin và bạn sẽ nhận được This account is currently not available.. Việc truyền lệnh trực tiếp cho sudo -u sẽ bỏ qua login shell, vì vậy nó chạy bình thường.

Bây giờ hãy xác nhận WordPress tự nhận diện hằng số từ bước 1:

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

Lệnh đó in ra bool(true). Một lỗi nghiêm trọng (fatal error) về hằng số không xác định nghĩa là dòng define() chưa được thực thi, thường là do nó nằm bên dưới lệnh require.

Bước 3: thêm cron entry bằng đúng user

User đúng là user sở hữu các file mà PHP ghi vào. Kiểm tra cả hai đầu:

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

Trên Ubuntu cài mặc định, cả hai đều trả về www-data. Nếu bạn cấp cho site một PHP-FPM pool riêng với user riêng, đây thường là kết quả của mô hình per-site trên LAMP stack trên Ubuntu 24.04, hãy dùng user đó cho mọi bước bên dưới.

Tạo một thư mục log mà user đó có quyền ghi:

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

Sửa crontab của user đó:

sudo crontab -u www-data -e

Thêm một dòng:

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

Phân tích từng phần. */5 chạy lệnh mỗi 5 phút. flock -n lấy lock file và thoát ngay nếu lần chạy trước vẫn đang giữ lock. /usr/local/bin/wp là đường dẫn tuyệt đối mà cron yêu cầu. --path cho phép lệnh chạy từ bất kỳ working directory nào. --due-now chỉ chạy các event đã đến thời điểm, thay vì chạy mọi event trong queue. Phần redirect ghi output bình thường và error vào một file duy nhất để bạn đọc.

Trong thực tế, redirect này không phải tùy chọn. Cron gửi output của job qua mail cho user của job, nhưng hầu hết image VPS không cài mail transfer agent. Sau đó cron ghi log (CRON) info (No MTA installed, discarding output) rồi loại bỏ output. Ghi vào file giúp giữ lại bằng chứng.

Kiểm tra file đã được lưu:

sudo crontab -u www-data -l

Với nhiều site, dùng mỗi site một dòng và lệch phút để chúng không khởi chạy cùng lúc:

*/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 sẽ tăng mãi nếu bạn không rotate. Ghi /etc/logrotate.d/wp-cron:

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

Kiểm tra cú pháp mà không thực hiện thay đổi nào: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Bước 4: xác nhận các event đã được chạy thật

Một dòng crontab lưu thành công không chứng minh được gì. Hãy kiểm tra từ bước ít tốn công nhất đến bước có thể xác nhận nguyên nhân.

Trước tiên, cron có khởi chạy command không? Cron ghi log vào journal trong unit riêng:

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

Một entry hợp lệ sẽ có dạng sau, trong đó timestamp và hostname ở đầu đã được lược bỏ:

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)

Dòng này có nghĩa cron đã khởi chạy command của bạn với tư cách www-data. Nó không cho biết command có chạy thành công hay không.

Tiếp theo, WordPress có thực thi gì không? Đọc file log:

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

WP-CLI in một dòng cho mỗi event, sau đó in tổng số:

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

Lỗi cũng được ghi vào cùng file. Đây chính là mục đích của 2>&1. Hầu hết các lần chạy sẽ không có event nào đến hạn và chỉ ghi rất ít nội dung, vì vậy hãy đọc file sau một lần chạy mà bạn biết chắc đang có event chờ xử lý.

Cuối cùng, hãy xác minh toàn bộ chuỗi hoạt động. Schedule một marker event rồi theo dõi cho đến khi nó biến mất:

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

Chờ một interval, rồi chạy lại command list. Hook đã biến mất vì một one-off event được xóa khỏi queue khi chạy. Không có plugin nào đăng ký callback cho tên hook đó, nên việc chạy hook không làm gì khác với site. Nếu hook vẫn được liệt kê sau hai interval, queue không được chạy. Hai bước kiểm tra đầu tiên sẽ cho biết vấn đề nằm ở cron hay WP-CLI.

Không dùng wp cron test cho việc này. Command đó kiểm tra việc visitor-triggered spawning có hoạt động không và sẽ báo lỗi khi DISABLE_WP_CRON là true. Trên server được cấu hình đúng, lỗi này là output được mong đợi, không phải sự cố.

Phương án dùng systemd timer

Nếu các tác vụ định kỳ khác trên máy chủ đã chạy bằng systemd service và timer, hãy đưa WordPress vào cùng cơ chế đó. Mỗi lần chạy sẽ xuất hiện trong systemctl list-timers, còn output được ghi vào journal thay vì một file mà bạn phải tự rotate.

Tạo /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

Sau đó tạo /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 không chạy đồng thời 2 bản sao của cùng một service, nên phiên bản này không cần flock. Persistent=true giúp chạy bù một lần đã bị bỏ lỡ khi máy chủ tắt, điều mà một mục crontab không làm được.

Chọn crontab hoặc timer. Nếu chạy cả 2 cho cùng một site, queue sẽ bị xử lý 2 lần. Việc chạy trùng các job gửi email hoặc xử lý đơn hàng sẽ lộ rõ với khách hàng.

Vì sao cron job không được chạy bằng root

Đây là cách đầu tiên trong ba nguyên nhân khiến thiết lập bị lỗi. Nếu thêm job vào crontab của root, WP-CLI sẽ dừng trước khi thực hiện bất kỳ thao tác nào:

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

Queue không bao giờ chạy. Nếu bạn không redirect output, bạn sẽ không thấy thông báo lỗi. Cách sửa nguy hiểm là thêm --allow-root, vì khi đó mọi file mà plugin ghi trong lần chạy đó đều thuộc về root. Request web tiếp theo chạy bằng www-data, không thể ghi vào các thư mục đó, và site bắt đầu báo các lỗi như:

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

Sửa lại ownership, sau đó chuyển job:

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

Crontab của root và crontab của www-data là hai file riêng biệt. Xóa dòng trong file này không ảnh hưởng đến file kia. Kiểm tra cả hai:

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

Vì sao cron báo wp: not found

Đây là lỗi thứ hai. Cron cấp cho các job của user một PATH rất ngắn, /usr/bin:/bin. WP-CLI được cài vào /usr/local/bin, nhưng thư mục này không nằm trong danh sách đó. Job khởi chạy, fail trong chưa đến một giây, và log chỉ có một dòng:

/bin/sh: 1: wp: not found

Hãy tự xem environment của cron thay vì đoán. Thêm một dòng tạm thời:

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

Đọc /tmp/cron-env.txt sau một khoảng thời gian, rồi xóa dòng đó. Giá trị PATH= trong file này chính xác là giá trị mà job của bạn nhận được.

Có 2 cách sửa. Dùng đường dẫn tuyệt đối /usr/local/bin/wp như trong bước 3. Hoặc đặt PATH một lần ở đầu crontab, bên trên mọi dòng job:

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

Cùng lỗi này còn xuất hiện ở cấp thấp hơn. Phar wp bắt đầu bằng #!/usr/bin/env php, vì vậy shell cũng phải tìm được php. Nếu PHP nằm ngoài /usr/bin, điều thường xảy ra với các bản build tùy chỉnh và bản build của control panel, bạn sẽ gặp lỗi:

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

Trong trường hợp đó, gọi interpreter một cách rõ ràng, ví dụ /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

Tại sao khoảng thời gian một phút lại tái hiện vấn đề ban đầu

Đây là lần thất bại thứ ba. * * * * * tạo cảm giác an toàn hơn năm phút, nhưng trên một trang web bận rộn, nó đưa bạn trở lại điểm xuất phát. Nếu một lần chạy mất nhiều thời gian hơn khoảng thời gian định sẵn, lần chạy tiếp theo sẽ bắt đầu khi lần đầu vẫn đang thực thi. Mười phút sau, sẽ có mười tiến trình PHP, mỗi tiến trình chiếm dụng bộ nhớ và kết nối cơ sở dữ liệu riêng.

Hãy kiểm tra tình trạng chồng chéo trực tiếp:

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

etimes là thời gian tồn tại của tiến trình tính bằng giây. Một dòng là trạng thái bình thường. Nhiều dòng với thời gian tồn tại lớn hơn nhiều so với khoảng thời gian chạy cron của bạn nghĩa là các tiến trình đang chồng chất lên nhau. Trên một VPS nhỏ, điều này dẫn đến lỗi Too many connections của MySQL, hoặc kernel sẽ kill PHP để giải phóng bộ nhớ, điều mà bạn có thể xác nhận bằng sudo dmesg -T | grep -i 'killed process'.

WP-CLI chạy trực tiếp các callback sự kiện thay vì request qua wp-cron.php, nhưng với --due-now hiện tại, WP-CLI vẫn tôn trọng transient doing_cron, đây là cơ chế khóa mà WordPress sử dụng để chống lại việc chạy trùng lặp. Nó thiết lập khóa đó khi bắt đầu chạy, và nếu một tiến trình khác đã giữ khóa, tiến trình mới sẽ ghi Warning: A cron event run is already in progress; skipping. vào log của bạn rồi dừng lại. Khóa đó chỉ tồn tại trong WP_CRON_LOCK_TIMEOUT, mặc định là 60 giây, vì vậy một lần chạy kéo dài hơn một phút sẽ không còn được bảo vệ bởi khóa này và lần chạy tiếp theo có thể bắt đầu song song. flock -n trong mục bước 3 giữ khóa của nó chừng nào tiến trình còn sống, đó là cách ngăn chặn sự chồng chéo cho các lần chạy chậm. Một lần chạy bị bỏ qua bởi flock sẽ thoát ngay lập tức và âm thầm, theo thiết kế. Chồng chéo là vấn đề bạn phải giải quyết trong crontab thay vì để kernel của host giải quyết cho bạn: ngay cả cơ chế đặt tác vụ nhận biết cache được thêm vào Linux kernel 7.2 cũng chỉ quyết định tiến trình chạy trên core nào, chứ không bao giờ quyết định số lượng tiến trình bạn đã khởi chạy.

Hãy chọn khoảng thời gian dựa trên lịch trình ngắn nhất mà bạn thực sự cần, và hãy đo thời gian một lần chạy trước:

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

Năm phút là thiết lập mặc định hợp lý: một bài viết được lên lịch lúc 09:00 thường sẽ xuất bản trước 09:05, miễn là lần chạy trước đó đã hoàn tất. Nếu một lần chạy trước đó vẫn giữ khóa vào lúc 09:05, lần gọi đó sẽ bị bỏ qua và bài viết sẽ đợi lần chạy tiếp theo lấy được khóa. Mười lăm phút là ổn cho một trang web không có tác vụ nào quan trọng về thời gian. Một phút chỉ dành cho các cửa hàng và các plugin điều khiển bằng hàng đợi thực sự cần nó, và chỉ khi bạn biết chắc chắn một lần chạy chỉ mất vài giây để hoàn thành.

Nếu bạn không thể cài đặt WP-CLI

Một số host chặn các công cụ shell. Gửi HTTP request trực tiếp đến wp-cron.php vẫn chạy cùng queue, nhưng đi qua toàn bộ web stack:

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

Những gì bạn phải chấp nhận:

• Lần chạy bị giới hạn bởi timeout của web server và PHP-FPM, nên job chạy lâu có thể bị dừng giữa chừng.
• Certificate phải hợp lệ, nếu không curl sẽ dừng với SSL certificate problem. Vì vậy, hãy duy trì việc gia hạn bằng Certbot trên nginx.
• Page cache không được cache wp-cron.php, nếu không các request từ cron sẽ nhận response đã cache và không có gì được chạy.
• Bạn không nhận được output cho từng event, nên bằng chứng duy nhất cho thấy một job đã chạy là tác động mà nó tạo ra.

-sS giữ cho curl không in gì khi thành công nhưng vẫn in error. Đây là hành vi phù hợp khi chạy trong cron job.

Những việc nào khác nên đưa vào lịch của server

Khi cron của hệ thống đã quản lý queue của WordPress, hãy đặt các tác vụ định kỳ còn lại của server ở cùng một nơi để dễ theo dõi. Bản vá bảo mật của hệ điều hành nên do unattended upgrades xử lý, thay vì một dòng cron bạn phải tự duy trì. Việc cập nhật plugin và theme của WordPress là một quyết định khác: wp plugin update --all trong crontab có thể dễ dàng làm hỏng một site đang chạy lúc 3 giờ sáng mà không ai theo dõi. Hãy thực hiện việc này một cách có chủ đích, hoặc chạy sau một bước staging và backup.

FAQ

Việc vô hiệu hóa WP-Cron có làm dừng các bài viết đã lên lịch không?

Không, miễn là có thứ khác chạy hàng đợi đó. DISABLE_WP_CRON chỉ ngăn việc tải trang kích hoạt hàng đợi. Các sự kiện vẫn được lên lịch chính xác như trước. Một bài viết đặt lúc 09:00 sẽ được đăng vào lần chạy cron đầu tiên sau 09:00 mà giành được quyền truy cập (lock), vì vậy với khoảng thời gian 5 phút, bài viết thường sẽ được đăng trước 09:05. Nếu một lần chạy trước đó bị chậm và vẫn giữ quyền truy cập, lần thực thi đó sẽ bị bỏ qua và việc đăng bài sẽ đợi lần tiếp theo. Nếu bạn đặt hằng số này mà không thêm mục cron, bài viết sẽ nằm trong danh sách với trạng thái Missed schedule cho đến khi có thứ gì đó chạy hàng đợi.

User nào nên chạy cron job cho WordPress?

User sở hữu các file mà PHP ghi vào, thường là www-data trên bản cài đặt Ubuntu mặc định. Hãy kiểm tra bằng stat -c '%U %G' /srv/www/example.com/wp-content/uploads và so sánh với dòng user = trong cấu hình pool PHP-FPM của bạn. Chạy job dưới quyền root sẽ khiến WP-CLI dừng lại với lỗi YIKES, và việc ép buộc chạy bằng --allow-root sẽ để lại các file thuộc sở hữu của root bên trong wp-content mà web server không thể ghi đè sau đó.

System cron nên chạy WordPress cron bao lâu một lần?

Mỗi 5 phút là phù hợp với hầu hết các trang web. Hãy khớp khoảng thời gian này với lịch trình ngắn nhất mà bạn thực sự cần, và giữ nó ở mức an toàn so với thời gian một lần chạy hoàn tất; bạn có thể đo lường bằng cách đặt time phía trước lệnh WP-CLI. Khoảng thời gian 1 phút sẽ khiến các lần chạy chồng chéo lên nhau trên các trang web bận rộn trừ khi có flock bảo vệ.

Tại sao wp cron test lại báo lỗi sau khi tôi vô hiệu hóa WP-Cron?

Vì lệnh đó kiểm tra việc kích hoạt thông qua khách truy cập, và nó báo lỗi khi DISABLE_WP_CRON được đặt là true. Đó là kết quả đúng trên một server được cấu hình theo cách này. Thay vào đó, hãy kiểm tra đường dẫn system cron: đọc /var/log/wp-cron/example.log, hoặc lên lịch một sự kiện đánh dấu bằng wp cron event schedule và xác nhận rằng nó đã biến mất khỏi wp cron event list sau lần chạy tiếp theo.

Tôi có cần WP-CLI không, hay dùng curl gọi wp-cron.php là đủ?

Curl vẫn hoạt động, và đó là giải pháp đúng khi bạn không thể cài đặt WP-CLI. Nó chậm hơn vì phải tải WordPress thông qua web server và bị giới hạn bởi thời gian chờ của request (timeout). WP-CLI chạy các sự kiện trong một tiến trình PHP dòng lệnh mà không bị giới hạn bởi web timeout, đồng thời in ra mỗi sự kiện một dòng kèm thời gian thực thi, vì vậy log sẽ cho bạn biết chính xác những gì đã chạy và mất bao lâu.