Porting self-hosted Wordpress to HTTPS: mixed content

[jsha]

When moving a self-hosted Wordpress blog from HTTP to HTTPS (by editing the site URL at /wp-admin/options-general.php), I run into trouble because image links embedded in existing posts still point to HTTP, even though those images are hosted by my Wordpress blog and now support HTTPS.

It would be great if Wordpress could automatically rewrite images in existing posts when site URL is changed to HTTPS.

[joemcgill]

Related #15928

[SergeyBiryukov]

#28521 would resolve this.

[thomaswm]

Related: #33691

[johnbillion]

#33691 was marked as a duplicate.

[thomaswm]

Replace local HTTP URLs in post content using a filter

[thomaswm]

Send "Upgrade Insecure Requests" HTTP header

[thomaswm]

I've uploaded two different patches:

• 29727.diff​ is a nearly exact copy of @wonderboymusic's patch on #28521. It replaces local non-HTTPS URLs using a filter.
• 29727.2.diff​ sends an ​Upgrade Insecure Requests HTTP header when the page is requested through HTTPS. This was suggested in ​a comment on make/core.

[SirLouen]

Reproduction Report

Description

❌ This report validates that the issue can be reproduced.

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Bug Reproduction

1. For testing this with wordpress-develop I'm using a combination of PRs: ​PR 8787 and ​PR 8977 which provide a perfect scenario: I can create a tunnel with ngrok with ngrok http https://localhost:8890
2. First I add some posts with images through the non HTTP version ​http://localhost:8889
3. Then I add both SITEURL and HOMEURL to the ngrok https upgraded version URL
4. Here I can see the SRCSET being set to the right URL, despite the SRC is wrong and might cause multiple failures without the SRCSET in place.

Actual Results

1. ❌ Error condition doesn't occur any more

Additional Notes

• I know, first hand, that this has been historically frustrating, and a search and replace with wp-cli has always become very handy in these situations. For HTTPS, it looks logical to perform such search and replace internally because it has always been something of priority (as commented in #28521).

• But with the introduction of dynamically generated SRCSET, SRC is being completely ignored; hence, it doesn't matter much that it's still pointing to the old URL. Also, all scripts and stylesheets are upgraded dynamically, so most problems regarding with HTTPS upgrade (or even domain change), are not as problematic, as they have historically been.

• Although it's always recommended to run the full search-replace to avoid potential troubles with scheme/URL misalignment with the new version. I would like to see a testing scenario where taking the original attachment URL could be a problem that required scheme upgrade for further testing (needs-test-info)