WordPress Cron (WP-Cron)

WordPress_Cron_WP-Cron.md

WordPress Cron (WP-Cron)

Disable Built-in WP-Cron

Disable the default WordPress pseudo-cron by adding the following to your wp-config.php (or the equivalent Bedrock configuration):

define('DISABLE_WP_CRON', true);

This prevents WordPress from attempting to execute scheduled tasks on every page request and allows the system cron to manage them instead.

---

System Cron (Bedrock)

Since this project uses Bedrock, configure your server cron to execute wp-cron.php every 5 minutes:

*/5 * * * * /usr/bin/curl -sk -m 300 -o /dev/null -H "Host: domain.com" "https://127.0.0.1/wp/wp-cron.php?doing_wp_cron"

Replace domain.com with your actual domain.

---

Why This Approach?

This configuration is significantly more reliable than calling https://domain.com/wp/wp-cron.php externally.

Benefits

• Independent of DNS – Uses the local loopback address (127.0.0.1), so DNS resolution failures cannot prevent cron jobs from running.
• Independent of Cloudflare – Requests never leave the server, eliminating dependency on Cloudflare's availability or any proxy.
• Bypasses the WAF – Web Application Firewall rules cannot accidentally block scheduled tasks.
• More reliable – Cloudflare outages, DNS issues, or firewall rule changes can no longer silently stop all scheduled jobs.
• Request timeout protection – The -m 300 option limits execution to 300 seconds (5 minutes), preventing stuck requests from accumulating and consuming server resources.
• Silent execution – -o /dev/null discards output, while -s keeps the command quiet to avoid unnecessary cron emails.
• TLS-compatible – The request is still made over HTTPS, while -k allows the self-signed/local certificate typically used for loopback connections.

---

Curl Flags Explained

Flag	Purpose
-s	Silent mode (no progress output).
-k	Skip TLS certificate validation for the local HTTPS request.
-m 300	Abort the request after 300 seconds if it hangs.
-o /dev/null	Discard response output.
-H "Host: domain.com"	Sends the correct Host header so the web server routes the request to the correct virtual host.

---

Why Use 127.0.0.1 with a Host Header?

The web server may host multiple websites (virtual hosts). Connecting directly to 127.0.0.1 reaches the local web server, while the Host header tells it which site should handle the request.

This keeps the entire request inside the server while ensuring WordPress boots with the correct site configuration.