FontAwesome icons aren't displaying whatsoever for me

[dwvisser]

Whether I try to view the site on Firefox or Edge, Linux or Windows, behind corporate firewall or not, I always see that the various FontAwesome icons on the landing page do not render.

[david-a-wheeler]

Thanks. I just noticed that too. What's weirder is that it works on https://staging.bestpractices.dev/, where we did our testing first. Obviously something is different.

[david-a-wheeler]

Ugh. It worked in the staging system. Thankfully the Firefox developer tools console can tell us a lot immediately:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://bestpractices.coreinfrastructure.org/assets/fontawesome-webfont-aa58f33f239a0fb02f5c7a6c45c043d7a9ac9a093335806694ecd6d4edc0d6a8.ttf. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 302.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://bestpractices.coreinfrastructure.org/assets/fontawesome-webfont-aa58f33f239a0fb02f5c7a6c45c043d7a9ac9a093335806694ecd6d4edc0d6a8.ttf. (Reason: CORS request did not succeed). Status code: (null).

downloadable font: download failed (font-family: "FontAwesome" style:normal weight:400 stretch:100 src index:3): bad URI or cross-site access not allowed source: https://bestpractices.coreinfrastructure.org/assets/fontawesome-webfont-aa58f33f239a0fb02f5c7a6c45c043d7a9ac9a093335806694ecd6d4edc0d6a8.ttf 

I'm mystified why this is a problem though. First, it should be requesting the files from www.bestpractices.dev. Second, because I was worried about transitions, I specifically rigged the CORS values to allow the cross-domain request, so even with this wrong domain it should be working.

So for 2 different reasons this shouldn't happen, but it's happening anyway. This shows that sometimes a belt-and-suspenders approach isn't enough. Maybe next time I should also glue my pants on.

My debugging hat is now on.

[david-a-wheeler]

The HTML head includes a stylesheet reference, as expected:

  <link rel="stylesheet" href="https://www.bestpractices.dev/assets/application-04018e470a1f93d7f829a24ab6e35df34e254cd21f06783355947185e5cd7376.css" media="all" />

The CSS loads font awesome (as expected) from bestpractices.coreinfrastructure.org (as NOT expected):

  License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License)
 */@font-face{font-family:'FontAwesome';src:url(//bestpractices.coreinfrastructure.org/assets/fontawesome-webfont-7bfcab6db99d5cfbf1705ca0536ddc78585432cc5fa41bbd7ad0f009033b2979.eot);src:url(//bestpractices.coreinfrastructure.org/assets/fontawesome-webfont-7bfcab6db99d5cfbf1705ca0536ddc78585432cc5fa41bbd7ad0f009033b2979.eot?#iefix)

I have NO idea why it's loading for there. Even weirder, staging doesn't do this, so there's some unexpected difference.

[david-a-wheeler]

I don't see any obvious problem with the code, at least not so far, and the code is pretty simple.

Here is my current hypothesis: I suspect the problem is that some of the assets are precompiled, and the last time the production site was compiled, its primary domain name was bestpractices.coreinfrastructure.org. I'm going to deploy an update, which will force precompilation with the new domain name www.bestpractices.dev with a restart, and then re-clear the Fastly (CDN) cache. We will soon see if that process solves the problem, and there's no reason it should cause a problem. Hopefully this process will solve the problem; if it doesn't, I'll have to look elsewhere.

[david-a-wheeler]

I was right, and my solution solved it. The code was fine, we just needed to clear and rebuild the various caches.

Thanks for the report. I believe it's fixed, so I'm closing this issue.