This issue mysteriously resolved itself. That is really weird.

SSL still breaks things when enabled/disabled but they fix themselves, probably as a result of cron or something.

This is weird.

It looks like the CSS isn't loading.
For example, in Untitled.jpg, do_next.css hasn't loaded.

I can't see how that would happen. Composr substitutes in https URLs for all CSS files if it is running the current page on HTTPS.

The CSS files used on HTTPS will be different ones to HTTP, but they all generate in the same way and come out of templates_cached. They are simply segregated so that any referenced dependencies within the HTTPS version themselves are referenced over https.

Composr ensures the cache files exist before finishing outputting the page. Sometimes they are wiped out by admin actions, but any subsequent page load would immediately re-generate them.

If if happens again please do a little digging.
See if the .css files in the HTML all load if you open the URLs to them individually (or look for hints of problems in the Chrome developer tools, network tab, and console tab).

It could be some weird caching issue. Something may have cached the URLs as not existing, and that stuck.

I'm going to run some tests locally, bear with me.

Ok my test tells that Chrome will block a CSS file loaded over http, if included on an https site. That may be a clue, so I'll look to see if Composr could somehow be using the wrong protocol.

Chrome console says:
Mixed Content: The page at 'https://localhost/test.php' was loaded over HTTPS, but requested an insecure stylesheet 'http://localhost/test.css'. This request has been blocked; the content must be served over HTTPS.

Are you using CloudFlare?
Did you set the hidden CDN option in Composr?

Ok, I couldn't reproduce any general problem, or see any way the code could cause one. Unless you have CloudFlare and CloudFlare is messing with our CSS and not realising when something has switched over to HTTPS.

HOWEVER, I did find a problem specifically with WYSIWYG. A hotfix is coming. It is necessary to empty the template cache after applying the fix.

Automated response: WYSIWYG does not work if a page is accessed via HTTPS yet the site itself is mainly HTTP

WYSIWYG does not work if a page is accessed via HTTPS yet the site itself is mainly HTTP. This is due to a cacheing issue. The template cache must be emptied after applying this hotfix.

Running the site in safe mode could also potentially cause a problem, if you're doing that.

I am running Cloudflare, so maybe that's how that happened.

Thanks for the hotfix. It resolved the WYSIWYG problem under SSL. I have been to create the error in Chrome you described, so I'm wondering if your hotfix also fixed that. I'll keep an eye and let you know.

I went onto your site to try to reproduce what you reported in #1777. However I see SSL is currently not on the members page, but also I continue to get connection errors. I'm attaching some screenshots to the issue. It may well be these connection errors that are causing your problem, not SSL.

(Click to enlarge)

(Click to enlarge)

I plucked those errors out of the Chrome console. The first I took was when I saw WYSIWYG not loading on the signup form.

I can re-enable SSL on the members page for you. I turned it off since it was causing issues with members not being able to change profile info such as their password.

I find it strange you're getting those errors. I've never been able to reproduce those 522s.

(Click to enlarge)

(Click to enlarge)

Aha! I think I found something. I uploaded 1.jpg and 2.jpg.

When enabling SSL on the members zone, 1.jpg happens (resources not served over HTTPS get blocked), which results in 2.jpg when trying to click the save button.

It also results in the style being broken, WYSIWYG not being loaded, etc.

Do you think you could make my user an admin?

Done ^^

Okay, I'm looking at your phpinfo and learning already. Cloudflare isn't connecting through to the site using https, so Composr isn't detecting it as https, so Composr is not serving stuff linked into the HTML as https. However, Cloudflare does provide some meta info. I'll do some tweaking. I'll leave members as SSL when I have it working.

Ah that makes sense

And the editing part of the 'members' page is actually served via AJAX so is not itself actually a page and thus depends on the "tacit HTTPS" detection. If it weren't for this it would have worked anyway (which is why most of the other HTTPS stuff does work, as that is 100% Composr page based).

Ok it all seems fine now that I added support for detecting the cloudflare meta data.

I did get those HTTP errors, but switching to my 3G connection resolved it. Not sure why cloudflare can't relay from my broadband line; I guess maybe it's connecting through to a different cloudflare data centre that's either buggy, or partly blocked on your server's end.

Thank you a lot Chris ^^