[wp-trac] [WordPress Trac] #51437: Streamline migrating from HTTP to HTTPS
WordPress Trac
noreply at wordpress.org
Tue Feb 2 00:08:17 UTC 2021
#51437: Streamline migrating from HTTP to HTTPS
-------------------------------------------------+-------------------------
Reporter: flixos90 | Owner: flixos90
Type: enhancement | Status: closed
Priority: normal | Milestone: 5.7
Component: Security | Version:
Severity: normal | Resolution: fixed
Keywords: has-patch has-unit-tests needs-dev- | Focuses:
note commit |
-------------------------------------------------+-------------------------
Changes (by flixos90):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"50131" 50131]:
{{{
#!CommitTicketReference repository="" revision="50131"
Security, Site Health: Make migrating a site to HTTPS a one-click
interaction.
Switching a WordPress site from HTTP to HTTPS has historically been a
tedious task. While on the surface the Site Address and WordPress Address
have to be updated, existing content still remains using HTTP URLs where
hard-coded in the database. Furthermore, updating _two_ URLs to migrate to
HTTPS is still a fairly unintuitive step which is not clearly explained.
This changeset simplifies migration from HTTP to HTTPS and, where
possible, makes it a one-click interaction.
* Automatically replace insecure versions of the Site Address
(`home_url()`) with its HTTPS counterpart on the fly if the site has been
migrated from HTTP to HTTPS. This is accomplished by introducing a
`https_migration_required` option and enabling it when the `home_url()` is
accordingly changed.
* A new `wp_replace_insecure_home_url()` function is hooked into
various pieces of content to replace URLs accordingly.
* The migration only kicks in when the Site Address (`home_url()`) and
WordPress Address (`site_url()`) match, which is the widely common case.
Configurations where these differ are often maintained by more advanced
users, where this migration routine would be less essential - something to
potentially iterate on in the future though.
* The migration does not actually update content in the database. More
savvy users that prefer to do that can prevent the migration logic from
running by either deleting the `https_migration_required` option or using
the new `wp_should_replace_insecure_home_url` filter.
* For fresh sites that do not have any content yet at the point of
changing the URLs to HTTPS, the migration will also be skipped since it
would not be relevant.
* Expose a primary action in the Site Health recommendation, if HTTPS is
already supported by the environment, built on top of the HTTPS detection
mechanism from [49904]. When clicked, the default behavior is to update
`home_url()` and `site_url()` in one go to their HTTPS counterpart.
* A new `wp_update_urls_to_https()` function takes care of the update
routine.
* A new `update_https` meta capability is introduced to control
access.
* If the site's URLs are controlled by constants, this update is not
automatically possible, so in these scenarios the user is informed about
that in the HTTPS status check in Site Health.
* Allow hosting providers to modify the URLs linked to in the HTTPS status
check in Site Health, similar to how that is possible for the URLs around
updating the PHP version.
* A `WP_UPDATE_HTTPS_URL` environment variable or
`wp_update_https_url` filter can be used to provide a custom URL with
guidance about updating the site to use HTTPS.
* A `WP_DIRECT_UPDATE_HTTPS_URL` environment variable or
`wp_direct_update_https_url` filter can be used to provide a custom URL
for the primary CTA to update the site to use HTTPS.
Props flixos90, timothyblynjacobs.
Fixes #51437.
}}}
--
Ticket URL: <https://core.trac.wordpress.org/ticket/51437#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list