rails 3.1 updating css issues - ruby

I just updated from 3.0.8 to rails 3.1 rc1. However,the css in my site is clearly not being accessed beacuse my site has no design anymore. I though i could fix it by creating an assets folder and placing my stylesheets and js inside the app/assets folder but that hasn't worked.
I also commented this line out in my config/environments/development.rb file
#config.action_view.debug_rjs = true
and I added this file to my config/application.rb file
config.assets.enabled = true
Here is what my gemfile looks like:
source 'http://rubygems.org'
gem 'rails', '3.1.0.rc1'
gem 'devise'
gem 'jquery-rails'
gem 'omniauth'
gem 'rails3-generators'
gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git'
gem 'sass-rails'
group :development do
gem 'sqlite3-ruby'
end
What am I doing wrong?
P.S. my images are also not showing up

Your app/assets directory should look like this:
app/
assets/
images/
pancakes.png
...
javascripts/
application.js
...
stylesheets/
application.css
...
There is a guide to the new asset pipeline. You might have to fix some paths as well.

Related

Heroku Production - ActionView::Template::Error (undefined method `directory' for #<Sprockets::Manifest:number>)

We have a react-rails app. Unfortunately, the app works on local development but not when deployed to heroku. When going to our default path on the app, we get the following error:
ActionView::Template::Error (undefined method 'directory' for #<Sprockets::Manifest:0x007fef13200aa8>)
We've figured out that it happens at this line in our view:
<%= react_component('NavBar', {}, {prerender: true}) %>
A few things about our app:
It uses browserify to compile our js.jsx.
We precompile using RAILS_ENV=production bundle exec rake assets:precompile after deleting the public/assets folder.
Works locally with both rails s and foreman start
We are using boostrap-sprockets. Even when removed, we still have this issue.
Here is our npm dependencies:
"dependencies": {
"browserify": "^10.2.4",
"browserify-incremental": "^1.5.0",
"classnames": "^2.2.3",
"reactify": "^1.1.0"
}
Here is our Gemfile
source 'https://rubygems.org'
gem 'rails', '4.2.3'
gem 'rails-api'
gem 'spring', :group => :development
gem 'active_model_serializers', '~> 0.10.0.rc1'
gem 'pg'
gem 'devise'
gem 'puma'
gem 'twitter'
gem 'react-rails', '~> 1.0'
gem 'browserify-rails', '~> 0.9.1'
gem 'bootstrap-sass', '~> 3.2.0'
gem 'sass-rails', '~> 5.0', '>= 5.0.4'
gem 'autoprefixer-rails'
group :test do
gem 'rspec-rails'
gem 'pry'
gem 'faker'
gem 'webmock'
end
group :development, :test do
gem 'factory_girl_rails'
end
group :production do
gem 'uglifier'
gem 'rails_12factor'
gem 'rspec'
end
ruby '2.2.4'
We would appreciate all help.
The solution from hours of searching on StackOverflow and github issues seems to be to remove
//= require react_ujs
from your application.js in your assets folder.
I ran into this same issue just today and followed the suggestions in: https://github.com/reactjs/react-rails/issues/443#issuecomment-180544359. I was still running into an error so for now I modified my heroku configurations (config/environments/staging.rb & config/environments/production.rb) to use
config.assets.compile = true
for now and server-side rendering worked fine. The react-rails folks said they have a pull request completed to fix this issue but I dont think it has been released yet.
Potentially relevant: rake assets:precompile undefined method directory? for nil:NilClass
This is an error that occurs when the Rails asset compiler (Sprockets) cannot find a directory that you've specified as the location of an asset for your project. My suggestion is to make sure that all your assets are being successfully deployed to heroku, and then check that your paths are set up correctly when you reference assets in your project for inclusion in a page.
Also see Eric C's answer pertaining to React-Rails specifically.
There was a bug in react-rails 1.6.0 which should be fixed in 1.6.1
Here's the patch:
https://github.com/reactjs/react-rails/pull/478
If the latest version doesn't work for you, please open an issue on the react-rails repo!

Why did Rails4 drop support for "assets" group in the Gemfile

In Rails 3, gems used exclusively to generate assets in the asset pipeline were properly placed in the assets group of the Gemfile:
...
# Gems used only for assets and not required
# in production environments by default.
group :assets do
gem 'sass-rails'
gem 'coffee-rails'
gem 'uglifier'
# See https://github.com/sstephenson/execjs#readme for more supported runtimes
# gem 'therubyracer', :platforms => :ruby
end
Now, according to the (still in progress) upgrade documentation:
Rails 4.0 removed the assets group from Gemfile. You'd need to remove that line from your Gemfile when upgrading.
Sure enough, making a new project with RC1 yields a Gemfile with asset-related gems included by default outside of any group:
source 'https://rubygems.org'
# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.0.0.rc1'
# Use sqlite3 as the database for Active Record
gem 'sqlite3'
# Use SCSS for stylesheets
gem 'sass-rails', '~> 4.0.0.rc1'
# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'
# Use CoffeeScript for .js.coffee assets and views
gem 'coffee-rails', '~> 4.0.0'
# See https://github.com/sstephenson/execjs#readme for more supported runtimes
# gem 'therubyracer', platforms: :ruby
...
Does this mean these gems will now be bundled in production builds by default? If so, why the change of heart? Is Rails 4 moving towards the dynamic generation of assets in production?
Previously the assets group existed to avoid unintended compilation-on-demand in production. As Rails 4 doesn't behave like that anymore, it made sense to remove the asset group.
This is explained in more detail in the commit that changed that. I extracted some quotes with the actual answer.
Some gems can be needed (in production) like coffee-rails if you are using coffee templates
and the fact that now assets are not precompiled on demand in production anymore.
(not precompiled on demand in production) Means that if you have that gems in production environment in 3.2.x and forget to precompile, Rails will do exactly what it does in development, precompile the assets that was requested. This is not true anymore in Rails 4, so if you don't precompile the assets using the tasks you will get a 404 when the assets are requests.
Rails 4 try to force you to precompile your assets before deployment. You have to precompile your assets with
$ RAILS_ENV=production bundle exec rake assets:precompile
And why?
I found this in Guide:
By default Rails assumes that assets have been precompiled and will be
served as static assets by your web server.
(Source: http://edgeguides.rubyonrails.org/asset_pipeline.html#in-production)
But many time you have to use these 'assets' gems in production... for example, if you use a js.coffee file in your views directory, then Rails needs coffee compiler in production mode as well.
So I guess, the reason of this change is performance improvement... and looks more simple as well. :)
We want coffeescript with AJAX (history), so coffee-rails moves out of the assets group.
sass-rails misbehaves (history), so it moves out of the assets group.
Axe the assets group.

Error syncing .less files when I push to Heroku app using asset_sync gem?

I have a Rails 3.2.12 app and I was trying to sync my assets using an Amazon S3 bucket and the asset_sync gem for my Heroku app.
I've looked on the whole github issues tracker and here on SO, but wasn't able to find an answer to this. So here's my question:
Is it possible to sync .less files using the asset_sync gem?
After I push to Heroku, I get in the logs this error:
Running: rake assets:precompile
rake aborted!
variable #inputHeight is undefined
(in /tmp/build_tejom7tf9zq9/app/assets/stylesheets/utils-and-mixins.less)
In order to config my app I followed the wiki from the asset_sync github page and to set my ENV variables I used the Built-in Initializer.
Here are the modifications in my production.rb file in order to fit the asset_sync requirements:
# Precompile additional assets (application.js, application.css, and all non-JS/CSS are already added)
config.assets.precompile += [ '*.css' ]
# Serving Assets From S3 on Heroku
config.action_controller.asset_host = "//s3.amazonaws.com/test"
# store assets in a 'folder' instead of bucket root
config.assets.prefix = "/production/assets"
end
Any suggestion would be highly appreciated. Thank you
Edit 1:
I tried even running separately in my command line:
heroku run rake assets:precompile --app <yourapp>
but it didn't help, it threw the same error.
Edit 2:
I guess this is what you asked for:
....
gem 'less-rails', '~> 2.3.2'
gem 'twitter-bootstrap-rails', '2.2.6'
# Gems used only for assets and not required in production environments by default.
group :assets do
gem 'sass-rails', '~> 3.2.3'
gem 'coffee-rails', '~> 3.2.1'
gem 'uglifier', '>= 1.0.3'
gem 'therubyracer', '~> 0.11.4', platforms: :ruby
gem 'asset_sync'
end
Managed to make it work by writing in my production.rb the specific .css file names that I wanted to include to my S3 bucket:
# Enable serving of images, stylesheets, and JavaScripts from an asset server
config.action_controller.asset_host = "//s3.amazonaws.com/test"
# Precompile additional assets (application.js, application.css, and all non-JS/CSS are already added)
config.assets.precompile += %w( public.css users.css admin.css )

Sinatra-assetpack not compiling Less files in Classic type Sinatra app

I cannot figure out how to do this. All my main .less files are in /app/css/less, with #import'ed files in /app/css/less/bootstrap. My main stylesheet is /app/css/less/style.less which should be compiled to '/public/css/style.css'.
Using a classic Sinatra app structure (not base), I have the following in various files (unrelated code left out):
****Gemfile
# encoding: utf-8
source :rubygems
gem 'sinatra'
gem 'thin'
gem 'less'
gem 'therubyracer'
gem 'haml', '~> 3.2.0.rc.1'
gem 'sinatra-partial'
gem 'sinatra-assetpack', :git => 'git://github.com/rupe/sinatra-assetpack.git', :require => 'sinatra/assetpack'
****myapp.rb
# encoding: utf-8
require 'rubygems'
require 'bundler/setup'
require 'sinatra'
require 'haml'
require 'sinatra/partial'
require 'sinatra/assetpack'
require 'less'
assets do
Less.paths .lt.lt "#{settings.root}/app/css/less"
Less.paths .lt.lt "#{settings.root}/app/css/less/bootstrap"
serve '/css', from: '/app/css/less'
css :style, [
'/css/style.css'
]
prebuild true
end
****layout.haml
!= css :style, :media => 'screen'
Which produces this stylesheet related tag in the served up html:
link rel="stylesheet" href="/css/style.496718.css" media="screen"
but does not actually compile the file style.49718.css. In fact, it doesn't compile any files at all.
note: The git branch, referred to in Gemfile, is a copy of the 'pbaker' branch that fixed Less support (supposedly). I have tried the standard gem, and other versions, all without any luck.
What could be the possible cause(s)?
NOTE: A related question, but not duplicate (as it refers to #import issues only), can be found here.
Finally figured out what the problem was, I had to use the --all option when running bundle package. So bundle package --all created a local cache of my custom git fork of the sinatra-assetpack gem, and all works "as advertised" now :)
As an alternative (and for google's posterity), there's been a bunch of work on the AssetPack gem recently (with less support now built in).
This Gist has a full example of less support: https://gist.github.com/4652773.

Gem development with Bundler: include or exclude Gemfile?

I'm developing a gem locally. It's a command-line utility that only has test dependencies, and my Gemfile looks like this:
source :rubygems
gemspec
group :test do
gem "cucumber"
gem "aruba"
gem "rspec"
end
My gemspec looks like this:
Gem::Specification.new do |s|
# authorship stuff...
s.files = `git ls-files`.split("\n")
end
That's the default gemspec created by Bundler. I know we're supposed to keep Gemfile and Gemfile.lock in source control, but I'm wondering about including them in the packaged gem through the Gem::Specification#files attribute. Are there arguments for/against including Gemfile and Gemfile.lock in the distributed gem? It seems weird or at least unnecessary to me.
Yehuda Katz just blogged on this topic! : Clarifying the Roles of the .gemspec and Gemfile

Resources