Eiche fam

I was trying to get the Font Awesome project to build. I wasn’t having a whole lot of luck (read: none), so I updated the bundled version in my WordPress theme (which desperately, desperately needs a better name than “Cover,” but that’s a post for a different day).

---

Fun fact: when I started building my theme — long before I started experimenting with preprocessors like Sass or Less — I was just loading the Font Awesome stylesheet separately. Now, though, I’ve bundled the Sass version into my compiled stylesheet. It’s one less resource to load. :)

---

So I had downloaded the latest version of Font Awesome, and in my efforts to get the project itself to build, I ran this in my command line:

$ gem update

This updated all the Ruby gems I have installed, which included Sass. So I went from version 3.3.8 to 3.4.5. Now, there is some code in my WordPress theme that depends on a feature available in 3.3 — @each multiple assignment — but I really have had no need of an update since.

I thought nothing of it, and deployed my latest stylesheet and fonts out to my website. I clicked the hamburger icon to make sure the icons still worked. I expected no surprises, but what I saw instead was this:

Upon inspecting the font elements, I discovered this:

.overlay .social-navigation .menu a[href*='github']:before {
content: "";
}

Prior to updating Sass to version 3.4.5, this was the output:

.overlay .social-navigation .menu a[href*='github']:before {
content: "\f09b";
}

So it would seem that it was an encoding issue. A quick Google search revealed this issue in the Sass project on Github, where other people seemed to have the same problem.

The problem was, I thought the encoding difference was throwing off the font. But as this gist in SassMeister proves, the conversion from ASCII to UTF-8 was not causing a broken font.

So I did a little more digging.

Then I noticed that Font Awesome’s _variables.scss include sets the directory path to the fonts:

$fa-font-path: "../fonts" !default;

Do you see what that’s doing? It’s telling the stylesheet (which, for me, is located at the theme’s root) to go up a level in order to search for the /fonts directory. At that location, it would never find it. So I changed the path to this:

$fa-font-path: "fonts" !default;

Now it’s telling the stylesheet to look for a /fonts directory at the same level as the stylesheet itself. And voila, the font works again.