[wp-trac] [WordPress Trac] #29727: Porting self-hosted Wordpress to HTTPS: mixed content

[WordPress Trac]

#29727: Porting self-hosted Wordpress to HTTPS: mixed content
---------------------------------------------+---------------------
 Reporter:  jsha                             |       Owner:  (none)
     Type:  feature request                  |      Status:  new
 Priority:  normal                           |   Milestone:
Component:  Media                            |     Version:  4.0
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch https needs-test-info  |     Focuses:
---------------------------------------------+---------------------
Changes (by SirLouen):

 * keywords:  has-patch, needs-testing, https => has-patch https needs-test-
     info
 * type:  enhancement => feature request


Comment:

 == 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: [https://github.com/wordpress/wordpress-develop/pull/8787 PR 8787]
 and [https://github.com/WordPress/wordpress-develop/pull/8977 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.

 [[Image(https://i.imgur.com/sOHFl0u.png)]]


 === 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`)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/29727#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform