WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 2 weeks ago

#47957 new enhancement

Don't verify SSL certificate for loopback test

Reported by: ocean90 Owned by:
Milestone: 5.3 Priority: normal
Severity: normal Version: 5.2
Component: Site Health Keywords: has-patch
Focuses: Cc:

Description

If a site uses a self-signed certificate the loopback test will report an error. Since spawn_cron() doesn't verify the certificate the test shouldn't either to replicate core's behaviour.

Attachments (3)

47957.diff (886 bytes) - added by ocean90 3 weeks ago.
47957.2.diff (1.5 KB) - added by ocean90 3 weeks ago.
Disable sslverify for get_test_rest_availability()
47957.3.diff (2.4 KB) - added by ocean90 3 weeks ago.
Disable sslverify for test_wp_version_check_attached()

Download all attachments as: .zip

Change History (4)

@ocean90
3 weeks ago

@ocean90
3 weeks ago

Disable sslverify for get_test_rest_availability()

@ocean90
3 weeks ago

Disable sslverify for test_wp_version_check_attached()

#1 @Clorith
2 weeks ago

Hmm, we definitely need a more reliable solution overall. The reason the Site Health check does it this way is because it was copied from how the plugin/theme editors do them (this was the basis for creating the test, as a lot of users had issues saving after the changes to t hem were implemented, all due to loopback failures).

There's now 3 places (likely to be more) that do loopbacks, so having a fixed loopback function is probably a more sustainable approach?

I'm thinking along the lines of function loopback( $target_url ) { return $WP_Http } which all the places that do loopbacks can use, and by returning the WP_Http object those places can then check whatever they need, if that is the content body, headers etc.

This would also be handy for #47954 which looks to do loopback calls to verify URLs are reachable before breaking a users access to their site.

Note: See TracTickets for help on using tickets.