[wp-trac] [WordPress Trac] #47577: Streamline detecting and enabling HTTPS

[WordPress Trac]

#47577: Streamline detecting and enabling HTTPS
-------------------------+-------------------------------------------------
 Reporter:  flixos90     |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:               |    Version:
  Administration         |   Keywords:  needs-patch 2nd-opinion needs-unit-
 Severity:  normal       |  tests
  Focuses:               |
-------------------------+-------------------------------------------------
 Of all the WordPress sites today, 63.4% are using HTTPS. While this is
 already better than the [https://w3techs.com/technologies/details/ce-
 httpsdefault/all/all average for the entire web], it is far from optimal.
 More and more modern web APIs require usage of HTTPS, let alone the
 security implications of not using it.
 In order to close that gap, it must be easier for administrators to switch
 their WordPress site to HTTPS, especially if it is already supported by
 their environment.

 In order to provide accurate recommendations to site owners about
 switching their site to HTTPS, we need to know whether HTTPS is even
 supported by their server and domain. We have been reliably
 [https://github.com/xwp/pwa-wp/blob/master/wp-includes/class-wp-https-
 detection.php detecting HTTPS support in the PWA plugin] for a while, and
 the same logic could be used in core.

 Based on the result of the HTTPS support detection, we would recommend one
 of the following:
 * If supported, recommend to change the WordPress site URL, as that's all
 that's needed.
 * If not supported, recommend talking to the web host about enabling
 HTTPS.

 This provide more accurate recommendations for the respective situation a
 site is in.

 In order to properly enable HTTPS it is also crucial to not have mixed
 content links. Performing extensive database replacements is unfeasible
 for WordPress core itself, so we should instead replace URLs in content
 pointing to `http://` versions of the page with their `https://`
 counterparts on the fly. While this would be unnecessary for sites that
 properly have switched all their content to HTTPS, the overhead is minimal
 and acceptable. Last but not least, if somebody still doesn't want it,
 those checks should be removable easily because of the filter usage.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47577>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform