WordPress.org

Make WordPress Core

Opened 17 months ago

Closed 8 months ago

Last modified 8 months ago

#22811 closed defect (bug) (fixed)

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

Reported by: Daedalon Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: WordPress.org site Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

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

  1. Go to a https URL (eg. https://wordpress.org/extend/plugins/types/ ).
  2. Bookmark the page. Imagine a few months happening before the next step.
  3. Click the Description tab (when browsing normally you'd click another tab in between but it's not a necessary step here).
  4. 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.
  5. 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.

Change History (13)

comment:1 SergeyBiryukov17 months ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to WordPress.org

comment:2 webaware17 months ago

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

comment:3 wycks13 months ago

+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.

Last edited 13 months ago by wycks (previous) (diff)

comment:4 SergeyBiryukov12 months ago

#24091 was marked as a duplicate.

comment:6 iandunn10 months ago

  • Cc ian.dunn@… added

comment:7 wycks9 months ago

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.

Last edited 9 months ago by wycks (previous) (diff)

comment:8 iandunn8 months ago

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

comment:9 follow-up: Daedalon8 months ago

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?

comment:10 in reply to: ↑ 9 ocean908 months ago

Replying to Daedalon:

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

comment:11 Daedalon8 months ago

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

comment:12 Otto428 months ago

  • Milestone WordPress.org deleted
  • Resolution set to maybelater
  • Status changed from new to closed

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

comment:13 Otto428 months ago

  • Resolution changed from maybelater to fixed

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.

Note: See TracTickets for help on using tickets.