I once spent roughly 3.5 hours trying to figure out why my custom google font and foundation-icons-3 would not render in production on Heroku, and you know what? I learned a lot! Turns out there’s this thing called the asset pipeline, not the kind you’re offered at a rave or the world class Hawaiian reef break, and it determines whether your Rails app is worthy of style when you push it to your production server.
Turns out, the asset pipeline is one of the simplest and least understood rails features for developers. Instead of me just telling you how to make your custom web-font and font-icons work on Heroku, which I will in part-II, I rather compress the brain-drain I just experienced into something of value. Keep in mind this is just a high to mid-level overview, we’ll get into more tricky aspects in part-II.
What is the asset-pipeline?
Awesome, but how does your application actually find these Manifest files? Magic! Along with link_tags inside your application layout: app/views/layouts/application.html.erb. Consider this file a universal default master file for all the views. It’s sorta like a Manifest file in the sense that it pulls all of the HTML from each one of your view files into itself by way of <%= yield %> (if you’re using erb as your templating language). We link stylesheets and scripts in the <head> of this file like this: <%= stylesheet_link_tag “application” %>. This points to the Manifest CSS file.
Sometimes just the order in which you require files might be incorrect, which causes certain files to override others. This is quite possibly the most important and overlooked section in Rails docs:
In conclusion, you’re application layout file has a link pointing to your Manifest files. These Manifests should already be requiring all of your assets in the order in which you intend. Roughly 90% of problems I’ve seen people have with the asset pipeline come from improperly requiring files or frameworks from within their Manifests.