rewriting relative image paths

[tobyhede]

My css has some relative image paths which appear to be getting rewritten by jammit.

so:

../images/error-bg.png

becomes:

../explicit/file_system/path/to/images/error-bg.png

Is there a way to prevent this or turn it off?

[dblock]

Same problem. Anyone has any suggestions?

[dblock]

I added an option called rewrite_relative_paths on my fork (https://github.com/dblock/jammit) - it still needs work but it will fix your immediate problem.

[jashkenas]

Why would you want to disable the rewriting of relative image paths? How could that work in both development and production, considering that the path to the CSS file is going to change?

[kylefox]

Been trying to figure out how to accomplish this as well.

@jashkenas: In my case, the compressed CSS file sits alongside the original CSS file (which has images located in ../img).

[jashkenas]

@kylefox: shouldn't the paths remain correct, then? Jammit should be writing your paths to be relative to Rails' public root.

[yn]

@jashkenas: rewriting of relative paths doesn't work if the asset_path (config.action_controller.asset_path) is determined at runtime, as is described in http://code.dblock.org/rails-s3-cloudfront-jammit-heroku-100

[napcs]

Please, an option to turn off the rewriting of relative URLs would be really really helpful when not using Rails. I am using Jammit standalone on several projects and I always have to hack around this. I actually use it with Guard and Sass so I have Jammit picking up the files in a temp folder after Sass converts them, and that makes the paths worse.

Please let me turn this off.

[kylefox]

@napcs: I was also using Jammit in Sinatra projects, which is why I posted my original +1 above.

To anyone trying to uses Jammit in a non-Rails app, I would highly suggest moving to Sprockets, as Sprockets is a more general-purpose tool. If you want more granular control over the process, you could also try our gem Hulk

I think the authors of Jammit are fairly committed to this being a Rails-only project (which is fine), so I suspect anyone asking for support in non-Rails apps is barking up the wrong tree by posting here.

[jashkenas]

Use cases outside of Rails are all well and good, but any decent asset packaging solution is going to have to be usable both at a building-packages level, as well as being able to load all of your assets individually in development, and merged in production.

Patches that makes that easier outside of Rails are always welcome, for example this one:

https://github.com/documentcloud/jammit/pull/203/files

Which makes it possible to set the "public root" on the command line, in this case for a Python-based project.

[dblock]

Pull #159 is still open that accomplishes this (or some part of this). We've had it in production for a while.

[napcs]

Pull #159 seems like a great start. If this isn't pulled in, I am thinking about investigating an alternative route, which would let me specify at least a relative base root. For now I'm getting around this with just /images instead of images/ in my css, which measn I just need to dev off a web server, and that keeps Jammit from rewriting. I get what Jammit is doing, but I think there's a working option.

[jashkenas]

Did you check out #203? It allows you to set the relative "public root" against which assets are resolved.

[napcs]

@jashkenas

No, somehow when I first looked at it I thought it was the asset_root that I was playing with earlier. This might do just fine and would probably go a long way towards fixing the problem for some people.