Site Health Check: Fails for sites with basic auth and php-fpm

[stephankn]

Situation is PHP running as CGI (for HTTP/2) and admin interface is protected by basic auth.

Authentication is not possible, as the password is not available in the environment:

https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-site-health-auto-updates.php?rev=45275#L100

the reported conclusion "A plugin has prevented updates by disabling wp_version_check()" is wrong.

Code should check at least AUTH_TYPE for "Basic" or GATEWAY_INTERFACE for "CGI/1.1" to output a proper message. Providing a link to the site-check URL with the instruction to click ans look for the result "yes" in the browser would have also helped.

maybe this check could be done on client-side by javascript in the browser?

[desrosj]

Moving Site Health tickets into their lovely new home, the Site Health component.

[Clorith]

Hiya, welcome to WordPress trac, and my apologies for the delayed response.

We could absolutely improve the text used for that test, to make it a bit more descriptive, and not directly blame plugins like it currently does (there are many reasons it could fail, as you've mentioned).

I think that this specific scenario is a bit of an edge case, so I'm not sure if adding buttons and asking users to look for words is the right way forward.

As for making the request be a plain ajax call, there's actually a two-fold reason this hasn't been done.

Due to how the update filter is added, it does not exist within a call to admin-ajax.php, and leaving it open to a plain request without going via there leaves it open to unintended information sharing about a potential security issue on a site.

Do you have any suggestions for improving the texts used here to make it bore clear that this may not always be a problem ?

[Clorith]

Following up on this ticket @stephankn to hear if this is still an issue? The logic on how this check is performed has been reworked a bit since this ticket was opened.

[stephankn]

@Clorith I checked with version 6.0.1. The misleading warning is no longer printed.

I see no resolution "magically fixed by something else", so closing with a different resolve. Feel free to add further details, but I think this is not worth the effort doing history research to figure out why it was fixed.