I’m working on revising my website. Have not published new site yet. Using RW 7.0.4 and Stacks 3. When I preview in Firefox or Chrome, my header fonts get replaced. Looks fine in Safari and RW preview. Bugs to be fixed? I’m using Futura for everything, which I use now in my current website. The headers are being replaced by a slab-serif font.
I am not sure why it happens but I have seen similar results. In my case I am using Font Pro with web fonts served on the server but I don’t think that is the cause.
When I check using MAMP I also see the incorrect font in those browsers but it appears to be using the correctly designated fallback font, however when previewing like this with RW7 it’s completely different.
My guess is that these browsers are somehow blocking access to these fonts on the localhost but RW7 is then serving unexpected fonts. As you say it looks fine in Safari.
I have to assume Realmac are aware of this and aiming to fix it.
1 Like
If you are using web fonts from your server then this will be a CORS (cross origin resource sharing) issue. You will see an error indicating this if you look in the browser console. This is nothing to do with RapidWeaver but is solely the security measures implemented between browsers and servers.
The remedy is easy. You just need to add an .htaccess file to the directory where your fonts are stored on the server to allow other domains to access them. To allow access from all domains you would just add place the following line in the htaccess file.
Header set Access-Control-Allow-Origin "*"
If you have lot of different fonts in sub-directories within a Fonts directory, you only need to add this to the main Fonts directory on your server and anything within will get the rule applied.
Also remember if you are initially creating the .htaccess file on your mac leave off the dot at the beginning or else it will become invisible. Just call it htaccess and then rename it once on the server (using your ftp app) by adding the leading dot.
All the above assumes that your server is running Apache.
If you are worried that others may access your fonts then simply remove the htaccess file once you have finished testing and your site goes live at which point it will be on the same domain as the fonts and so there will be no CORS issues.
6 Likes
I’ve just tried that on a test domain and confirmed it works when tested with the RW localhost in Chrome and Firefox.
There’s no error in the browser console, and my fonts are Google embedded fonts. Does the above recommendation still apply? I’m not a programmer, so not sure what it all means.
If they are Google fonts then no, you don’t need to worry about the above. It works in all browsers OK for me. How are you loading the Google Fonts? via a stack or theme?
1 Like
My theme, which is a modified Volcano theme by Will Woodgate. Is it possible there is a glitch in RW 7 that needs to be fixed and it’s just in the preview? I checked for extensions and plug-ins and there doesn’t seem to be anything that should interfere.
All I can say is that it works for me just fine in RW7 and all browsers, sorry thats not much help to you.
Sorry for the hideous font but at least you can see it is working in Safari, Chrome and Firefox…
1 Like
LOL hideous. Yeah, not sure what’s going on. Hoping it’s just a bug in preview on the other browsers. Once I republish, maybe I’ll see a difference. No problem with Safari and RW preview.
I just realized that Firefox is only replacing my headers, but Chrome is replacing all my text.
So it turns out there is an issue with Suitcase Fusion 6 and fonts. I uninstalled it and using Font book and now my fonts are showing up fine. grrrr why can’t everyone just play well together?
That is a wonderful reply and now both RW and Safari and Firefox are working for me. Problem is Chrome is like a donkey refusing to obey.
I also tried to add this command I read elsewhere
set Access-Control-Allow-Methods “GET, PUT, POST”
to no avail.
Apparently Chrome is a lot more strict with these issues
@Zen_learner Chrome is strict on CORS yes, but if you have the Access-Control-Allow-Origin in the .htaccess file AND it is in the correct location then it will work. The other instruction you mention will not help with font serving.
If Chrome is not displaying fonts (you will have a CORS error in the browser console) then it is most likely that the .htaccess with the code is not in the root of the sub domain from where the fonts are being served. If your fonts are in a directory in your main www subdomain then the .htaccess should be in the root of the directory where your site resides (usually public_html). If however the fonts are in a subdomain of the same server (for example http://fonts.mydomain.com/ or a directory therein, then the .htaccess file with the rule should go in that subdomain root (i.e. the directory on the server mapped to the subdomain).
If everything is in the right place then Chrome will render the fonts fine.