[wp-trac] [WordPress Trac] #51437: Streamline migrating from HTTP to HTTPS

[WordPress Trac]

#51437: Streamline migrating from HTTP to HTTPS
-------------------------+------------------------------------------
 Reporter:  flixos90     |      Owner:  flixos90
     Type:  enhancement  |     Status:  assigned
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Security     |    Version:
 Severity:  normal       |   Keywords:  needs-patch needs-unit-tests
  Focuses:               |
-------------------------+------------------------------------------
 Per existing WordPress core behavior, HTTPS being enabled can be detected
 by looking at whether the Site Address and WordPress Address both use
 "https://" URLs. This detection is currently only present within Site
 Health, but #47577 aims to make it more generally available via a
 function.

 A major pain point in WordPress has been the migration of a WordPress site
 from HTTP to HTTPS: While changing the Site Address and WordPress Address
 to use HTTPS is trivial, updating references to the old URLs in existing
 content is not. It cannot be accomplished within core UI and requires use
 of more advanced tools, such as WP-CLI or plugins like "Better Search
 Replace", which is a no-go for most users.

 The migration of existing content can also happen more dynamically though,
 by replacing the old URLs starting with "http://" to "https://" on the
 fly. While replacing the content in the database is generally recommended,
 this presents a roadblock for most users, and this alternative is
 certainly feasible.

 It could also be considered to build a full HTTP to HTTPS database
 replacement tool into WordPress core, but dynamic replacement is a pattern
 already established in core for years (e.g. injecting `srcset`, `sizes`,
 `loading` tags to content images) and would be allow for a simpler way of
 solving this problem. Two important things to consider:
 * This replacement logic should only run if the site was migrated from
 HTTP to HTTPS. It shouldn't run if the site was HTTPS from the start.
 * It should be possible to skip the logic entirely, e.g. for advanced
 users that actually replaced all URLs in the database and thus no longer
 need this.

 I'm proposing the following:
 * Introduce a function `wp_should_update_insecure_urls()` which returns
 whether WordPress core should automatically replace "http://" versions of
 the home URL with "https://":
     * Rely on `wp_is_using_https()` from #47577.
         * If `false` (and the site is not a `fresh_site`, i.e. already has
 content), store a new option `https_migrated` and set it to `0`. This will
 be able to indicate in the future that the site used to be HTTP. Then
 return `false`.
         * Otherwise (if `true`), and there is an option `https_migrated`,
 first change its value to `1` if it's still `0`. Then return `true`.
     * Make the return value filterable, so that plugins can disable/enable
 the feature as needed.
 * Add hook callbacks to various content filters (e.g. `the_content`,
 `widget_text_content` etc, and if `wp_should_update_insecure_urls()`
 returns `true`, replace the non-HTTPS variant of the current `home_url()`
 with its HTTPS-variant.

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