Site Health: information about "loopback" connections is vague/misleading.

[DavidAnderson]

In the "Site Health Check" feature, if the HTTP "loopback" test fails, you get this message: "The loopback request to your site failed, this means features relying on them are not currently working as expected."

This is unhelpfully vague, and may not be true in the sense of not affecting any features the user would care about (e.g. perhaps the hosting company automatically sets up visits to wp-cron.php - are there any other non-super-niche features affected?).

In https://core.trac.wordpress.org/ticket/47046#comment:9 it's said, by way of examples as to what features might fail, "A couple of examples are starting a new WP_Cron instance, or when editing plugin or theme files through the admin.".

For testing cron, a better test would be for WP to look at whether there's a backlog of tasks (i.e. overdue tasks) in the cron queue, rather than guessing based on only one possible mechanism for using cron (i.e. loopback). In the case of "editing plugin or theme files", that might be disabled anyway (some hosting companies do). If there aren't more use significant cases than that (editing your plugin files is a very niche activity), it'd be better not to trouble the user to investigate something vaguely specified.

At least, it should be specific: "you won't be able to edit plugin/theme files directly from the WP admin area", so that the user can realise "well, I don't care about that, I can move on" rather than encouraging the user to invest resources in achieving an unnecessary perfection.

[Clorith]

WP_Cron and theme/plugin editors are the most prominent ones, but we're trying to not be too specific, as we can't guarantee what services rely on loopbacks, plugins or themes might be using it for various aspects, we really can't tell, but we can tell if it isn't working.

There's a separate check for WP_Cron specifically with more details on what WP_Cron does.

If you have suggestions for better wording, that isn't locked in to singular functionality, I'm all ears, but that likely won't be included until 5.3 though.

[DavidAnderson]

"the most prominent ones" - are there any others in WP core at all? I can't think of any. If there's a separate cron check, then for 99.9% + of users, they're being untroubled unnecessarily; they're going to believe their site lacks health, when it doesn't.

Rather than tweaking the wording, I'd suggesting having this check off by default, and providing a default-false filter so that plugins that need loopback to work can turn the check back on easily (rather than re-inventing the wheel themselves). Then "features relying on them are not currently working as expected" would be known to actually mean "actual features" rather than "features you're not using". As-is, it's most useful function would be to strong-arm hosting companies to not prevent loopback. If that's the intended purpose, I wouldn't personally object. But if that's not the intended purpose, then I don't think it currently really has one.

[joyously]

It is used for the code editors, to test that changes don't fatal.
It seems like it is needed for the Customizer, but I could be mistaken on that.
It is used for Recovery mode, I think.
It could be used by plugins, so this has to be vague.

[Clorith]

As per the core standards, we don't ship with things "off by default", we don't include it at all if that were the case.

If there's nothing actionable here (we are not removing it, this test has proven it self over the past 12 months as being quite vital, as is evident by our use of it in the WordPress.org support team), I'm going to close off the ticket. I've marked it as being up for close-consideration.

[Clorith]

I'm closing this for now, if we see there's a need to improve this based on feedback post-5.2 we can revisit and improve the user flow at that time.

[desrosj]

#47431 was marked as a duplicate.