This changes the logic in `update_https_detection_errors()` to never store error messages from the actual request since they could use a different encoding, which would make storing them in an option potentially fail, leading WordPress to then falsely assume that HTTPS is supported.
While this doesn't actually fix the encoding issue, it is not crucial to do so anyway, since these messages are not used anywhere. A simple differentiation between whether the overall HTTPS request or only the SSL verification failed should be sufficient for the purpose of this function.
Props flixos90, tmatsuur, lukecarbis.
Fixes#52484.
git-svn-id: https://develop.svn.wordpress.org/trunk@50471 602fd350-edb4-49c9-b593-d223f7449a82
Prior to this changeset, the check for the correct RSD link output was relying on a specific protocol, although it needs to accept both the HTTP and HTTPS version of the URL.
Props TimothyBlynJacobs.
Fixes#52542. See #47577.
git-svn-id: https://develop.svn.wordpress.org/trunk@50391 602fd350-edb4-49c9-b593-d223f7449a82
This changeset introduces a `pre_wp_update_https_detection_errors` filter which can be used to short-circuit the default logic for detecting problems with HTTPS support for the site, by returning a `WP_Error` object.
Props timothyblynjacobs.
See #47577.
git-svn-id: https://develop.svn.wordpress.org/trunk@50075 602fd350-edb4-49c9-b593-d223f7449a82
Following up on [49904], this changeset focuses mainly on improving the guidance about the current state of HTTPS in Site Health.
* Correct the existing copy to indicate that both the Site Address and the WordPress Address need to be changed to fully switch to HTTPS.
* Link to the respective input fields via anchor links rather than to the overall General Settings screen.
* Show different copy if the site is using HTTPS for the WordPress Address (for example to have only the administration panel in HTTPS), but not for the Site Address.
* Inform the user about potential problems even when the site is already using HTTPS, for example if the SSL certificate was no longer valid.
* Always rely on fresh information for determining HTTPS support issues in Site Health, and therefore change the `https_status` test to become asynchronous.
* Rename the new private `wp_is_owned_html_output()` function to a more appropriate `wp_is_local_html_output()`.
Props adamsilverstein, flixos90, johnjamesjacoby, timothyblynjacobs.
See #47577.
git-svn-id: https://develop.svn.wordpress.org/trunk@50072 602fd350-edb4-49c9-b593-d223f7449a82
Trying to schedule cron jobs before WordPress is installed results in DB errors, which is suboptimal.
See #47577.
git-svn-id: https://develop.svn.wordpress.org/trunk@49909 602fd350-edb4-49c9-b593-d223f7449a82
This changeset modifies the Site Health panel for HTTPS to provide more accurate recommendations based on whether the environment is already set up for HTTPS.
* Introduces `wp_is_using_https()` to check whether the site is configured to use HTTPS (via its Site Address and WordPress Address).
* Introduces `wp_is_https_supported()` to check whether the environment supports HTTPS. This relies on a cron job which periodically checks support using a loopback request.
Props Clorith, flixos90, miinasikk, westonruter.
Fixes#47577.
git-svn-id: https://develop.svn.wordpress.org/trunk@49904 602fd350-edb4-49c9-b593-d223f7449a82
