Make WordPress.org's links use http or https by auto-detection

[Daedalon]

WordPress.org's links are hardcoded to use the http protocol despite the pages also being viewable using https (which is great). This causes unwanted hassle with eg. bookmarks, showing which pages were or were not visited and so forth.

An example of the steps to reproduce:

1. Go to a https URL (eg. ​https://wordpress.org/extend/plugins/search.php?q= with the search string appended after the "=", this being the only way to search on WordPress.org via https as all the forms redirect to http).
2. Type anything in any of the search forms. -> A warning is shown that you're being redirected to an unencrypted page.

OR

3. Go to a https URL (eg. ​https://wordpress.org/extend/plugins/types/ ).
4. Bookmark the page. Imagine a few months happening before the next step.
5. Click the Description tab (when browsing normally you'd click another tab in between but it's not a necessary step here).
6. You're now on a page that you haven't bookmarked. Bookmark it, because you like this page and don't remember having bookmarked a rather identical page months ago.
7. You end up having multiple bookmarks for the same pages.

The fix for all these is rather easy on paper: have all links on wordpress.org that point to wordpress.org automatically use the protocol used for loading the page currently being viewed. Start with having forms' targets use this, then navigational links, and later consider either auto-converting links in page contents (eg. plugin descriptions) or mentioning the possibility of using :// links for this next to editors.

[webaware]

This has another impact, on searches from DuckDuckGo. If you search using bang notation, !wp, DuckDuckGo sends you to an https link, which fails to load any results due to insecure content (including scripts, CSS, images).

Try for yourself: ​http://duckduckgo.com/?q=!wp+wp_enqueue_script

[wycks]

+1

Also you don't need any special URL, just go to ​https://wordpress.org/extend/plugins/ for example and it won't load approximatly 13 files (css, js,).

Another issue are people using the "HTTPS Everywhere" Chrome and Firefox plugins, and I think some of the AD removers also force HTTPS when available.

I think it's best to either turn it off or make it work.

[SergeyBiryukov]

#24091 was marked as a duplicate.

[fulldecent]

From duplicate https://core.trac.wordpress.org/ticket/24091

This shows what the page looks like when loaded from the https URL.

https://core.trac.wordpress.org/attachment/ticket/24091/Screen%20Shot%202013-04-15%20at%2011.15.19%20AM.png

[wycks]

It seems some progress has been done here but one page still breaks the layout( I did not test all of them), ​https://wordpress.org/showcase/

Also <img> tags still load over HTTP.

[iandunn]

Before this can be done, s.wordpress.org will need an SSL certificate setup (​#meta72).

[Daedalon]

Fulldecent: Unfortunately clicking that .png link or the ticket link only leads me back to this page. Perhaps a WP Trac maintainer could be notified of this odd behavior somehow?

In the meanwhile, if anyone has a copy of that attachment, could it be added to this ticket?

[ocean90]

Replying to Daedalon:

Works for me. The image is also attached to #24091.

[Daedalon]

Thanks, Ocean90. Now it works for me too. Previously did not, neither before or after login.

[Otto42]

These will need to be handled on a case by case basis. Make new tickets on meta.trac as necessary.

[Otto42]

Showcase site mostly fixed. Any further sites showing this same issue (incorrect use of http for CSS/images when browsing via https) should receive their own separate tickets on meta.trac.