#1999 - main_recent_galleries comcode block is not serving gallery previews over HTTPS when HTTPS enabled
-
By PDStig
- Added
- 5 views
| Identifier | #1999 |
|---|---|
| Issue type | Minor issue (breaks specific functionality) |
| Title | main_recent_galleries comcode block is not serving gallery previews over HTTPS when HTTPS enabled |
| Status | Completed |
| Handling member | Chris Graham |
| Addon | galleries |
| Description | I've just enabled HTTPS site-wide on my website, lovinity.org . However, I am noticing that the main_recent_galleries comcode block is not serving the preview images on recent galleries list over HTTPS when it should, thus triggering mixed content warnings. |
| Steps to reproduce | 1. In a page where HTTPS is enabled, add the main_recent_galleries block. Make sure galleries show up in it.
2. Access the page with the main_recent_galleries block.
3. According to Google Chrome, it is serving preview images over HTTP when it should be doing so over HTTPS. |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
By making the base URL in info.php https://?
You later say, "In a page where HTTPS is enabled", so I wonder if you changed the base URL, or just checked off all pages as HTTPS.
Do you have a URL on your live site to reproduce the problem?
And no, I read about base URL changing making Composr not work, so I'm using the HTTPS setting and I have all pages check marked.
EDIT: Also, in case you're wondering why I'm using HTTPS everywhere, apparently if I want Arrowchat to use HTTPS all the time, every page that it runs on also has to be HTTPS.
My only other concern is that the jwplayer serves its logo watermark over HTTP... so if you go to play a video or audio using it, you'll get a mixed content warning.
To fix jwplayer, if it is in HTML5, change "http://l.longtailvideo.com/html5/" to "https://l.longtailvideo.com/html5/" in the JAVASCRIPT_JWPLAYER.tpl template. I just checked it works and we'll make this an official change. I can't fix it for the Flash version (assuming it fails in that version - I did not check), as that's tied up inside the .swf file.
Your other problem would need fixing with a deep change to block caching:
http://compo.sr/tracker/view.php?id=2002
Just clearing the block cache would have fixed, or triggering something that clears it, or waiting out. So long as you don't use the block on both SSL and non-SSL pages you'll be fine.