1
votes

I have a rails 4.1 app running on Heroku and I'm seeing a static assets problem. Whenever my app requests any non-svg version of font assets (provided by the font-awesome-rails gem), they are not being served. All other assets seem to be served ok.

> curl http://myapp.herokuapp.com/assets/fontawesome-webfont-701cf412b1cf188f7e15450446d7cd04.ttf 
## gives 404 response even though the file exists in public/assets on heroku

> curl http://myapp.herokuapp.com/assets/fontawesome-webfont-4835d3d33b92d5c7c8c58149959d075d.svg 
## gives 200 response and serves the file

It appears that all these assets have been precompiled successfully, and stored in public/assets (below is from heroku bash).

$ ~/public/assets $ ls -l fontawesome-webfont-*

-rwx------ 1 u31786 31786 38205 2014-05-16 19:57 fontawesome-webfont-0c7d84c1c574b8bae138a7014e781a1c.eot
-rwx------ 1 u31786 31786 80652 2014-05-16 19:57 fontawesome-webfont-103111d81ddabc2cf4abea9d8a922fb8.ttf
-rwx------ 1 u31786 31786 202148 2014-05-16 19:57 fontawesome-webfont-1bc7b8f24d224d2cce2fdff63d829fb8.svg
-rwx------ 1 u31786 31786 253487 2014-07-04 02:17 fontawesome-webfont-434a869d64e7a46581d538486a8af044.svg
-rwx------ 1 u31786 31786 202148 2014-05-16 19:57 fontawesome-webfont-4835d3d33b92d5c7c8c58149959d075d.svg
-rwx------ 1 u31786 31786 44432 2014-05-16 19:57 fontawesome-webfont-4daf533148b5cd2067fa92a25d911a2b.woff
-rwx------ 1 u31786 31786 44432 2014-05-16 19:57 fontawesome-webfont-641588c6e43238bf5012415aa7d8f6c9.woff
-rwx------ 1 u31786 31786 141564 2014-07-04 02:17 fontawesome-webfont-701cf412b1cf188f7e15450446d7cd04.ttf
-rwx------ 1 u31786 31786 83760 2014-07-04 02:17 fontawesome-webfont-8613891d251955c3898dc19ee822a763.woff
-rwx------ 1 u31786 31786 72449 2014-07-04 02:17 fontawesome-webfont-97abc2bd68ee5cc83cf9f5386cfc7912.eot
-rwx------ 1 u31786 31786 38205 2014-05-16 19:57 fontawesome-webfont-b921a0d9014189177e286b16478a6680.eot
-rwx------ 1 u31786 31786 80652 2014-05-16 19:57 fontawesome-webfont-e21e874c038a38923c7e064e8606b135.ttf

It seems like I shouldn't need to add the font file types to config.assets.precompile as suggested here (I tried, it did not help). The asset appears to be precompiled successfully since it gets placed into public/assets, but somehow not served by Rails.

How could it be possible for an asset to exist in public/assets with the right permissions, but not be available from Rails on Heroku over http? Are there any other Rails configuration settings that would affect this?

Thanks.

3

3 Answers

1
votes

It turned out that my app had a version of the rack-zippy Middleware gem which causes those filetypes to not be served. (same as this). Upgrading the gem solved the problem.

0
votes

Just add fonts to assets compilation

config/production.rb

Rails.application.configure do
  . . .
  config.assets.precompile += %w( 
    *.svg *.eot *.woff *.ttf *.png *.jpg *.jpeg *.gif
  )
  . . .
end
0
votes

After trying multiple solutions I've been able to solve this issue using the asset helper as recommended by rails guide in the font-awesome.css:

@font-face {
  font-family: 'FontAwesome';
  src: url('<%= asset_path("fontawesome-webfont.eot")%>?v=4.2.0');
  src: url('<%= asset_path("fontawesome-webfont.eot")%>?#iefix&v=4.2.0') format('embedded-opentype'),
       url('<%= asset_path("fontawesome-webfont.woff")%>?v=4.2.0') format('woff'),
       url('<%= asset_path("fontawesome-webfont.ttf")%>?v=4.2.0') format('truetype'),
       url('<%= asset_path("fontawesome-webfont.svg")%>?v=4.2.0#fontawesomeregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

Remember to rename the file to include .ERB extension: font-awesome.css.erb

Rails Guides: The Asset Pipeline

2.3.1 CSS and ERB

The asset pipeline automatically evaluates ERB. This means if you add an erb extension to a CSS asset (for example, application.css.erb), then helpers like asset_path are available in your CSS rules:

.class { background-image: url(<%= asset_path 'image.png' %>) } This writes the path to the particular asset being referenced. In this example, it would make sense to have an image in one of the asset load paths, such as app/assets/images/image.png, which would be referenced here. If this image is already available in public/assets as a fingerprinted file, then that path is referenced.

If you want to use a data URI - a method of embedding the image data directly into the CSS file - you can use the asset_data_uri helper.

logo { background: url(<%= asset_data_uri 'logo.png' %>) } This inserts a correctly-formatted data URI into the CSS source.

Note that the closing tag cannot be of the style -%>.