[Plugin: WordPress HTTPS (SSL)] Admin CSS Mangled

Hey Mark,

I don’t think it will fix your issue, but try updating to 3.0.2. If it doesn’t fix it, would you mind if I take a look at your site? I’d really like to get it fixed. I certainly don’t have that issue in a similar setup that I use to test the plugin with.

Thanks,
Mike

Hi Mike,

Sure, I’ll try that and let you know. I’ll be happy to show you the site if it’s still not working.

Mark

Hi,

On first test, I see two issues:

1) The settings aren’t saving the hostname. In this case, it’s a blog in a subdirectory, so the hostname is:

domain.com/~username/subdirectory

However, it always reverts to:

domain.com/~username

And when I try to login via HTTPS, I get the same redirect loop I had before (possibly related to the item above).

I’ll keep testing and let you know.

Thanks,

Mark

Hey Mark,

The plugin knows the blog is in a subdirectory, so it strips it off. That’s not a bug.

It’s possible that you’re going over a messed up proxy.

Thanks,
Mike

Hi,

I’ve tested on another site on the same server, and so far I’m not seeing those problems again.

We are using a Varnish proxy, but that shouldn’t apply because it passes all wp-admin requests directly to Apache. Should we leave the proxy setting “Off”?

I am seeing another issue: if you upload media while logged in via the special HTTPS hostname, the URL of the uploaded media is in the format:

https://host.ssldomain.com/~username/wp-content/uploads/2012/04/image.png

Of course, it should ideally be in the format:

https://sitedomain.com/wp-content/uploads/2012/04/image.png

In other words, media URLs should take on the front-end domain name instead of the special (shared SSL certificate )hostname.

Any way around this?

Thanks,

Mark

Hey Mark,

The proxy setting is only for if the server can never detect if the page is HTTPS. If HTTPS is Yes on HTTPS pages, you don’t have to worry about it.

That URL isn’t permanent or anything. Any images on the front-end will be referenced by HTTP on HTTP pages.

Thanks,
Mike

Hi Mike,

I think the media URL is a problem. That URL does seem to be permanent, for example look at this post:

https://anothertry.wpcdn.com/uncategorized/hello-world/

The uploaded image (the metallic WordPress logo) has this URL:

https://host1.wppronto.com/~anothert/wp-content/uploads/2012/02/wp-logo.jpeg

…which is undesirable for aesthetic reasons, and because it can mess up caching and CDN plugins that expect the public domain name instead of the special SSL hostname.

I know that this could be manipulated by hardcoding the wp-config file…I think something like:

define(‘WP_CONTENT_URL’,’https://wpprontocdn/wp-content’);

But we don’t want our novice users to have to do things like this. So is there any way the plugin could do that and keep uploaded media with the desired public URL instead of the special SSL URL?

Thanks,

Mark

Hey Mark,

Looks like there was a typo in the code, haha. Wait about 5 minutes and re-install the plugin from the repository. Let me know if the image changes back to HTTP.

Thanks,
Mike

Hi Mike,

I re-installed, but the new version doesn’t work for me. The admin login page CSS is gone (the ugly bare-bones form instead of the styled form).

Then, when I try to login, I just get a 404.

This is on the same site that was working prior to this update.

Thanks,

Mark

Update: I realized that in the re-install, the hostname had been reset to default. So that might explain the behavior mentioned in my post above.

However, now I can’t set the hostname. When i use the same hostname I was using before, I get the error that there is an invalid WordPress install at that host.

Not sure what to do…

Thanks,

Mark

Hi Again,

I deleted and reinstalled WordPress, and the plugin is working…EXCEPT:

Uploaded images still have the wrong URL. It’s still https and uses the SSL hostname instead of the front-end hostname.

Example:

https://anothertry.wpcdn.com/?p=1

The memory graph still has the problem URL.

Sorry!

Mark

Hey Mark,

Any time you re-install or remove the plugin, you’ll probably want to access your admin panel over HTTP since the secure host will be set to the default.

Working on a fix now. Going to take a little break. I’ve been at it all week and this weekend. ??

Thanks,
Mike

Hey Mark,

This should be fixed in the latest push. Again, reinstall and let me know the results. Last time I didn’t verify the fix, I just noticed a typo and assumed. This time I actually tested it. ??

Thanks,
Mike

Hi Mike

So far everything seems to work with the new version.

I am noticing that SSL login seems to take a long time. Is that normal, or is there any way around it?

I’ll keep testing and let you know if I experience any other issues. But so far it looks good.

Thanks for your hard work and continued efforts on this.

Mark

Hey Mark,

There are a lot of variables that can play into that. There are a few places in my plugin that I know are performance issues, but I don’t know how to fix them. They all stem from the same problem.

When a user sets up a secure site on a subdomain, I change it so that the cookies are set for the base host. That way if you have example.com and secure.example.com, you will be logged into both.

There is no good way to figure out the base host of a random URL. The only way I found to do it was to strip subdomains off of the host until you hit something that’s not a valid domain.
secure.example.com – good
example.com – good
com – bad

So, example.com is the base domain. In order to test if a domain is valid, you have to make a request from the server to that domain. This generally isn’t a problem, but has the potential to slow down the page when you login, update the plugin settings, or update the plugin. These are all the places where those kinds of calls are made.

Edit: Just to clarify, I’m not saying my plugin is the cause, but it’s possible. HTTPS is always going to be slower because of the encryption/decryption process. Like I said before, there are also other factors that can play into it.

Thanks,
Mike