Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#22811 closed defect (bug) (fixed)

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

Reported by: daedalon's profile 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
11 years ago

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

#2 @webaware
11 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
11 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,).

Version 0, edited 11 years ago by wycks (next)

#4 @SergeyBiryukov
11 years ago

#24091 was marked as a duplicate.

#6 @iandunn
11 years ago

  • Cc ian.dunn@… added

#7 @wycks
11 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 11 years ago by wycks (previous) (diff)

#8 @iandunn
11 years ago

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

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

Replying to Daedalon:

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

#11 @Daedalon
11 years ago

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

#12 @Otto42
11 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
11 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.