Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


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

moomerman opened this Issue · 41 comments

24 participants

Richard Taylor Matthias Schmidt Rob Cameron Joshua Peek Nugroho Herucahyono Tom Lehman Robert Fall Johannes Barre xanview Larry Sprock Vince Cima Dave Myron Chris Eppstein Tobias Schlottke James Alexander Rosen Gavin Morrice Marcin Ciunelis sandstrom Andy Jeffries Matt Powell Igor Ranieri Elland Mike Subelsky Pavel Gabriel Justin Gordon
Richard Taylor

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:

Matthias Schmidt

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


Then you have the asset_path helper available:

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

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?

Matthias Schmidt

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.

Rob Cameron

Sure enough, thanks!

Richard Taylor

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.

Joshua Peek

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.

Joshua Peek josh closed this
Richard Taylor

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.

Nugroho Herucahyono

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

Tom Lehman

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

Robert Fall

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

Johannes Barre

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.

Larry Sprock

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.

Larry Sprock

@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?

Vince Cima

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

Dave Myron

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?

Richard Taylor

@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
Larry Sprock

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

Richard Taylor

@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)
Larry Sprock

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?

Larry Sprock

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).

namespace :assets do
  desc "As if production env"
  task :precompile => :environment do
    # Give assets access to asset_path

    assets = Rails.application.config.assets.precompile

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
  config.action_controller.perform_caching = false
namespace :assets do
  desc "As if production env"
  task :precompile do
    # Set global to compress and fingerprint assets
    $precompile_assets = true

    # Load rails

    # Give assets access to asset_path for fingerprinting

    assets = Rails.application.config.assets.precompile

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...

Chris Eppstein

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.

Tobias Schlottke

@chriseppstein will this implementation be included in 3.1?

James Alexander Rosen

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

Gavin Morrice


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?

Gavin Morrice

In the meantime:

cp -R app/assets/images public/assets

really helps!

Marcin Ciunelis

@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.

Gavin Morrice

@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


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.

Andy Jeffries

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?

Andy Jeffries

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.

Gavin Morrice
Gavin Morrice
Matt Powell

Huge +1 on that.

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

Igor Ranieri Elland

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

Mike 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.

Pavel Gabriel

@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').

Mike Subelsky

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

Pavel Gabriel

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")

Mike 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!

Zeljko Milojkovic zmilojko referenced this issue from a commit in zmilojko/zwr-gem
Zeljko Milojkovic zmilojko stylesheet is now erb
Trying to get that doomed image fingerprinted in the css file. Following
tips from rails/rails#1209.

Signed-off-by: Zeljko <>
Justin Gordon

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.