I just deployed the site using Mina. All the JS and CSS works, but there are some files in assets/images that are being used by colorbox that are not being served.
Failed to load resource: the server responded with a status of 404 (Not Found) http://pykture.com/assets/controls.png
I have changed this to true
config.serve_static_assets = true
but still no luck. How can I get these image files served?
You may want to use this - https://github.com/knapo/jquery-colorbox-rails - gem.
The problem is that the references to assets (like controls.png) in the CSS are not wrapped in an asset helper. If you need to write your own SCSS file, make sure you wrap references to these images in URL helpers. Like so:
image-url('colorbox/controls.png')
Then the CSS in production will not contains URLs like http://pykture.com/assets/controls.png, and instead will include URLs like http://pykture.com/assets/controls-8e899fb84b99ba6f03cb879824c7895d.png
Related
I have a problem with certain assets on heroku. (local environment is working fine)
The assets are in the pipeline. If I execute in the heroku rails console:
helper.asset_path("typicons.woff")
helper.asset_path("backgrounds/1.jpg")
I get the following response:
/assets/typicons-c2430aad2b6a33948dc064cfaee8ad65ff9e3ca439834f3aaa84abec3d10dea8.woff
/assets/backgrounds/1-c2098ff7e7fbb89b2d18e9cd9089f712f2b837265d1d2e4182c36c23392760c6.jpg
So I assume that the assets are in the heroku asset pipeline. As well by opening the url directly with the digest in it, I receive the file.
However if I try to reference the files in css or javascript like this:
$('.top-content').backstretch("/assets/backgrounds/1.jpg");
The file does not load. As well opening /assets/backgrounds/1.jpg directly does not work. Referencing assets from .rb or .erb files works.
Please can someone tell me, what kind of config I have to change, so the URLs for assets work as well without the digest?
Thank you!
Assuming you are using a fairly standard asset pipeline setup, this passage from the Rails Guides should help:
If you add an erb extension to a JavaScript asset, making it something such as application.js.erb, you can then use the asset_path helper in your JavaScript code:
-- http://guides.rubyonrails.org/asset_pipeline.html (section 2.3.3)
In your example, add the erb extension to your JS file and then change the line to
$('.top-content').backstretch(<%= asset_path("backgrounds/1.jpg") %>);
The problem is that Rails 4 does not support non-digested assets at all.(For whatever reason)
Here is a more thorough explanation on the issue: Non Digested Asset Names in Rails 4
My personal workaround was to add a public asset folder to my app:
public/assets/static/
and upload the assets required there. Since it was only about fonts and background images, which do not change often, it does not seem to be a problem. In the link above there are several other solutions proposed.
For every version of my app, I upload my assets to the cloud CDN, and the images on the website are loaded as something like imagename-somehash.
I have static images that are large, i.e like carousel images, which don't change often or at all. So even when the app changes, they can remain cached by clients who previously visited the website.
How would one do that? Any images I have under app/assets folder gets upload to CDN with the imagename-somehash format, so the image changes with every version of the app.
I'm using rails 4.2. Is this possible?
In rails guides there is an article What is Fingerprinting and Why Should I Care? which gives some insights about that hash on the end of a file and how it works.
Check your environments files. In production you may want config.assets.digest to be true.
You can put these images in public folder and can mention full url in views for these images
OR You can also put it on
vendor/assets/images
but in that case you would have to disabled precompile path
If you want to serve only some assets from your CDN, you can use custom :host option your asset helper, which overwrites value set in config.action_controller.asset_host.
<%= asset_path 'image.png', host: 'mycdnsubdomain.fictional-cdn.com' %>
I'm using Carrierwave to handle file uploads. Files get stored under public/uploads/. Project uses Ember.js templates, and the img tags point to the proper src. (I've verified that the files are present at those paths.) However, the server returns a 404 for each.
It looks like this is a common problem, and the common solution is to:
config.serve_static_assets = true
However, this isn't working. I'm still getting 404s. Any other ideas about how to deal with this?
It should be noted that I'm not using Apache or nginx.
Rails no longer compiles the assets without digests. In order for this to work properly, you need to use a rails helper to include the proper asset name (with the digest), or use a gem like https://github.com/alexspeller/non-stupid-digest-assets as a workaround.
In my rails app I am serving all my assets through a CDN. I'd like to serve only my fonts directly from my app server. font_url/font-url will always include the the cdn url. Is there any convenient way to generate the path to the font (with digest) without the CDN domain or the protocol (http[s]) included?
The only thing I can think of is writing my own method that replicates the functionality of asset_path -- hopefully there is a more elegant way to achieve this.
update -- backgroun
I want to serve fonts from my main domain only to IE users so they don't break when in "high security" mode.
How to serve fonts from different servers for IE users?
IE conditional comments with Sass and Bourbon
Update:
Copy the font files into a separate folder, say "ie-high-security" for example. This is to identify them in step #2.
Serve files in the folder ("ie-high-security" in the example) by configuring the asset_host in "config/application.rb":
ActionController::Base.asset_host = Proc.new { |source|
if source.include?('/ie-high-security/')
""
else
"http://assets.example.com"
end
}
Reference the fonts in the "ie-high-security" folder in a separate stylesheet intended only for IE9.
Serve the IE9 stylesheet with conditional comments as suggested in https://stackoverflow.com/a/25415002/368697:
<!--[if IE 9]>
stylesheet using internally served fonts
<![endif]-->
Old suggestion:
Use font_path instead of font_url. The first method generates an absolute path without the asset host prepended.
If the font is being included from a stylesheet that is served from your CDN, you'll need a full path back to the app server though.
I'm just getting into the Asset Pipeline; I'm using SASS/SCSS, but I'm not understanding why I should be using the Asset Helpers.
For example, if I have some CSS/SCSS without using an Asset Helper:
background-image: url('rails.png');
This will work fine because both my .SCSS file and image are in and accessible through the assets directory.
What's the point of doing this?:
background-image: asset-url("rails.png", image);
I understand it will add "/assets/" to the url, but why should I be using the Asset Helpers if the standard CSS way will work?
I think I'm missing something. Does it have something to do with deploying to production?
Using the helpers gives you access to the finger printed URLs in production. From the Asset Pipeline guide:
In the production environment Rails uses the fingerprinting scheme outlined above. By default it is assumed that assets have been precompiled and will be served as static assets by your web server.
During the precompilation phase an MD5 is generated from the contents of the compiled files, and inserted into the filenames as they are written to disc. These fingerprinted names are used by the Rails helpers in place of the manifest name.
So in production, the paths have an MD5 appended and you have things like this:
/assets/pancakes-af27b6a414e6da00003503148be9b409.png
With the checksums in place, Rails can tell browsers to cache these files forever. Then, if you do a new release that changes one of your assets, the checksum changes and that changes the whole path; the new path makes the browser think it is a whole new file so it will fetch it again. Without the checksums you can easily get old files stuck in browser caches and that sort of thing isn't exactly a happy fun time.