Rails just compress javascript in development mode but i dont need to.
Here is the config/environments/development.rb
# Do not compress assets
config.assets.compress = false
# Expands the lines which load the assets
config.assets.debug = true
Rails version is 3.2.8 but also tried 3.2.9-rc3, 3.1.8 doesnt work with my application because it was created in 3.2.8
I just found that rails serves precompiled assets instead of assets from app/ catalog when they are exist. Its need to remove them to make Rails work like i need.
rake assets:clean
I belive Rails must not behave that way in development mode.
Related
I have searched around and can't rectify the situation based on the responses to other similar questions. I seem to have broken the asset pipeline somehow but can't seem to figure out how.
None of my assets are being loaded at all; rails seems to just be ignoring my manifest files. When I inspect my page in firebug, only the 'non-compiled' text inside my manifest files (both js and css) is being displayed - almost as if the asset pipeline wasn't even enabled.
I deleted the contents of public/assets since I was adding a new file to the manifest which seemed to start this behavior.
Current configuration:
environments/development.rb
# Do not compress assets
config.assets.compress = false
# Expands the lines which load the assets
config.assets.debug = true
application.rb
# Enable the asset pipeline
config.assets.enabled = true
config.assets.manifest = config.root
# Add extra assets for precompiling
config.assets.precompile += ['admin.js', 'admin.css']
# Version of your assets, change this if you want to expire all your assets
config.assets.version = '1.0'
I had the same issue. You can still use Ruby 2.1.2, just upgrade rails to latest 3.2.x version - it's 3.2.22
Gemfile:
gem 'rails', '3.2.22'
And run:
$ bundle update rails
The issue was caused by using an incompatible version of ruby. I was using version 2.1.2 which lead to unusual behavior from the sprockets gem (which powers the asset pipeline). This was fixed by downgrading to ruby 1.9.3. I haven't done any experimentation for fear of breaking it again but maybe this has been addressed in later versions of sprockets. I am using sprockets 2.1.3.
See: Rails 3.2.8 Application.js and Application.css are not working as expcted
Always remember two things when you want to handle Rails asset pipleline:-
if you want all you newly created js/css to autoinclude in application.js/css,pls add them in...
ELSE
IF you dont wont to add in manifest file(application.js/css) then use precompile directive in yuur environment file.
config.assets.precompile=%w(custom.css,custom2.js...etc)
so make sure you have either of these...
===========for example=-=============
suppose you have new css/js file:-
custom.css inside
app/assets/stylesheets/
so you can include in
application.css
// = require 'custom'
OR
use precompile directive:-
config.assets.precompile += %w( custom.css )
and then reference it like you always do
stylesheet_link_tag "custom"
same applies for js also
I just spent a few hours troubleshooting this issue (in 2017!) and it turned out I just needed to remove the gem active_reload. Updating rails and ruby was having no effect for me. The thread where I found that gold is here:
https://github.com/rails/rails/issues/2715
I just updated a Rails 3.2.x app to 4.0.2.
When I deployed to production (ubuntu, MRI 2.0) I got the good old error about the lack of a javascript runtime.
I quickly fixed it by installing node, but it makes me wonder.
I prefer to precompile the assets locally, check them into git, and then push them to the production server along with the rest of the application.
With Rails 3.2 this system has always allowed me to not care about a js runtime in production, as the application doesn't need to compile coffeescript or run uglyfier.
So, the question is: what has changed with Rails 4? Is there a config option to control this behaviour?
I checked my (rails 4) config file, and I think that the production evironment is already configured to NOT fallback to live compilation.
assets-related config options:
config/application.rb
config.assets.precompile += ['html5shim.js']
config.assets.initialize_on_precompile = false
config/environments/production.rb
# Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = false
# Compress JavaScripts and CSS
config.assets.js_compressor = :uglifier
# config.assets.css_compressor = :sass
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = false
# Generate digests for assets URLs
config.assets.digest = true
# Version of your assets, change this if you want to expire all your assets
config.assets.version = '1.0'
In case someone hit this question as I did. I had the same problem and this link pointed me to the right direction: https://mattbrictson.com/upgrading-to-rails-4-with-capistrano. Specifically the following statement: In Rails 4, the standard Gemfile no longer has an :assets group, which means asset pipeline gems are always loaded in production, on all servers. I precompile my assets locally and upload them to production, so there is no reason to have JS runtime on production server.
In my case I added group :asset to my Gemfile putting there asset-related gems. In my case it was:
group :asset do
gem 'uglifier'
gem 'execjs'
end
My capistrano tasks on production install bundle without :asset group, so after this change JS runtime is no longer required on production.
Environment: heroku
Rails: 4
Ruby: 2
We deployed an app to heroku, and it seemed as though anything in the public folder was not accessible (didn't see the static file so the router kicked in and then complains about no route matching).
To get around this, we set
# Rails 4 only flag
config.serve_static_assets = true
in our production.rb file. Is this really the best way to handle this? Or did we fail to configure the app some how to be hosted on heroku properly?
This is deprecated in Rails 4.2, and it is now an alias slated to be removed in Rails 5.0
config.serve_static_assets = true
It should be changed to:
config.serve_static_files = true
In previous Rails versions, Heroku injected a plugin that enabled serving of static assets so this issue didn't exist. As this plugin system was removed in Rails 4, they now created a gem which does the same. You enable it in your Gemfile via:
gem 'rails_12factor', group: :production
See Getting Started with Rails 4.x on Heroku
You could also of course use a CDN for your assets, but you're not required to.
For Rails 5+ work on twelve-factor platforms out of the box and the gem is no longer required
As Dean Winchester mentioned it, it is a good idea to use a CDN for your static assets. In fact when using only Heroku your Rails application would have to be responsible to serve static assets since Heroku Cedar architecture will not do that for you.
Setting config.serve_static_assets = true is the way to go if you don't want to configure a CDN and use only Heroku.
The rails guides are wrong. Try...
config.assets.serve_static_files = true
I have deployed this app (rails 3.2.11) a million times, I haven't messed with any settings, but now I'm greeted with this:
Why did this happen out of the blue? My conents of application.rb include config.assets.enabled = true - never had any issues.
In fact running it locally on port 3000 seems to not have any issues whatsoever.
After deploying to heroku this morning, it seems that it loads nothing that's inside /assets/
Interestingly, after copying the files over to try and just make a new app, git commit results in all the stuff you'd expect as well as a LONG list of these which I think might be related:
Edit: Interestingly enough SOME of the assets have loaded, like the logo and the background, but the rest as you can see return 404.
put line in config/environments/production.rb
config.assets.compile = true
it worked as it will compile the assets on runtime, just like in development environment, but its makes application slow, the best way is to either compile the assets locally in production environment with rake task(RAILS_ENV=production bundle exec rake assets:precompile) and commit your generated assets in public/assets and then do deployment. or, heroku run rake assets:precompile
I had this problem today with rails 4 on heroku. The article provided by #Jeff is a little bit old but, the gem repository has a good readme.
Summarizing, you will need to add two gems to your Gemfile:
gem 'rails_serve_static_assets' (it will solve the static assets problem) and
gem 'rails_stdout_logging' (which the previous one depends on).
Heroku released a gem to handle the assets without needing to turn off compilation or to manually compile.
https://devcenter.heroku.com/articles/ruby-support#static-assets
Just add this to your Gemfile and redeploy.
gem 'rails_serve_static_assets', group: [:production]
For Rails 4, use:
config.serve_static_assets = true
The default was false. We needed this after removing the rails_12factor gem.
Rails recommended that this setting config.serve_static_assets by default should be disabled i.e. set to false. Here is the default configuration in config/environments/production.rb generated in rails app
Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = false
So if you are setting it to true in your local app then that's still fine. But if you are deploying your app on Apache or ngix or anything other than heroku then its not advisable to make config.serve_static_assets=true in your production.rb config file. Here is the documentation from Rails guides.
config.serve_static_files configures Rails itself to serve static
files. Defaults to true, but in the production environment is turned
off as the server software (e.g. NGINX or Apache) used to run the
application should serve static assets instead. Unlike the default
setting set this to true when running (absolutely not recommended!) or
testing your app in production mode using WEBrick. Otherwise you won't
be able use page caching and requests for files that exist regularly
under the public directory will anyway hit your Rails app.
URL - http://guides.rubyonrails.org/configuring.html
To make the assets to load with the corresponding fingerprint of each file verify the configuration config/environments/production.rb has the instruction:
ruby
# Load assets with fingerprint behavior
config.assets.digest = true
Using Rails 3.2.2 and ruby 1.9.2 and I am not able to serve assets in production. We are running on apache. I've read some documentation and set :
config.serve_static_assets = true
config.assets.compile = true
in production.rb, and it doesn't seem to work. What else can I try? Or how can I get some debug info on where it IS looking.
Also, I went back to development, and went into assets/images and deleted .png files in order to intentionally break things in the development environment, but it didn't work, the images still show up. There must be some pre-compiling of assets, but where do they get stored, and how would I clear that? thanks
Usually, if you have Apache in front of your rails server, you would not want your application to compile assets in production. You probably want to pre-compile assets and have Apache serve them.
Compiled assets are stored in public/assets by default.
How all this comes together depends on the particulars of your configuration, which you have not shared. I would recommend reading the rails guides on the asset pipeline:
http://guides.rubyonrails.org/asset_pipeline.html
and in particular:
http://guides.rubyonrails.org/asset_pipeline.html#in-production
It heven has some examples of how to configure Apache.
In config/application.rb:
config.assets.enabled = true