SSL Insecure Needs 3.5 Compatibility?

G’day Jason,

I did actually test the plugin with WP 3.5 (since beta1) and all is working OK for me. Can you provide me a link to your website so that I can look at what is triggering the problem? It could be a specific plugin or theme issue.

You can find out which files are causing problems by opening Google Chrome’s developer console, which lists the files blocked as insecure content.

cheers,
Ross

Thanks Ross, unfortunately this site is internal. But I did do a console view from inspect element and it was showing that the pages were trying to load http files instead of https. I went to the theme and found it was loading the location thus:

<link rel="stylesheet" type="text/css" href="<?php bloginfo('stylesheet_url'); ?>" media="screen" />
<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo('template_directory'); ?>/css/effects.css" />

Our IT department did a roll back so we are back to 3.4.2 and everything is working again. The theme has always been loading the files this way so I’m not sure why going to 3.5 changed anything. I unfortunately don’t have access to the db so I can’t look to see where all the stored http values are, which is why I’ve been using this plugin ??

I’ve checked all sorts of settings like making sure home and site url specify the https but it wouldn’t take and I ended up in a loop when I tried to force admin ssl through the wp-config.php file.

Since we are back to the old version I can’t really look into this more. But thanks for your speedy reply!

G’day Jason,

That sounds like a regression in WP 3.5, as those two bloginfo() calls should be returning https links. I’ll take a look and maybe submit a bug with WordPress.

cheers,
Ross

@jason: I just tried this in a test install, and it worked fine (without my plugin). I think there’s something else going on with your website. Perhaps when you get some time, set up a development copy and upgrade to WP3.5, then turn off all plugins and see if it still has the problem.

cheers,
Ross

I’ve also seen this issue with 3.5. It seems that 3.5 is not taking https into account on all of the links.

@pwood: are you able to provide a link to an example site? Have you been able to pinpoint where a WordPress function isn’t taking SSL into account?

For all the basic recommended practices (e.g. plugins_url(), get_template_directory_uri(), get_stylesheet_directory_uri()), it seems to work OK.

Taking a quick look, I see that these are not taking SSL into account:

bloginfo( 'stylesheet_url' )

get_template_directory_uri()

plugins_url()

The site is https://thebowserreport.com. Currently you will see some of the scripts/stylesheets loaded twice in the head. I hardcoded a few in as a fall back for Google Chrome users who don’t tell chrome to display insecure files.

I submitted a bug report to WordPress about this earlier today. Hopefully I was specific enough… I had these issues when I switched to the default twenty-eleven theme with no plugins too. Even the files bundled with WordPress such as the jquery script and Admin css files are loaded as HTTP.

@pwood: bloginfo('stylesheet_url'), get_stylesheet_directory_uri() and plugins_url() all ultimately should be calling is_ssl() to determine the protocol scheme to use. It’s possible that there’s a bug in the twisted logic of set_url_scheme() that is in the mix there somewhere, but I reckon the most likely problem is that your server isn’t passing on one of the server variables that WordPress is expecting to help it identify an SSL connection.

Can you please drop this (only this) into a .php file and run on your server, then tell me what values you get for _SERVER['HTTPS'] and _SERVER['SERVER_PORT']?

<?php
phpinfo();
?>

@pwood: perhaps you can send me a link to that phpinfo() page on your server, via my contact page.

@webaware just sent you the link!

@pwood: right, your server is hidden behind a load balancer or other forwarding service that isn’t passing any information about the protocol/port used to access it externally; there is no _SERVER['HTTPS'], and _SERVER['SERVER_PORT'] says port 80 which is the regular, non-SSL port for HTTP.

In some such situations, like Amazon’s ELB servers apparently, you get an additional server variable _SERVER['HTTP_X_FORWARDED_PROTO'] which has the value “https” when accessed over SSL. But your server doesn’t have that either. Frankly, I can’t see anything in your phpinfo() output that
indicates that you were accessed via SSL.

You’re going to have to talk to your host about this. They probably have a simple configuration they can set (or tell you how to set) that will let you detect SSL. See this answer on Stack Overflow and maybe tell your host about it. If they can’t just set _SERVER['HTTPS'] then maybe we can write a simple plugin that uses the set_url_scheme filter to kludge it up ??

Good old Network Solutions. This could be interesting with them…. Thanks so much for your help though!!!!! Many many thanks.

Oh dear, this doesn’t sound good. I’ll see if I can kludge something up using that filter.

According to Network Solutions, there is code that must be placed in the wp-config file to fix this, and they would be happy to share this with me if I paid for their “My Time Support.”

Well, I guess you could pay them for their “My Time Support”, or you could just drop this gist into your plugins folder and enable it, then set your site URL to use https://

https://gist.github.com/4688802

What is does is test to see if your site URL is set to https, then it sets _SERVER['HTTPS'] so that is_ssl() detects the page as SSL.

NB: it will always detect the connection as SSL, if you set your site URL to https!