Make WordPress Core

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#22811 closed defect (bug) (fixed)

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

Reported by: Daedalon Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Site Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)'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. with the search string appended after the "=", this being the only way to search on 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.


  1. Go to a https URL (eg. ).
  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 that point to 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)

#1 @SergeyBiryukov
9 years ago

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

#2 @webaware
9 years 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:!wp+wp_enqueue_script

#3 @wycks
9 years ago


Also you don't need any special URL, just go to 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 9 years ago by wycks (previous) (diff)

#4 @SergeyBiryukov
9 years ago

#24091 was marked as a duplicate.

#6 @iandunn
9 years ago

  • Cc ian.dunn@… added

#7 @wycks
8 years ago

It seems some progress has been done here but one page still breaks the layout( I did not test all of them),

Also <img> tags still load over HTTP.

Last edited 8 years ago by wycks (previous) (diff)

#8 @iandunn
8 years ago

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

#9 follow-up: @Daedalon
8 years 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?

#10 in reply to: ↑ 9 @ocean90
8 years ago

Replying to Daedalon:

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

#11 @Daedalon
8 years ago

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

#12 @Otto42
8 years ago

  • Milestone 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.

#13 @Otto42
8 years 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.