I have a new-ish rails 3.1.1 app using sass/compass with compass taking care of the sprite generations for me. In development, all works just fine. However, when I deploy, I see this entry in the log file:
Compiled team/application.css (1ms) (pid 24202)
Compiled team/forms.css (0ms) (pid 24202)
Compiled team/member.css (0ms) (pid 24202)
Compiled application.css (0ms) (pid 24202)
Completed 500 Internal Server Error in 2014ms
ActionView::Template::Error (File name too long - /home/cri/webapps-releases/cri/releases/20111121225403/app/assets/images/html,body,div,span,applet,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote...(the rest of my compiled css goes here)
My production config (for asset stuff) is pretty vanilla wiht much of it being what was generated by rails:
# Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = false
# Compress JavaScripts and CSS
config.assets.compress = true
# Specify the default JavaScript compressor
config.assets.js_compressor = :uglifier
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = true
# Generate digests for assets URLs
config.assets.digest = true
config.assets.debug = true
Can anybody tell me why my compiled css is being used as the filename for the sprite?
Update: Modified title to reflect what I now think I know about this issue.
I am running rails-3.1.1 with sass-3.1.10 and sass-rails-3.1.5 and compass-0.11.3.
compass-0.11.3 does not have proper asset pipeline support you are going to want to be using the >= 0.12.alpha.3 release you can get this by doing gem install compass --pre if you are still having this issue under 0.12 then it is a bug and i would be grateful if you would file a ticket on the compass github.
Try
config.assets.debug = false
Those workarounds are true, but this bug in rails was fixed in 3.1.4. Upgrading is likely your best all-around bet.
Related
After changing an asset (a css or js) file I see in the logs that the change was noticed and compiled, and the browser also auto-reloads.
[debug] Live reload: priv/static/js/app.js
10:53:15 - info: compiled MyComponent.jsx and 2095 cached files into 2
files in 2.3 sec
However, it doesn't appear that the assets in /priv/static were actually updated. I can only see my change in the browser once I run mix phx.digest, and hard refresh the browser.
Any ideas on how to troubleshoot this?
Using:
Phoenix 1.3
brunch 2.10.7
config/dev.exs:
config :my_app, MyApp.Web.Endpoint,
http: [port: 4000],
debug_errors: true,
code_reloader: true,
check_origin: false,
watchers: [node: ["node_modules/brunch/bin/brunch", "watch", "--stdin",
cd: Path.expand("../assets", __DIR__)]]
# Watch static and templates for browser reloading.
config :my_app, MyApp.Web.Endpoint,
live_reload: [
patterns: [
~r{priv/static/.*(js|css|png|jpeg|jpg|gif|svg)$},
~r{priv/gettext/.*(po)$},
~r{lib/my_app/web/views/.*(ex)$},
~r{lib/my_app/web/templates/.*(eex)$}
]
]
TL;DR — If you don't set the cache_static_manifest setting on your endpoint, it won't generate versioned URLs.
So, I know I'm about three years late here, but I recently figured this out. I discovered that merely setting the cache_static_manifest value in the Endpoint config will cause it to use the digest in any mode. (This is documented, but not in a way that seemed particularly clear to me.)
Now, you might be thinking "But I didn't set that in dev mode." I thought that, too, until I realized that I had written a naive config/runtime.exs.
At the time, I had been focused on configuring things a runtime when running a release, but completely forgot that it configures things even when not running in a release. Once I made it conditional, everything was fine.
Example:
if Config.config_env == :production do
config :my_app, MyAppWeb.Endpoint, cache_static_manifest: "priv/static/cache_manifest.json"
end
I ran into the same issue and for me it helped to manually remove the static folder with rm -rf priv/static and to restart the server with mix phx.server. Afterwards the hot reloading worked without having to manually run mix phx.digest all the time.
Another possible cause is that the Endpoint module (lib/my_app_web/endpoint.ex) is setting Plug.Static to use compressed assets:
defmodule MyAppWeb.Endpoint do
use Phoenix.Endpoint, otp_app: :my_app_web
plug Plug.Static,
# ...
gzip: true,
Then, if a release has been built from within the project directory and the gzipped assets are still present when developing, they will be served instead of the newly-saved, non-compressed assets.
To avoid this:
config/dev.exs:
config :my_app, :environment, :dev
config/test.exs:
config :my_app, :environment, :test
config/prod.exs:
config :my_app, :environment, :prod
lib/my_app_web/endpoint.ex:
defmodule MyAppWeb.Endpoint do
use Phoenix.Endpoint, otp_app: :my_app_web
in_prod = Application.get_env(:my_app, :environment) == :prod
plug Plug.Static,
# ...
gzip: in_prod,
I'm currently having the exact same problem as described in this post: Rails not serving assets in production or staging environments.
I am running Rails 4.0.4 in production environment on Windows 7 (so that could easily be the problem, can't use Linux unfortunately). I have run rake assets:clobber to make sure everything is cleaned up and and then RAILS_ENV=production rake assets:precompile and it succeeds without errors or warnings. All the files appear in my public/assets folder and using Windows explorer I can view the text in application.js and application.css, and images display correctly. However when I try to visit localhost:3001/assets/application.js it is blank, same with application.css, and image files come up with an error. I have restarted the server each time after changing settings and precompiling.
When I look at the logs it says the page renders successfully, there are no "No route matches" errors like I have seen in other posts. So the assets are being found, but for some reason they aren't being properly served.
Here is my production.rb:
ABC::Application.configure do
config.cache_classes = true
config.eager_load = true
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
config.action_dispatch.x_sendfile_header = "X-Sendfile"
config.serve_static_assets = true
config.action_mailer.default_url_options = { :host => '' }
config.i18n.fallbacks = true
config.active_support.deprecation = :notify
config.assets.js_compressor = :uglifier
config.assets.css_compressor = :sass
config.assets.compile = false
config.assets.digest = true
end
Any help would be much appreciated, I've been stuck on this for nearly two days!
Just as I finished typing up this question, I finally came across another post which said the headers were being set but there was no body, which sounded like my problem. They were using nginx and fixed the problem by changing the following:
# Specifies the header that your server uses for sending files
# config.action_dispatch.x_sendfile_header = "X-Sendfile" # for apache
config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect' # for nginx
And seeing as I'm not using either Apache or nginx, I commented out both lines and finally my assets were served. Seems obvious in hindsight but I thought I would post this anyway in case it helps anyone else having the same problem.
After upgrading to Rails 4, public/assets/manifest.yml is not generated anymore. Instead the different formatted manifest-(fingerprint).json is present.
But it seems to me that the server is still looking for the old manifest.yml format, ignoring the .json version?
I see other questions based on similar problems, but they seems to be sovled by upgrading to Rails 4, adding rails_12factor to gem file, setting serve_static_assets = true, etc., but none of these solutions seems to have any effect in my scenario.
I am tired and uninspired due to this annoying problem, any help will be appreciated!
Logfile from Heroku:
ActionController::RoutingError (No route matches [GET] "/assets/layouts/test/test.html"):
Gemfile:
ruby '2.0.0'
gem 'rails', '4.0.0'
...
gem "compass-rails", github: "milgner/compass-rails", ref: "1749c06f15dc4b058427e7969810457213647fb8"
...
gem 'rails_12factor', group: :production
production.rb
RailsFoundationAngular::Application.configure do
config.assets.initialize_on_precompile = false
config.cache_classes = true
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
config.serve_static_assets = true
config.assets.compress = true
config.assets.compile = false
config.assets.digest = true
config.i18n.fallbacks = true
config.active_support.deprecation = :notify
config.action_dispatch.x_sendfile_header = nil
end
I am using Angular and their ui-router, and this is the part of my routes.js.coffee where the test.html is linked:
.state "root",
url: "/"
views:
"root":
controller: "ApplicationController"
templateUrl: "/assets/layouts/test/test.html"
I have also tried precompiling locally, but as I am using Rails 4 here as well, still no manifest.yml is created, only the .json version.
Of course, everything is working just perfectly in development...
So my actual cuestion:
How do I make Heroku recognize and use the manifest-(fingerprint).json -file, or alternative ways to make this work?
The answer is, that Heroku already does recognize and use the manifest-(fingerprint).json -file. The "workaround" in my comment above, is the proper way to reference these files, and by doing so, the manifest-file is used the way it's ment to be used.
Renaming the file with the internal link to .erb, and referencing like this: templateUrl: "<%= asset_path('layouts/test/test.html') %>" does the trick. All internal files, images, and html -files should be referenced like this.
It's all described very thoroughly here: Asset-pipeline guide
It seems so simple and straightforward now, but I really spent a lot of time trying to get the wrong way around this from the beginning.
I hope this answer can save the time for someone else.
Working on rails, images are not visible and giving error.
Started GET "/assets/home.png" for 127.0.0.1 at 2012-06-19 12:23:24 +0530
Served asset /home.png - 404 Not Found (24ms)
ActionController::RoutingError (No route matches [GET] "/assets/home.png"):
I have used command
rake assets:precompile
production.rb
config.assets.compress = true
config.assets.compile = false
application.rb
config.assets.enabled = true
config.assets.version = '1.0'
Thanks for any help!
Actually you cannot reference your image with /assets/home.png path.
It will work in development mode, but in production all of your assets have a fingerprint in their filename (read this http://guides.rubyonrails.org/asset_pipeline.html#what-is-fingerprinting-and-why-should-i-care-questionmark)
That's why, in assets-pipeline enabled applications you need to reference all of your assets using helper methods. Read this doc to learn about the different helpers available in Ruby, JS and Sass files: http://guides.rubyonrails.org/asset_pipeline.html#coding-links-to-assets
The lack of a fingerprint in the file request suggests that you are running this in development. I am also going to guess that this is an app upgraded from an older version of Rails.
Any images need to be in the folder /assets/images for the pipeline to work.
Also, you do not need to precompile when in development mode.
Delete the public/assets folder, delete the folder tmp/cache/assets, and restart your server.
If this images are in the correct location, it should work.
The command "rake assets:precompile" works very slow for me. Especially on my Amazon EC2 Micro production server which does not have a lot of processor resources. On EC2 I have to wait 1 minute or more during each deployment just for this precompile task alone. Is there a way to make it faster?
Previously I used Jammit to compress/minify css and js. Jammit worked nearly 10 times faster on the same web site and servers.
If you don't need to load the Rails environment, you should disable that with:
config.assets.initialize_on_precompile = false
EDIT: I've just written a gem to solve this problem, called turbo-sprockets-rails3. It speeds up your assets:precompile by only recompiling changed files, and only compiling once to generate all assets.
It would be awesome if you could help me test out the turbo-sprockets-rails3 gem, and let me know if you have any problems.
There is a bug in Rails 3.1.0 that includes too many files in the precompile process. This could be the reason for the slowness if you have many assets js and css assets.
The other is that Sprockets (the gem doing the compilation) is more complex and has to allow for more options - scss, coffeescript and erb. Because of this I suspect it will be slower doing just concatenation and minification.
As suggested, you could precompile the files before deploying them if this is still an issue.
My solution is to exclude application.js .css and any other application related assets from from precompilation. So that i can use rake assets:precompile once to precompile engine related assets only.
Then on each deploy i use a simple rake task to build any application related assets and merge them into manifest.yml:
namespace :assets do
task :precompile_application_only => :environment do
require 'sprockets'
# workaround used also by native assets:precompile:all to load sprockets hooks
_ = ActionView::Base
# ==============================================
# = Read configuration from Rails / assets.yml =
# ==============================================
env = Rails.application.assets
target = File.join(::Rails.public_path, Rails.application.config.assets.prefix)
assets = YAML.load_file(Rails.root.join('config', 'assets.yml'))
manifest_path = Rails.root.join(target, 'manifest.yml')
digest = !!Rails.application.config.assets.digest
manifest = digest
# =======================
# = Old manifest backup =
# =======================
manifest_old = File.exists?(manifest_path) ? YAML.load_file(manifest_path) : {}
# ==================
# = Compile assets =
# ==================
compiler = Sprockets::StaticCompiler.new(env,
target,
assets,
:digest => digest,
:manifest => manifest)
compiler.compile
# ===================================
# = Merge new manifest into old one =
# ===================================
manifest_new = File.exists?(manifest_path) ? YAML.load_file(manifest_path) : {}
File.open(manifest_path, 'w') do |out|
YAML.dump(manifest_old.merge(manifest_new), out)
end
end
end
To specify which assets to compile i use a YAML configuration file (config/assets.yml):
eg.
---
- site/site.css
- admin/admin.css
- site/site.js
- admin/admin.js