Introduce constant or filter to prevent wp-cron.php triggering cron jobs.

[peterwilsoncc]

The constant DISABLE_WP_CRON allows developers to ​prevent the triggering of loopback requests to the wp-cron.php endpoint.

However, the constant does not prevent the wp-cron.php endpoint from running events registered via the WP Cron API.

DISABLE_WP_CRON was introduced prior to the existence of WP-CLI, so the recommended method for executing jobs via real cron was to execute the script directly or use curl to call the endpoint.

Now that WP CLI does exist, the best method for running wp-cron via real cron is to call wp cron event run --due-now or similar.

With this new best practice, I think it would be beneficial to allow developers to disable the wp-cron.php endpoint. Hitting the endpoint can be resource intensive and, for sites using real cron, lead to conflicts.

I think a constant or filter disable_wp_cron_endpoint would be beneficial in the context of modern sites using WP CLI.

The value of DISABLE_WP_CRON would need to default to the new filter/constant as firing loopback requests to an endpoint that doesn't do anything would be a little bit silly.

[whiteshadow01]

What should be shown when someone tries to visit this endpoint when the developer has disabled it using the above mentioned constant?

Should it throw a 404 or should it show a webpage explaining that this route is disabled?

[westonruter]

Normally accessing wp-cron.php just shows an empty response, right? This endpoint is almost never visited directly. But if the endpoint is disabled, I imagine sending back a 403 Forbidden would be appropriate. It wouldn't hurt to send this with wp_die() and some message.

Aside: It would be nice if accessing wp-cron.php would generally indicate if anything was run as part of the request. That would make accessing the screen actually generally useful. More detail could be provided if a user is logged-in as an administrator. For unauthenticated requests, it could simply say whether any jobs were run.

[peterwilsoncc]

I haven't thought too much about implementation details.

At the very least I think we'd need an HTTP header to indicating the cron jobs are bypassed. As ​batcache (the most popular full page caching drop-in) doesn't cache empty pages, we'd probably want some output to signal the page can be cached.

Response codes and messaging can be figured out if it's decided this is appropriate to add to WP Core.

[johnbillion]

I think we should keep this ticket focused. I'd also like to see more verbose output from wp-cron.php but that should happen in a separate ticket.

One complication is that the call to fastcgi_finish_request()/litespeed_finish_request() that runs prior to wp-load.php being loaded, and therefore prior to when a new constant or filter value can be checked. This means outputting a 403 etc won't be possible without jiggling some of that logic around.

• Introduces a filter to allow developers to enable/disable the wp-cron.php endpoint, wp_cron_endpoint_enabled.
• The default value of the constant DISABLE_WP_CRON is defined and set to false if the endpoint is disabled.
• Modifies wp-cron.php endpoint:
  • Adds a header indicating whether jobs are spawned or bypassed
  • Modifies when the request fast-finishes running to allow said header to be sent.

Trac ticket: https://core.trac.wordpress.org/ticket/64157

Unrelated, I am mentioning this ticket https://core.trac.wordpress.org/ticket/64175 as a test to see if the action fix works as expected.

Once the other PR is merged I'll delete this commentn

Unrelated, I am mentioning this ticket https://core.trac.wordpress.org/ticket/64175 as a test to see if the action fix works as expected.

Once the other PR is merged I'll delete this commentn