View Issue Details

IDProjectCategoryView StatusLast Update
0001768Composrcorepublic2020-03-22 22:10
ReporterPatrick SchmalstigAssigned To 
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0001768: SSL breaks things on site when enabled and then disabled
DescriptionWhen using HTTPS and SSL on parts of the website, if you enable a section of the site to use SSL, it will break WYSIWYG. If you later disable the SSL on that section of the site, it will sometimes cause things to break and no longer function properly until you enable SSL again. An example is the CMS and Admin Zone menu pages.
Steps To Reproduce1. Enable SSL on some places, including the Admin Zone.
2. Notice how WYSIWYG doesn't function properly.
3. Disable SSL on those areas.
4. Now notice the format of the pages for admin menus and CMS are now messed up.
5. Re-enable SSL.
6. The format is correct again, but of course WYSIWYG doesn't work.
Additional InformationSee screenshots.

Clearing cache did not resolve this matter.
TagsNo tags attached.
Attach Tags
Time estimation (hours)
Sponsorship open


Patrick Schmalstig

2015-01-12 00:15

administrator (827,398 bytes)

Patrick Schmalstig

2015-01-12 18:07

administrator   ~0002435

Last edited: 2015-01-12 18:07

View 2 revisions

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.

Chris Graham

2015-01-12 19:09

administrator   ~0002436

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.

Chris Graham

2015-01-12 19:14

administrator   ~0002437

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

Chris Graham

2015-01-12 19:26

administrator   ~0002438

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.

Chris Graham

2015-01-12 19:29

administrator   ~0002439

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

Chris Graham

2015-01-12 19:39

administrator   ~0002440

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.

Chris Graham

2015-01-12 19:42

administrator   ~0002441

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.

Chris Graham

2015-01-12 19:42

administrator   ~0002442

Fixed in git commit fef0fca ( - link will become active once code pushed)

A hotfix (a TAR of files to upload) have been uploaded to this issue. These files are made to the latest intra-version state (i.e. may roll in earlier fixes too if made to the same files) - so only upload files newer than what you have already. Always take backups of files you are replacing or keep a copy of the manual installer for your version, and only apply fixes you need. These hotfixes are not necessarily reliable or well supported. Not sure how to extract TAR files to your Windows computer? Try 7-zip (

hotfix-1768, 2015-01-12 8pm.tar (31,744 bytes)

Chris Graham

2015-01-12 19:44

administrator   ~0002443

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

Patrick Schmalstig

2015-01-12 21:08

administrator   ~0002445

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.

Chris Graham

2015-01-26 10:12

administrator   ~0002475

I went onto your site to try to reproduce what you reported in 0001777. 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.

Chris Graham

2015-01-26 10:13


Chris Graham

2015-01-26 10:13


Chris Graham

2015-01-26 10:14

administrator   ~0002476

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

Patrick Schmalstig

2015-01-26 18:57

administrator   ~0002478

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.

Patrick Schmalstig

2015-01-26 19:07


1.jpg (152,711 bytes)
1.jpg (152,711 bytes)

Patrick Schmalstig

2015-01-26 19:07


2.jpg (148,732 bytes)
2.jpg (148,732 bytes)

Patrick Schmalstig

2015-01-26 19:08

administrator   ~0002479

Last edited: 2015-01-26 19:14

View 2 revisions

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.

Chris Graham

2015-01-26 21:25

administrator   ~0002482

Do you think you could make my user an admin?

Patrick Schmalstig

2015-01-26 21:33

administrator   ~0002483

Done ^^

Chris Graham

2015-01-26 21:41

administrator   ~0002484

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.

Patrick Schmalstig

2015-01-26 21:43

administrator   ~0002485

Ah that makes sense

Chris Graham

2015-01-26 21:44

administrator   ~0002486

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).

Chris Graham

2015-01-26 22:36

administrator   ~0002487

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.

Patrick Schmalstig

2015-01-27 01:19

administrator   ~0002488

Thank you a lot Chris ^^

Issue History

Date Modified Username Field Change
2020-03-22 22:10 Chris Graham Category ssl => core