Sudden SSL problems have broken my Rapidweaver sites

A couple days ago everything on my site was working perfectly then suddenly I started having all kinds of problems with broken formatting and I am not exactly sure what has caused it. I tried Stacks 3 and the latest version of Foundation but had some problems and decided it was better going back to Stacks 2 in the short term so I uploaded the old version again.

Everything was looking fine in the morning, then suddenly the formatting was all wrong on several pages but it didn’t even seem consistent and would change over time. I eventually traced it to an SSL issue. Chrome and Firefox are refusing to show various parts of the site because they are deemed to be insecure, so I contacted CloudFlare who handle the certificate and after a long wait they came back to say my site was linking to non secure elements that look like the CSS style sheets to me.

Later on I discovered they had reactivated my certificate with a new one just hours before and suddenly I had problems. If you go to Murasaki - Full Service Design Studio - Web Design Cornwall for example in Chrome or Firefox you will see the formatting is a mess. Incidentally another site that I haven’t touched in months also done in Rapidweaver is suddenly having similar problems and that’s not done with Foundation.

CloudFlare are adamant that the problem is at my end and showed me a couple of screenshots showing from my page source. I am not linking to any http pages so it looks like the theme itself or something else. I am wondering if the spec for their SSL certificates has changed overnight.

I went onto the server via FTP and deleted the whole lot in case there was any coding left behind from my experiment with Stacks 3 and then uploaded my old site again from Rapidweaver but nothing has changed.

Can anybody see where I am going wrong here? I have attached a couple screenshots showing the areas of code that CloudFlare says are responsible. To me it looks like something has changed at CloudFlare or the specification of SSL has suddenly become much tougher and is breaking Rapidweaver sites. I am using their flexible SSL setting that should be quite forgiving.

My about page in the link above now looks fine but I’ve changed nothing. The FAQ page is wrong https://colourmanagementpro.com/faq/ and so is the news page https://colourmanagementpro.com/news/

Your SSL page is requesting content (the CSS files) that are not SSL (https) and as such those fetches are being blocked by the browser, hence the messed up styling.

If it were me, I would be sorely tempted to modify these two lines in your FAQ page source to change the http to https:

<link rel="stylesheet" type="text/css" media="all" href="http://colourmanagementpro.com/rw_common/themes/foundation/A.consolidated.css.pagespeed.cf.PN-doqnFqc.css"/>

<link rel='stylesheet' type='text/css' media='all' href='http://colourmanagementpro.com/footer/index_files/A.stacks_page_page1.css.pagespeed.cf.E6HcFezCzk.css'/>

Just to see if it helps. Course, you will need to modify them at source on your host. If those resources are fetchable via SSL that just might get that page up and running again.

Thereafter I would refer to the great Foundation God in the sky about a more permanent fix.
Just my $00.02 of course others may bring deeper insight (is there a setting in Foundation to make fetches secure?)

Update… actually those CSS files change to https when fetched from the browser directly. So they 100% DO support https fetching… I think it’s just the link text itself needs to be changed to https from http. Not sure what is the proper ‘Foundation-y’ way is to accomplish that.

1 Like

I asked Joe and Zeebe about this yesterday but no answer so far. It’s also affecting a different site done with a 3rd party theme so this is not just limited to Foundation. It’s a general problem affecting all my Rapidweaver sites that suddenly kicked in yesterday. I wonder if @nikf or somebody from Realmac could offer any insight.

On a different note SSL is becoming much more common now so I think developers need to think carefully about their coding to ensure their stacks and themes don’t block SSL from working.

Yes, I can understand that. Not sure what I might have said that suggested it was a Foundation issue? I just wondered aloud whether Foundation theme might have had a provision for this built in (they seem to have thought of just about everything else!)

I think it is a insecure link issue that the browser is taking exception to. Could, and does, happen in non RW sites… loads of questions about this problem on Google for all manner of platforms.

I think the links are the issue not the theme per se. Agree that it would be nice if themes (not just Foundation) had a way to handle this… but I have to ask… how would we handle this situation if we were building raw? We would have to fix it ourselves right?

It does seem like the links are the issue but none of that explains why it was all fine one day with SSL but not the next. The other site uses a theme from Brandon Lee. Any external sites I link to are all https.

There is no way I know of in Foundation or the other theme to change this either. In theory I could edit the links online using something like Yummy FTP but then it would break again the next time I made any changes, so this is something that needs to be handled by the developers as a longterm solution.

*** Not specifically relevant to this thread but I am watching this topic, which happens automatically when you start a thread, however I am not receiving email notifications. This seems to be a bug that was never present on the old forums.

I can’t really offer any insight here. There’s some processing being done on Cloudflare’s part, with Google PageSpeed processing the CSS. As a result: the CSS links are being rewritten…

which would suggest that the issue is on their part. To check: is RapidWeaver set to use the https:// version of your website address in the Site Setup area? That would be the only way in which RW has any control over this… Once it’s on your server there’s no interaction on RW’s part…

Yes the pages are definitely set up to use https:// in the site setup. I’ll get back to CloudFlare.

Apologies if I’m being dumb and missing the obvious, but how are your file links configured in RW? Relative to page? Relative to website address? (think it might be the latter?)… if the CSS file links were relative to page would they not just be referenced locally and bypass the whole http/https pantomime? Like, for example:

<link rel="stylesheet" type="text/css" media="screen" href="/rw_common/themes/boreal/styles.css" />
<link rel="stylesheet" type="text/css" media="screen" href="/rw_common/themes/boreal/custom.css" />

Where the CSS links just point to good old /rw_common/

I guess you are doing something with Cloud flare that maybe needs it to be the way you set it? Just wondering.

Yes my file links are Relative to Page. I had to do this with links to https because it has never worked for me when using Relative to DOCROOT with Joe Workman’s Global Content but you may be on to something.

Just a thought. I believe I have PageSpeed Module installed on my server and I wonder if changes at CloudFlare have suddenly come into conflict.

Regarding links using http, rather than rewriting, I believe you can use mod-rewrite in the .htaccess file. I haven’t tried it but it would be much more convenient if it works.

I’ve just asked the server managers to disable PageSpeed Module on my server to see if that helps. I actually have page rules inside CloudFlare that redirect all http to https so this should all just work.

The really strange part is that I check a page and it looks fine, then 10 minutes later it’s broken and an hour after that it’s fine. To me that points to CloudFlare messing around with their configuration.

EDIT UPDATE: My server manager has just disabled PageSpeed Module on my server and that appears to have fixed the issue on both sites. It looks like CloudFlare made some changes yesterday that caused a conflict so I have written to advise them of this. I tried to make it clear to them from the start that I hadn’t changed anything in the coding.