assets:precompile doesn't replace image asset paths in CSS

[moomerman]

This is with Rails3.1rc and beta1 If I have a background url specified in application.css like so:

body { 
  background: #00ff00 url('rails.png') no-repeat fixed center;
}

The new asset pipeline stuff finds that image in the assets folder. However when I rake assets:compile the resulting compiled CSS still references rails.png but the asset is now called rails-9c0a079bdd7701d7e729bd956823d153.png so my production server wouldn't be able to serve that asset from the web server.

I would have expected it to expand it to:

url('/assets/rails-9c0a079bdd7701d7e729bd956823d153.png')

[MSchmidt]

You have to use ERB inside your CSS to fix this. You can do this by appending .erb to your css/scss file:

applications.css.scss.erb

Then you have the asset_path helper available:

body { 
    background: #00ff00 url(<%= asset_path 'rails.png' %>) no-repeat fixed center;
}

[cannikin]

I added asset_path to all images included in my CSS and it didn't make any difference after running rake assets:precompile No hash added to the image includes in public/assets/application.css ... am I missing a step?

[MSchmidt]

Hashes are only applied in production. Running rake assets:precompile in development has no real effect. It will create all the files but they are not used by the development server. You can run rake assets:precompile RAILS_ENV=production to see how the asset pipeline would behave in production, but you should remove the public/assets folder afterwards since it's from no use for your dev env.

[cannikin]

Sure enough, thanks!

[moomerman]

So there is a workaround but this is still a bug? Either CSS assets shouldn't be handled by the asset pipeline at all or the correct thing should happen when you compile the assets.

[josh]

Everything @MSchmidt said is correct.

If you don't want images to be handled by the asset pipeline, just keep them in public/images as you had them before.

[moomerman]

I can understand what you're saying but this fails the principle of least surprise. A new developer comes along and is told about the asset pipeline, you can use it in your css - this is great. However, when you deploy to production it will all break! Either you need to make this very clear in the documentation (ie. don't use it) or don't use the asset pipeline for css assets in development. Just my thoughts.

[xinuc]

I agree with @moomerman, this is really confusing.
Jammit can even embed the images in the css files automatically.

[RogerPodacter]

Agree with @moomerman; maybe it's low priority to fix, but this behavior is definitely worse for the user

[robertfall]

This issue tripped me up when playing with 3.1. I do agree that the default behaviour should be more newbie friendly...

[iGEL]

The problem aren't the hashes, the problem is the different behavior between dev & production. Why don't you apply hashes in development as well? Unless you have hundreds of Megabytes of assets, it'll take fractions of a second to get the MD5 sums.

[tetherit]

+1

[lardawge]

Agree with iGEL, seems like a feature that is meant for production shouldn't need me to be in production environment to use.

The main reason this is a fail is because there are several things that I only use in production/staging which I don't want to setup locally... Memcached being one of them.

rake assets:precompile should produce what will be needed in production.

[lardawge]

@MSchmidt & @josh, I am currently testing this using 3-1-stable branch and it is not working as described. I get assets with no hashes. Not sure what is missing here but I have been chasing my tail trying to make sense of the asset pipeline with nothing more than frustration for the last week. I remember this working in beta1 (will have another look), not sure what happened along the way.

Where is the outline for expected/intended behavior that was used to implement this feature so we can get some idea of how it is suppose to work without sifting through 2 plugins and rails core?

[vincecima]

The pipeline should handle the CSS files correctly by default or the CSS files should be treated as ERB by default.

[contentfree]

So, if I'm following along correctly, using Rails 3.1 asset pipeline set up as it is by default – aka using url(rails.png) in a non-erb CSS file – will result in a broken production environment?

[moomerman]

@contentfree The asset will be served but not how you expect it to. If you're running a web server on the front end then the web server won't serve the asset, it will fall back to the application and get served by the asset pipeline as in development. This is confusing though since you're precompiled your assets so you expect them to be served from the precompiled cache (and by your web server if you have one).

Another issue I just noticed is that it is serving the static asset via the asset pipeline in production even though in production.rb I have:

config.serve_static_assets = false

[lardawge]

@moomerman can you verify that it works as described by @MSchmidt on 3-1-stable? From my end it does not.

[moomerman]

@lardawge I just tried against the latest 3-1-stable and got an error while running RAILS_ENV=production rake assets:precompile

rake aborted!
uninitialized constant Sprockets::Helpers

Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

[lardawge]

Here is a pull request to fix that: #1387

You can try my fork until this gets accepted...

So for me with 3-1-stable,
I get hashed assets (js, css, images) in the public assets directory when running rake assets:precompile.
The css does not reference the hashed images even if I use asset_path as MSchmidt suggested in production.

Expected behavior,
The css should be parsed using the asset_path by default and reference the hashed asset in production without using erb.

@josevalim can you give us a hand sorting this... I am happy to do some work to make the required changes and get it working, just need to know the intended behavior if it differs from what I suggested. Also can we reopen this ticket?

[lardawge]

Ok, sorted out some of the issues that I have been having.

1. Image urls in css/scss files don't get touched unless you use erb. For some reason I thought that scss files were parsed for urls. Having to use erb now completely makes sense to me rather than having to build a parser to go through and find urls which can be written in a variety of formats. Maybe in the future.
2. The reason I was having problems with getting asset_path to work in the scss.erb was because I had removed the line in the rake task that was causing uninitialized constant Sprockets::Helpers (3-1-stable). The helper is what overrides the path allowing sprockets to fingerprint assets. Sprockets::Helpers still doesn't exist in 3-1-stable so I overwrote the rake task locally using the following until something is done about it. I will probably end up keeping it because in my case it works for the workflow (see below).

Rake::Task["assets:precompile"].clear
namespace :assets do
  desc "As if production env"
  task :precompile => :environment do
    # Give assets access to asset_path
    ActionView::Helpers::SprocketsHelper

    assets = Rails.application.config.assets.precompile
    Rails.application.assets.precompile(*assets)
  end
end

I was able to run rake assets:precompile as if I was in production by adding the following to the development.rb and updating the rake task. The only thing rails cares about is config.action_controller.perform_caching being true and it will add the hash.

As an aside, the api will change to the following for minifying js/css in 3.1. This caught me off guard because there was no mention of the change other than looking through the source code. You will also need to add gem 'sass-rails' to Gemfile.

# development.rb
if $precompile_assets
  config.assets.compress = true
  config.assets.js_compressor = :uglifier
  config.action_controller.perform_caching = true
else
  config.action_controller.perform_caching = false
end

#assets.rake
namespace :assets do
  desc "As if production env"
  task :precompile do
    # Set global to compress and fingerprint assets
    $precompile_assets = true

    # Load rails
    Rake::Task['environment'].invoke

    # Give assets access to asset_path for fingerprinting
    ActionView::Helpers::SprocketsHelper

    assets = Rails.application.config.assets.precompile
    Rails.application.assets.precompile(*assets)
  end
end

Lastly, image_tag generate hashed urls if you only use the image name or relative paths.

<%= image_tag 'rails.png' %>
<%= image_tag 'nested_folder/rails.png' %>

Hopefully this is helpful to someone...

[chriseppstein]

fyi: in sass rails I will be adding native sass functions to ease access to asset paths.

background: image-url("foo.png")

will search the asset path for an image named foo.png and lastly it will look in public.

[tobsch]

@chriseppstein will this implementation be included in 3.1?

[jamesarosen]

@chriseppstein is there an issue on sass-rails that I can watch to track this (and possibly help test it out for you)?

[Bodacious]

Guys

The asset pipeline works fine for me in Staging/Production

I think it's great...

It's crippling me in Dev mode though... having to make a request to the pipleine for each image on my app means it now takes about 20-30 seconds for a page to load. Try styling a page with that?

I'm going bald here guys, is there something I've missed?

[Bodacious]

In the meantime:

cp -R app/assets/images public/assets

really helps!

[martinciu]

@Bodacious I had same issue, but problem wasn't in asset pipeline. I use mongoid wchich by default preloads all models in developemnt evnironment. After switching this off each asset load in aboud 100ms.

You can find what is realy slow using rack-perftools_profiler. It helped me a lot.

[Bodacious]

@MartinCui - thanks for the suggestion - I don't use Mongoid but I'll check out rack-perftools_profiler and see it I can find where I'm going wrong

[sandstrom]

Don't know if it's possible, but would be neat if Sprockets could figure out that url("/assets/cat.jpg") (or a similar string in javascript) should be rewritten. I don't know the inner workings of Sprockets, but I'm thinking such a feature shouldn't be too difficult. Support for automatically converting small enough images into base64 would be neat too.

That said, the new pipeline is great and this isn't a major issue. Using ERB or falling back to the previous behavior are both easy.

[andyjeffries]

The problem I'm having is that if I use "application.css.scss.erb" and then within that file want to import an SCSS partial (say _partial) then none of the following work:

@import "partial"
@import "partial.css.scss"
@import "_partial.css.scss"
@import "partial.css.scss.erb"
@import "_partial.css.scss.erb"

I need to be able to use asset paths within any SCSS and having to add multiple layers of parsing to each file (and still have it break) is entirely weird.

Given that ERB tags are invalid SCSS, could we not pass all SCSS files via ERB and then hopefully the @import should work?

[andyjeffries]

Sorry, just realised there's a github user called "import" that will now be strangely pulled in to this thread. I was referring to the SCSS directive, not him.

[Bodacious]

The @import (apologies to user named @import) is a SASS directive, not a sprockets directive.

I think it would be cooler to include variables from other styles using the *= require directive

Difficult to do?

On 28 Jul 2011, at 15:09, andyjeffriesreply@reply.github.com wrote:

Sorry, just realised there's a github user called "import" that will now be strangely pulled in to this thread. I was referring to the SCSS directive, not him.

Reply to this email directly or view it on GitHub:
#1209 (comment)

[Bodacious]

Should start a new thread for this btw

On 28 Jul 2011, at 15:09, andyjeffriesreply@reply.github.com wrote:

Sorry, just realised there's a github user called "import" that will now be strangely pulled in to this thread. I was referring to the SCSS directive, not him.

Reply to this email directly or view it on GitHub:
#1209 (comment)

[matpowel]

Huge +1 on that.

Anyone with any decently DRY'd pattern of SASS can't really use the asset compiling because of this.

[elland]

only one comment to this new assets stuff:
tha fuck is this?

[subelsky]

I just got bit by this issue when I tried to use an asset host. precompiling the asset gives me fingerprinted images which I then sync to my asset host, but anytime I call image-url in my .scss files the resulting URL does not include the fingerprint.

[alovak]

@subelsky please check that you don't have leading '/' in image-url value.

If you use helper in this way: image-url('/logo.png') sprockets will not replace it with digest.
Just use image-url('logo.png').

[subelsky]

Hi @alovak thanks for writing back; I tried that but it didn't work. Maybe because these files are in /vendor/assets/stylesheets?

[alovak]

I also have files in vendor. But I include them with sprockets directive:

*= require my-file

this file is in /vendor/assets/stylesheets

and it contains:

...
background: image-url("input-file/button.png") no-repeat left top;
...

the resulted css contains url("input-file/button-xxxxxxxxxxxxxxxxxxxxx.png")

[subelsky]

It worked! It turned out I had been writing my image-urls as image-url('assets/input-file/button.png') - every time I looked through this I failed to notice the unnecessary assets prefix int he path. Thanks for helping me!

[justin808]

In case anybody googles for this issue, I had this exact problem, and it turned out that the custom build script was failing to set RAILS_ENV=production.

[kulbida]

Still hawing this issue with:
gem 'sass-rails', '~> 5.0'
gem 'rails', '4.2.0'
Setting RAILS_ENV variable did not work.

[nitsujri]

For me, fixed this using image-url(), font-url() properly. Only using url() did not help. This is a huge gotcha. Probably causing lots of people turn config.assets.compile = true

[likethesky]

Since I was using sass-rails like @kulbida I finally ended up adding the file extension .scss to the offending .css file(s) so they all end in .css.scss, then replaced all instances of url('blah.png') with url(asset-path('blah.png')) (in my case all the blah.pngs were in a /vendored folder).