I had a rare error in my Rails application. A CSS file was referring to non existing image files. And missing PNG file was somehow mapped to a controller action. Fortunately the action wasn't changing DB. This seems to be not OK that missing PNG can trigger controller action.
So should I disable mod_rails for static asset directories? However I've never heard this is required for Rails apps.
It is definitely a good idea, since if you allow any kind of image upload the target destination is usually the asset directory. Normally the user can quite easily upload a php or ruby file instead, so disabling all mod_evil_script for these directories is a good idea in general.
You should be serving static assets directly via Apache anyway, because it's faster. Let Rails do what it's designed to do which is handle dynamic requests.
Related
I am using Ruby on Rails 4.1.1 and I want to add a linked image - my app's logo - in email messages but I had a doubt since my previous question.
By using files located in the public directory it seems that to link to an image in your Asset Pipeline you can use
link_to(LINK_TEXT_OR_IMAGE_TAG_HELPER, image_path(IMAGE_NAME))
but for those located in the app/assets it seems do not work the same, at least in rendered email messages in production mode. All assets that are compiled in Production have a fingerprint ID... is the fingerprint causing the load of static assets to do not render images in email messages?
I doubt since I would like to access images from both browser and email. I tried to solve the issue by moving the image from app/assets/images/logo.png to public/images/logo.png and by changing statements in my application.css.scss file from image-url("logo.png") to url("/images/logos.png"). However I do not know if I am following "the Rails way" or a "best practice". Do I? Should I add to the public directory all assets that I plan to use outside my application and in the app/assets directory all assets that I plan to use internally to my application?
For emails, it almostisn't any different compared to standard Rails views.
You can link to an image in your mailer using the image_tag helper you'd normally use in regular views as well:
<%= image_tag('some_image.jpg') %>
You also need to tell Action Mailer where it can find the assets, because it will use absolute URLs to refer to your images:
config.action_mailer.asset_host = 'http://www.example.com/'
In Rails, my assets have fingerprints added to them, e.g.
mysite.com/assets/something/base-216123123asdfasd20a.css
Unfortunately, if I want to link to this from another site (like a blog) I can't rely on the fingerprint.
Is there a configuration setting I can set so that I can access files without knowing their fingerprint? (While still keeping the fingerprint for normal Rails usage; this would just be used for special cases)
I don't want to do one-off things like creating a route for a specific asset, because I'll need it for many assets.
The simplest way is to put the files directly into the public folder:
- public
-- your_file.js
This would then have to be called by referencing your URL directly = http://domain.com/your_file.js
This is only really advisable for files which you want to remain static (such as widget JS or similar).
Non Digest Assets
Alternatively, you may wish to try a gem I've never used before called non-stupid-digest-assets - a gem which allows you to determine which files are "fingerprinted" and which are not.
I've never used this gem, so cannot comment on its effectiveness, but it looks like it will give you the ability to save certain assets without their fingerprinted name. This means that you'll still be able to call them using the various asset path helpers which are available in Rails, as well as giving others a direct reference for the file:
#config/initializers/non_digest_assets.rb
NonStupidDigestAssets.whitelist = ["your_file.js"]
You'll then be able to call asset_path("your_file.js")
I have a rails 4 app on heroku, and I want to embed some of my image assets in a static website that I'm making.
The problem is that rails adds a digest to the asset path.
<img src="http://myapp.herokuapp.com/assets/tools/my-image-43b65377b7644fae3f34d288f3235b80.png"/>
This makes it very hard for me to hotlink to my assets, because their digests may change over time.
Is there anyway to embed my images without having to insert this digest? I know that rails 3.1 allowed you to do so.
In rails-4, non digested assets are not generated anymore.
If you want to hotlink assets, place a copy of image you'll use in public/. To avoid duplication, you can use a symlink pointing to the proper location in app/assets/images/.
It's worth noting that rails does a very good job at caching images in browser, and it is usually recommended to add far future timeout for assets caching in front server. So you should probably avoid to hotlink images that are prone to change often.
I have put all my images for my admin theme in the assets folder within a folder called admin. Then I link to it like normal ie.
# Ruby
image_tag "admin/file.jpg" .....
#CSS
.logo{ background:url('/assets/images/admin/logo.png');
FYI. Just for testing I am not using the asset_path tag just yet as I have not compiled my assets.
Ok all good so far until I decided to update an image. I replaced some colors but on reload the new styled image is not showing. If I view the image directly in the browser its still showing the old image. Going one step further I destroyed the admin images folder. But it has broken nothing all the images are still being displayed. And yes I have cleared my cache and have tried on multiple browsers.
Is there some sort of image caching going on? This is just local development using pow to serve the pages.
Even destroying the whole images folder the images are still being served.
Am I missing something?
In 3.1 you just get rid of the 'images' part of the path. So an image that lives in /assets/images/example.png will actually be accessible in a get request at this url - /assets/example.png
Because the assets/images folder gets generated along with a new 3.1 app, this is the convention that they probably want you to follow. I think that's where image_tag will look for it, but I haven't tested that yet.
Also, during the RailsConf keynote, I remember D2h saying the the public folder should not have much in it anymore, mostly just error pages and a favicon.
You'll want to change the extension of your css file from .css.scss to .css.scss.erb and do:
background-image:url(<%=asset_path "admin/logo.png"%>);
You may need to do a "hard refresh" to see changes. CMD+SHIFT+R on OSX browsers.
In production, make sure
rm -rf public/assets
bundle exec rake assets:precompile RAILS_ENV=production
happens upon deployment.
For what it's worth, when I did this I found that no folder should be include in the path in the css file. For instance if I have app/assets/images/example.png, and I put this in my css file...
div.example { background: url('example.png'); }
... then somehow it magically works. I figured this out by running the rake assets:precompile task, which just sucks everything out of all your load paths and dumps it in a junk drawer folder: public/assets. That's ironic, IMO...
In any case this means you don't need to put any folder paths, everything in your assets folders will all end up living in one huge directory. How this system resolves file name conflicts is unclear, you may need to be careful about that.
Kind of frustrating there aren't better docs out there for this big of a change.
In rails 4 you can now use a css and sass helper image-url:
div.logo {background-image: image-url("logo.png");}
If your background images aren't showing up consider looking at how you're referencing them in your stylesheets.
when referencing images in CSS or in an IMG tag, use image-name.jpg
while the image is really located under ./assets/images/image-name.jpg
http://railscasts.com/episodes/279-understanding-the-asset-pipeline
This railscast (Rails Tutorial video on asset pipeline) helps a lot to explain the paths in assets pipeline as well. I found it pretty useful, and actually watched it a few times.
The solution I chose is #Lee McAlilly's above, but this railscast helped me to understand why it works. Hope it helps!
The asset pipeline in rails offers a method for this exact thing.
You simply add image_path('image filename') to your css or scss file and rails takes care of everything. For example:
.logo{ background:url(image_path('admin/logo.png'));
(note that it works just like in a .erb view, and you don't use "/assets" or "/assets/images" in the path)
Rails also offers other helper methods, and there's another answer here: How do I use reference images in Sass when using Rails 3.1?
With the introduction of the new directory structure in 3.1 (i.e. app/assets/), should app images (logo, banner, icons, main bg, etc) still be stored in public/images or should they go into app/assets/images?
Someone mentioned:
I would be shocked if anything in
app/assets can be served publicly -
that wouldn't make sense from either a
security viewpoint or from honoring
the convention of the public
directory. Since you need these flash
files to be publicly accessible, you
should store them in public.
Valid point. Which brings me to the question:
Based on above understanding. What about the app images? If images such as logo, banner, main background, icons are considered public, why is there an images directory in app/assets?
Or should we still put these types of images in public/images. If so, what is the images dir in app/assets used for?
Note: I haven't looked at Rails 3.1 yet...
As far as I understood DHH's keynote, app/assets was introduced so you could structure your application in a better way. But there's nothing wrong with storing images in public/images. Thanks to Michiel for pointing out that public/images will no longer be with us in Rails 3.1!
The public folder will the replaced by the assets folder. That's the folder that your web server will point to. Files from app/assets, lib/assets or other places will be copied (images) or compiled (css, js) to assets.
That means that assets is now considered a build directory, and you shouldn't store anything there - you might even decline to put it under version control, and just have the server generate or copy the images and css and scripts when you deploy.
See also: http://blog.nodeta.com/2011/06/14/rails-3-1-asset-pipeline-in-the-real-world/