Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
moomerman opened this Issue · 43 comments
@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
Collaborator

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.

@josh josh closed this
@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.

@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
@Bodacious
@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!

@zmilojko zmilojko referenced this issue from a commit in zmilojko/zwr-gem
@zmilojko 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 <zeljko@zwr.fi>
f2869ae
@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

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.