#1768 - SSL breaks things on site when enabled and then disabled
-
By PDStig
- Added
- 12 views
| Identifier | #1768 |
|---|---|
| Issue type | Major issue (breaks an entire feature) |
| Title | SSL breaks things on site when enabled and then disabled |
| Status | Completed |
| Handling member | PDStig |
| Addon | core |
| Description | When 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 reproduce | 1. 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 information | See screenshots.
Clearing cache did not resolve this matter. |
| Funded? | No |
| Commits |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
SSL still breaks things when enabled/disabled but they fix themselves, probably as a result of cron or something.
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.
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.
Did you set the hidden CDN option in Composr?
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.
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.
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.
(Click to enlarge)
(Click to enlarge)
I find it strange you're getting those errors. I've never been able to reproduce those 522s.
(Click to enlarge)
(Click to enlarge)
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.
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.