Because a jQuery plugin I use in my application has direct references to images, I'm trying to turn off asset fingerprinting.
So I set config.assets.digest = false in my production.rb, but now none of my image references work at all. /assets/foo.png just returns a blank response.
I really don't want to alter the jQuery plugin's code and add erb image helpers, but I'm not sure what else to do. And frankly, the asset fingerprinting for images seems to be much more trouble than it's worth.
Does anybody have any insight?
Thanks!
Someone made a gem for this purpose:
https://github.com/spohlenz/digestion
The asset pipeline is a great new component of Rails 3.1. However it
has a feature known as fingerprinting that makes it impossible to
properly incorporate many popular JavaScript libraries (including
TinyMCE, CKEditor and FancyZoom to name just a few) into the asset
pipeline.
This gem patches the asset pipeline to allow these libraries to be
used, by disabling the fingerprinting functionality for specific files
or paths.
If you are using a large plugin, like ckeditor, then your only real option is to move that plugin into the public directory.
For smaller plugins you can move their images into the correct asset path. For example if your plugin references images/icon.jpg under the plugin folder this would need to be moved to something like app/assets/images/plugin_name/icon.png and then referenced in the plugin with <%= asset_tag('plugin_name/icon.png') %>.
The pipeline IS worth it. Not using digests in production pretty much negates the point of using it at all, which is to set far-future headers so that the asset gets cached somewhere.
If you are set on removing digests then you must precompile the assets (so that Sprockets does not serve them with far-future headers), and make sure no headers are set on the server.
Related
I'v seen some larger emberjs implementations like discourse: https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse
Can someone explain to me how this gets integration into rails?
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
You need to read about Asset Pipeline.
The directory you linked to above is included by the various require lines in app/assets/javascripts/main_include.js, which is itself included by app/assets/javascripts/application.js.erb.
The gem doing the heavy lifting (the one responsible for interpreting the require lines) is Sprockets.
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
Between the asset pipeline docs and sprockets' docs, your very general question should be more than answered. In a nutshell, yes, the files are minified and merged, and yes there is a whole lot more to it.
In addition to reading about the Asset Pipeline and Sprockets (which handle JS minification, etc), also take a look at the ember-rails gem: https://github.com/emberjs/ember-rails
ember-rails allows you to include Ember.JS into your Rails 3.1+ application. The gem will also pre-compile your handlebars templates when building your asset pipeline. It includes development and production copies of Ember.
What I want is really simple - I want all assets except a particular css file (that references image assets and thus needs to go through the asset pipeline) to be precompiled. How do I exclude that css file from being precompiled?
There are a couple possible answers depending on what you want. I'm not quite sure what you're asking.
If it's in app/assets, you really need anything in there to go through the asset pipeline to be available. In production, you need to precompile all your assets in that are part of the asset pipeline -- and need to re-precompile in production mode whenever they change.
If the asset name doesn't have a scss or sass suffix, it won't go through the scss/sass compiler, although it'll still go through the asset pipeline for fingerprinting in filename, gzipping, etc.
If you really don't want an asset to go through the asset pipeline at all, then you can't really put it in app/assets. You have to put it in public instead. Then it gets confusing how to generate a URL to it, the best way is to use public_path + "/subdir/foo.css".
But I'm not sure that's what you're asking. If you have an asset file that references image paths, normally you do need that to through the asset pipeline, absolutely! Because it's the asset pipeline that will fill out the URLs properly for those image assets. You'll want to use the Rails asset_path helper in the asset file to generate the URL to an image. You can put an .erb on the end of the file, and then use ERB codes <%= asset_path('my_asset.css') %> in it it. Or if it's sass,asset_path` might be built into rails sass already, I forget.
I don't fully understand what problem you are having exactly, but I think what you are asking for may not actually be what you need. Have you checked out the Rails Asset Pipeline guide? It's pretty decent. http://guides.rubyonrails.org/asset_pipeline.html
It sounds like you actually want a file precompiled separately from the other files?
If so you just need to add it to the Rails.application.config.assets.precompile array. Look in config/initializers/assets.rb for a commented line as an example.
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.
I've used jammit to do my asset packaging so far, but my next application will be in Rails 3.1
Should/Can I still use Jammit? Or should I work with the built-in asset pipeline?
You can still use Jammit, but the built in asset pipeline is The Rails Way™.
I'd recommend you try out the asset pipeline/Sprockets - if you don't like it, it's as simple as moving the javascript and css files back to the public directory and setting up Jammit the old way.
I found that setting up the asset pipeline the first time around for browser specific css was a little non-intuitive, but, that was just me being unfamiliar with the whole process. Sprockets works well and allows you to use ERB/HAML with your coffee script or sass (if you want.)
I am wondering if it is just my lack of understanding. I have a action mailer that using a bunch of asset via the image_tag and config.action_mailer.asset_host in the config. As I am using the assets pipline for my javascripts (with the necessary config) -- and not images and css. ActionMailer views complains that I do not have them pre-compile, which is correct as I don't want to, for various reason. One of which my designer just don't want to embed tags in the css as they do not work with his adobe tools.
So is there a way to to switch off CSS and image processing form sprockets?
Thanks
Charlie
Even if you don't want precompiled assets on your mailing machine, could you transfer public/assets/manifest.yml to it? Otherwise the view helpers won't know where your image path will end up.