Opened 4 years ago
Last modified 4 years ago
#52916 new enhancement
can_perform_loopback() should not rely on wp-cron.php check
Reported by: | dvershinin | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | minor | Version: | 5.7 |
Component: | Site Health | Keywords: | |
Focuses: | ui, administration | Cc: |
Description
It is quite often that users would want to prevent/hide access to /wp-cron.php.
For example, they want to use the real Linux cron scheduler, and invoke /wp-cron.php only interactively; all while returning "404" on purpose when /wp-cron.php is requested.
Here you can find an NGINX config that purposely does not list /wp-cron.php as an allowed endpoint, and thus returning 404 when wp-cron.php is accessed via web, which is fine. The WP Cron is suggested there to be run via CLI only.
So while the site is still fully functional, WP Admin shows a false-positive error for the health check: "Your site could not complete a loopback request".
I propose to:
- use a different endpoint for loopback requests check, something that is less likely to be disabled by users. wp-json?
- check wp cron being valid using other means, like last run time of a task.
At the very least, not use /wp-cron.php for any checks when DISABLE_WP_CRON constant is true.
Change History (4)
#3
follow-up:
↓ 4
@
4 years ago
At the very least, not use /wp-cron.php for any checks when
DISABLE_WP_CRON
constant is true.
I think this is worth discussing. As you identify, it's a minor issue due to the unusual server configuration required so it may be able to wait until a major release rather than been in a WP maintenance release.
#4
in reply to:
↑ 3
@
4 years ago
Replying to peterwilsoncc:
At the very least, not use /wp-cron.php for any checks when
DISABLE_WP_CRON
constant is true.
I think this is worth discussing. As you identify, it's a minor issue due to the unusual server configuration required so it may be able to wait until a major release rather than been in a WP maintenance release.
Agreed. I think that'd be the right fix. We are already doing loopback requests to the REST API.
Hi there, welcome back to WordPress Trac! Thanks for the ticket.
Just noting that the current check was introduced in [50399] / #52547 as a follow-up to [49154], [49917], and [50381].
The intention was to more closely represent how WordPress itself uses loopback requests. See comment:5:ticket:52547 and the Slack discussion for more context.