scriptygoddess

One of my clients had set it up so that one particular page in their WordPress install would load as https:// and even though they changed all links they could find in their template to use root-relative links, they were still getting complaints from IE about the page loading some secure and non-secure items. A look through the source code revealed that two plugins in particular (an event manager plugin and cforms plugin) pulled in their CSS or javascript files without the https. It probably got these settings from the main WordPress install, which wasn't set to use ALL https – the had just set it up so that this one page would be (using a special template for https pages). But there was no way to get that information to the plugin… So I needed to do a little hacking to the plugin(s) and add in a conditional statement that would check if the page being viewed was https – and if so, swap out http:// for https:// in the path to the file.

In the case of the cforms plugin, the file I had to modify was cforms.php – the line I found that pulled in the file path looks like this:

$cforms_root = $cformsSettings['global']['cforms_root'];

So, just below that I added this:

if(isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "on") {
$cforms_root = str_replace("http://","https://",$cforms_root);
}

Pretty simple. Of course, if/when we need to upgrade the plugin, the change will be overwritten – but it's pretty easy to add back in…

(Apparently, I'm not the only one with this issue…)

In the case of the event manager plugin, the file I modified was dbem_events.php:

So just below this:

function dbem_general_css() {  
$base_url = get_bloginfo('url');

I added this:

if(isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "on") {
$base_url = str_replace("http://","https://",$base_url);
}

No more complaints from IE.