WordPress 5.7 Will Make It Easier to Migrate From HTTP to HTTPS

The next major release of WordPress will make it much easier for users to migrate their sites from HTTP to HTTPS. It introduces new capabilities to detect if the user’s hosting environment has support for HTTPS and provides a one-click update process, handling mixed content rewrites where possible.

“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,” WordPress Core Committer Felix Arntz said in the ticket proposing the feature. “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.”

In WordPress 5.6, there is no clear guidance in the Site Health screen about how to migrate to HTTPS, even though it shows as an issue. The user would need to learn more about how to update it manually, starting with changing the site URLs.

In WordPress 5.7, if HTTPS is supported, the Site Health Status screen will notify users and guide them with a new button that updates the site with a single click. It also migrates the site content on the fly to use HTTPS for URLs. Arntz recorded a video demo of the update:

This change also comes with new environment variables and filters that allow hosting providers to change the URLs linked in the HTTPS status check in Site Health, so they can more effectively manage it for their customers’ hosting options. This is similar to how hosts can modify URLs for updating the PHP version, which has had a positive impact on getting sites running on supported versions of PHP.

It’s important to note that the streamlined HTTP to HTTPS migration in 5.7 does not handle updating content in the database. Also, if a site’s URLs are controlled by constants, the update is not possible to complete automatically. In these instances, the HTTPS status check on the Site Health screen will inform the user why the site would need to be manually updated.

More technical details are available in the ticket and commit message, and a dev note should be forthcoming.


18 responses to “WordPress 5.7 Will Make It Easier to Migrate From HTTP to HTTPS”

  1. With WP-CLI’s search and replace the process was easy and I never saw it as a major inconvenience, but it sounds like a good update. My understanding by reading the article is that we will probably have to do the search/replace anyway, so WP-CLI will still be the way to go, at least for me.

    Having relative URLs in general might be an interesting feature on the same direction, but I remember reading an old discussion about that, concluding that it’s not something that will be implemented.

  2. Are we to understand that since URLs in the database will not be changed, there will be protocol rewrites in every page load, potentially impacting performance… vs a case where all HTTP are rewrote to HTTPS using a search-replace opération?

    And once HTTPS is activated, will Site Health consider the site « secure », even though in reality, there remains mixed content in the database?

    • Correct, the protocol won’t be changed in the database, but on the fly. The dynamic replacement is very simple, I would be surprised if it had a noticeable difference in performance.

      And yes, Site Health will consider the site “secure” as long as it is served over HTTPS. It doesn’t check the contents of the database.

  3. This is great! Like the security changes, this is a little detail that provides a big improvement. Maybe the next little detail with big impact could be better built-in oauth2 support with the WordPress json api? Currently it only works with the login cookie without help of a plugin.

      • Hello Timothy,

        Thanks, I did read that but did not look further into it until you mentioned it.

        I see this is user specific, which in the scheme of things is a good idea. What would be cool is to have a 2nd password, where the one you see today is only for refreshing a password (like a refresh token in oAuth2), and also a 3rd password that acts as the client secret. I guess what I would like to see is true oAuth2.

        If there was a way to issue client ID’s and secrets via an API, you would be able to revoke clients and it would also allow any user to the blog to authenticate with the client, in theory. The site may want to limit client access to specific users like your doing now. Very complicated.


  4. I’d have to agree with Anh. Beginners probably aren’t checking site health.

    I’m curious if they’re even aware that they need to secure their site. I was working with a client yesterday and they had no idea this was a necessity. He doesn’t sell anything online so he didn’t think he needed it.

    Does this new feature actually install the SSL certificate from the host? Or does the certificate need to be installed first for this to work?


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: