{"id":2579,"date":"2017-12-28T14:50:38","date_gmt":"2017-12-28T20:50:38","guid":{"rendered":"http:\/\/www.mooreds.com\/wordpress\/?p=2579"},"modified":"2017-12-28T14:50:38","modified_gmt":"2017-12-28T20:50:38","slug":"heroku-pipelines-and-asset_paths-and-font-downloads-being-cancelled","status":"publish","type":"post","link":"https:\/\/www.mooreds.com\/wordpress\/archives\/2579","title":{"rendered":"Heroku pipelines and asset_paths and font downloads being cancelled"},"content":{"rendered":"

My font downloads were being cancelled when I was using a CDN in front of a rails app hosted on Heroku.\u00a0 I was testing out using heroku pipelines<\/a>, which lets you promote a slug built in one environment directly to another.\u00a0 Rails was also serving the CSS\/JS\/font files, but was behind a CDN and config.action_controller.asset_host<\/code><\/a> was set to the cloudfront URL, so most clients were pulling from the CDN.<\/p>\n

The issue I ran into was that in order to get my fonts to show up correctly when I was compiling my slugs on production deploy (before I moved to heroku pipelines), I needed to use erb and the asset_path<\/code> tag. So my font css file looked like this:<\/p>\n

@font-face{\r\n  font-family:'FontAwesome';\r\n  src:url(<%= asset_path('fontawesome-webfont.eot?v=3.0.1') %>);\r\n  src:url(<%= asset_path('fontawesome-webfont.eot?#iefix&v=3.0.1') %>) format('embedded-opentype'),\r\n  url(<%= asset_path('fontawesome-webfont.woff?v=3.0.1') %>) format('woff'),\r\n  url(<%= asset_path('fontawesome-webfont.ttf?v=3.0.1') %>) format('truetype');\r\n  font-weight:normal;\r\n  font-style:normal }\r\n<\/pre>\n
However, this caused the asset_path in this CSS file to be set to the full CDN hostname plus the asset path, something like https:\/\/d123.cloudfront.net\/assets\/fontawesome-webfont.eot<\/code> (when the slug was compiled on staging).  When the slug was compiled on production, the value was set to https:\/\/d256.cloudfront.net\/assets\/fontawesome-webfont.eot<\/code>.  When I was using heroku pipelines, the slug was unchanged between staging and production, just as advertised.  However, this meant that the CSS was being served off of the production CDN host (d256<\/code>) and the fonts in that CSS file were referencing the staging CDN host (d123<\/code>).  Browsers didn’t like that.  This question indicates that this is due to cross resource permissions not being set correctly<\/a>.  <\/p>\n
What were my options?<\/p>\n
I could return to deploying slugs by compiling them on staging and production.  However, I like the concept of pipelines and the immutable artifact.<\/p>\n
I could try to find some way to post process the slug and change that link in the font CSS.  But that didn’t seem possible, based on documentation, and kinda defeats the purpose.  I did discover the heroku release phase<\/a>.<\/p>\n
I tried some of the other solutions outlined on this question<\/a> to tweak how the asset pipeline compiled the font references, but nothing else worked.<\/p>\n
I could have tried to set the permissions correctly for the font download.  One worry there would be having the production environment depend on the staging CDN.  Never a good idea to mix environments.<\/p>\n
I also could have tried relative paths to the font files in the CSS file.  I didn’t do this because I thought of my final solution first.  <\/p>\n
The solution I finally went what was using a CDN that hosted the font files of the correct version and used those.  I also chose this solution because we won’t be using these fonts (which we primarily use for icons) for long–in the near future we’ll be removing the icons from the application.<\/p>\n","protected":false},"excerpt":{"rendered":"
My font downloads were being cancelled when I was using a CDN in front of a rails app hosted on Heroku.\u00a0 I was testing out using heroku pipelines, which lets […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[77],"tags":[],"class_list":["post-2579","post","type-post","status-publish","format-standard","hentry","category-rails"],"_links":{"self":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/2579","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/comments?post=2579"}],"version-history":[{"count":2,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/2579\/revisions"}],"predecessor-version":[{"id":2581,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/2579\/revisions\/2581"}],"wp:attachment":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/media?parent=2579"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/categories?post=2579"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/tags?post=2579"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}