Make WordPress Core

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's profile 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)

#1 @SergeyBiryukov
4 years ago

  • Component changed from Administration to Site Health

#2 @SergeyBiryukov
4 years ago

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.

#3 follow-up: @peterwilsoncc
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 @TimothyBlynJacobs
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.

Note: See TracTickets for help on using tickets.