Static pages and assets in Rails 3.1.1

Currently working on a project where we need to drop in various static html pages + static assets for those from time to time that "just work." We cannot have anyone editing the html directly to place paths in for the assets. We need it to simply work such that the html + asset folders are placed directly into /public and the content is served up as it was generated.

When testing this behavior in production, it's a no go with errors such as:

ActionController:开发者_如何转开发:RoutingError (No route matches [GET] "/some_folder/some-image.png"):

I assume this is a result from what I'm reading from 3.1.x's asset pipeline.

How do you alter the routes such that these will be served up directly? Or is there a preferred way to keep this precise behavior? (Ultimately this will be deployed on heroku.)

Adding some more details as current remarks have not yet pushed my issue over the edge in terms of a solution:

In my present scenario I'm running it straight on WEBrick rails s -e production to test it out. In development mode this does work properly; the only exception is in production.

I am also running this prior to running the server: bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile --trace

When I actually attempt to load the page in production, I see the following output:

cache: [GET /] miss
cache: [GET /test_files/index.css] miss
cache: [GET /test_files/index.js] miss
cache: [GET /test_files/logo.png] miss
cache: [GET /test_files/background.png] miss
cache: [GET /test_files/horizontal.png] miss
cache: [GET /favicon.ico] miss

Upon further scrutiny of the production.rb I am seeing: "config.serve_static_assets = true" that when set to false by default evokes the issue experienced in webrick. So when setting that to true it serves the files up properly.

From some additional reading it appears that perhaps Heroku needs this set to false as well, which is the environment to which we're deploying.

Thanks for the input, but this appears to be the approach to take for now and I'd certainly appreciate any further input if this is NOT the correct answer or if there's a better approach.

As of Rails 3.1.1 the precompile task creates non-digested as well as digested filenames, so you can refer to these in static files (while still having the digest version in dynamic files).

The only problem is if you use far-future headers on the assets directory; changes to the undigested files won't be pick up by remote clients that still have a copy and believe the cache to still be valid.

You may need to look at an approach the replaces the non-digested filenames with the correct name during the deployment process.

If you do not use far-future headers in the directory then it does not matter - you can use either name.

For me the @ylluminate's answer helped: I've changed the config.serve_static_assets option to true in the config/environments/production.rb file and restarted the server with

$rails server --environment=production

and now it serves compressed assets.

NOTE: I've also precompiled the assets with

$bundle exec rake assets:precompile

(call rake this way assure will be used the rake version choosen for the project but I guess use just rake assets:precompile will work 99% of the times)

If you have /public/some_folder/some-image.png physically present (no matter if you just copied it there manually or it was generated by assets precompile), it must work. The server (e.g. Apache) will first check if the requested path exists in public, if it does it won't even call Ruby on Rails.

As far as digested filenames are concerned there is an option to turn this feature off, but I wouldn't recommend that for reasons already mentioned by someone else here.

Also you can put files that refer to assets in the app/assets folder and add a .erb extension AT THE END. Then you can use <%= asset_path ... %> inside that file, so no manual editing will be necessary. This will work even if you already have some other preprocessing on the file, for example sass - style.css.scss.erb will work. First the erb code will be evaluated (putting in the correct filenames for assets) then the sass compiler will be ran.

Oh and have a look at the sprockets-image-compressor gem, just add it to your Gemfile and it will automagically compress image assets too (losslessly using pngcrush and jpegoptim)...I don't know if the gem is rock-solid but from what I've seen I love it!