I’ve had this problem occur sporadically and can’t seem to nail exactly what causes it. I’ve found that deleting the cookies for the site makes the login work again. I’ll be working on a quick bug fix for version 1.9.1 and hopefully I can figure out what’s causing it.
If you still need the plugin, try using version 1.8.5 for the time being. You can download it from http://downloads.wordpress.org/plugin/wordpress-https.1.8.5.zip.
I’ve been trying to get HTTPS working on on e of my sites using the Shared SSL option, and having some problems. I’m not sure if these existed before, it may be a WP 3.2-related problem.
When I turn on the Shared SSL option, when visiting my site form the Shared SSL URL, the page fails to load stylesheets and JavaScript code.
Looking at the source, none of those URLs have been changed to the shared SSL URL. Turning on the “Disable Automatic HTTPS” option fixes the URLs for stylesheets but the JavaScript URLs still point to https://[non-Shared SSL blog URL].
Is there a way I can fix this?
Thanks.
Hi lucasec,
It’s strange that Disable Automatic HTTPS would have that effect. It certainly sound like something is funky. Could you provide a link to the page?
Thanks,
Mike
The WordPress install’s usual address is http://www.miltb.com . miltb.com is an add-on domain on my hosting package which has a primary domain of lucasec.com. I actually do have a dedicated SSL but it only covers http://www.lucasec.com.
Here’s my WordPress HTTPS config:
Internal HTTPS Elements – CHECKED
External, Bypass check – UNCHECKED
Disable Automatic HTTPS – CHECKED
Force SSL – UNCHECKED
Shared SSL – CHECKED, Host: https://www.lucasec.com/ext/bandwebsite/wpblog
Force Shared SSL Admin – UNCHECKED
When I visit this URL, some stuff loads using the Shared SSL URL, but other content loads using https://www.miltb.com, which produces a certificate error.
Permalinks don’t work, but I can remedy that by moving some folders around.
Hi lucasec,
It appears as if something is preventing the plugin’s output buffering method. I would try disabling other plugins to see if one of them is interfering. If that’s the case, I’m sure I can come up with a bug fix.
I would like to get an admin account on the blog so that I can modify my plugin to try to come up with a bug fix. If that’s okay, email the details to mike[at]mvied[dot]com. If you’re uncomfortable with that, that’s understandable, but I won’t be able to diagnose why the plugin isn’t functioning without admin access.
Thanks,
Mike
Admin access should be fine.
Before I do that though I’m going to go ahead and check all my plugins for conflicts.
Alright, sounds good. I would try disabling all other plugins as an initial test. That should tell you right away if it’s another plugin. If it works after that, start turning them on one by one. If it is another plugin interfering, I’d still like to get in there and see if I change something up so that it works with the other plugin. So far I haven’t had any issues with other plugins and I’d like to keep it that way. 🙂
I’ve disabled all the plugins and the problem is still present, but with all the other plugins disabled the only bad URLs in the source are the header image in the theme and some metadata about the XMLRPC pingback.
To further troubleshoot I set up a clean wordpress install at test.miltb.com. All I did was install and then go add the WordPress HTTPS plugin.
The shared ssl URL is set to: https://www.lucasec.com/test/
When I go to that URL, the stylesheets try to load from https://test.miltb.com until I turn on “Disable Automatic HTTPS”, then it’s just the header image and Javascript that won’t load, which can be seen on https://www.lucasec.com/test/?p=1#comments.
Excellent, that’ll be perfect for me to test on. Shoot me an admin login for the test site and I’ll see what I can come up with.
Oh, and the reason they load when you use Disable Automatic HTTPS is that the URL’s get changed to http://test.miltb.com/wp-content/themes/twentyeleven/images/headers/shore.jpg rather than https://test.miltb.com/wp-content/themes/twentyeleven/images/headers/shore.jpg so they work.
This would not be happening if the plugin’s output buffering method was working properly. The URL’s would be fixed to the Shared SSL URL.
Well, I was wrong. The plugin just wasn’t prepared to handle this particular case when using Shared SSL.
Copy the wordpress-https.php file from the test site to your live site and let me know if that fixes it. I’ll be sure to work this into a bug fix release today. I’ve got some other fixes that need to go out.
I’ve got it doing what I need it to now. There’s still a few URLs that are https://www.miltb.com, but the scripts are working, which was all I need to work for my purposes.
It might be worth looking at https://www.lucasec.com/bw (I changed the URL) as some feed links still seem to be incorrect but the scripts now are using the right URLs.
I’ll let you know if I come across any more problems.
That is intended. Generally people don’t want their site feeds over HTTPS, plus it doesn’t affect the security of the site, so the plugin doesn’t mess with it. The only time the feed URL is touched is when Disable Automatic HTTPS is enabled because WordPress changes every URL it can to HTTPS, which is generally not desired.
All of the changes I made will be in version 1.9.1. Let me know if you find anything else.
Ok, I will. I conveniently just accidentally completely deleted one of my WP sites so any URLs I posted above may be down until my backup restores 🙁 .
Ok with that crisis averted, I can get back to checking for bugs and such.
Also, please let me know if you still need the test site, otherwise I’ll delete it. I have no problem with keeping it around if you’re still using it though.
