This bit of code supplied with CartThrob does some fancy stuff on the checkout page.

<script type="text/javascript" src="{path='store/cart.js'}"></script>

However, we go to HTTPS on this page and the JS doesn't get served up. We get this error:

The page at https://domain.com.au/store/checkout ran insecure content from http://domain.com.au/store/cart.js.

The JS file has template variables and all sorts in it, so I guess they why the CT people have it a template file? Either way, can I get it with HTTPS?



One potential solution would be to switch your site URL to a protocol relative URL, i.e. instead of your Site URL being defined as http://mysite.com you could change it to simply //mysite.com. This way, when your browser requests cart.js it will request the https variant if you're on a secure page and the http one if you're not.

If you take this approach and you're using either the {path} or {stylesheet} variables to link to your CSS then there is (naturally) a corresponding Internet Explorer bug to be aware of.


Deeper down the rabbit hole we go... it turns out EE's currently pretty buggy with respect to protocol relative URLs. On top of that, the buggy code is replicated at least three times within EE's codebase. It's not pretty. I've posted a bug report which is replicated below:

Protocol relative URLs break path variables

The remove_double_slashes method currently converts absolute URLs like ‘//mysite.com/about’ into relative (and broken) URLs like ‘/mysite.com/about’. The attached regex tweak fixes the problem for me, but I haven’t tested it extensively.

It appears that this fix needs to be applied in at least three (!?) different places, all of which replicate the same function more or less identically:

  • remove_double_slashes() in EE/libraries/Functions.php
  • reduce_double_slashes() in CI/system/helpers/string_helper.php
  • _remove_double_slashes in CI/system/libraries/Pagination.php

A small tweak to the regex seems to have solved the problem for me, but I haven't tested it extensively.

Find this:

return preg_replace("#(^|[^:])//+#", "\\1/", $str);

Replace it with this:

return preg_replace("#([^/:])/+#", "\\1/", $str);
  • I tried this suggestion Dom. But some of my links ended up breaking. The would convert to: mysite.com/mysite.com. No doubt it is operator error. So I changed it all back to the standard setup – Mike Dexter Dec 1 '12 at 5:22
  • It's not you - I've just tried this and appears that EE routes all {path} vars through a remove_double_slashes() method... you can imagine why that wouldn't be very helpful. I'll update my post if I can find a fix (it will be a core mod unless EllisLab implement it). – Dom Stubbs Dec 1 '12 at 12:04

It might just be an issue of making your {path} URIs get served via HTTPS when the page you're viewing is being accessed via HTTPS. We have some logic in our config.php that handles it; the important bit being if($_SERVER['HTTPS'])

Paths & URLs

$root_path = '/home/project/';
$private_path = $root_path . 'private_ee/';
$public_path = $root_path . 'public_html/';

    $public_url_component_0 = 'https';
    $public_url_component_0 = 'http';

if($_SERVER["SERVER_NAME"] == 'www.example.com'){
    $public_url_component_1 = $public_url_component_0 . '://www.example.com';
    $public_url_component_2 = '/';
    $public_url_component_1 = $public_url_component_0 . '://staging.example.com';
    $public_url_component_2 = '/~project/';

$public_url = $public_url_component_1 . $public_url_component_2; 

$config['base_url'] = $public_url;
$config['site_url'] = $public_url;
$config['cp_url'] = $public_url . 'admin.php';
$config['theme_folder_path']   = $public_path . 'themes/';
$config['theme_folder_url']    = $public_url . 'themes/';
$config['third_party_path'] = $private_path . 'third_party/';
$config['tmpl_file_basepath'] = $private_path . 'templates/'; 
$config['snippet_file_basepath'] = $private_path . 'snippets/';
  • Thanks for your suggestion, Nick. Still very new to EE so not sure what it all means :) – Mike Dexter Dec 1 '12 at 5:20

To get around the issue I place the JS in a "Low Variables" with early parsing turned on. Which got around the HTTPs issue and also allowed the variables in the JS to grab the required EE data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.