The issue here is that I have Bootstrap on production looking for the fonts at:
assets/spree/fonts/glyphicons-the-file-name.something
When in development mode, it looks for these assets in:
fonts/glyphicons-the-file-name.something
So what I did was I added the fonts folder into public and it all worked. I did the same for production. You can guess that I'm now dealing with a rails assets:clean issue that must be running and removing the files, hence not allowing them to appear.
Is there a way to tell Rails to not clean the files in assets/spree/fonts?
I'm assuming you installed the bootstrap files manually?
If you instead use a gem such as the following, then you won't have to worry about these issues:
gem "bootstrap-sass"
Alternatively, you should be installing everything into your vendor directory. As you've found you'll then have issues with any linked assets within these files. The correct fix for this would be to edit the bootstrap source to use the correct asset_path helpers.
Obviously that's quite a bit of maintenance overhead when you get round to doing the next bootstrap update.
I'd take a look at the bootstrap-sass gem, even if you decide not to use it.
Related
I am trying to package a rails app as a gem. Part of what I want to put into the gem are the precompiled assets (so the user doesn't have to bother with that). However, gem build <my_gemspec> chokes on the super long file names of the digested precompiled files in public/assets. Anyone else been through this?
Thanks!
One other note: this isn't a gem that would be used by another application. Rather its a packaging of a standalone rails app. The gem makes it easier for people to use it by simply calling its executable to run.
I got around this problem by doing:
config.assets.configure do |env|
env.digest_class = Digest::MD5
end
which shortened the asset names enough while still maintaining a digest
We always have ruby gem of famous javascript or css lib such as bootstrap-sass, ember-rails. But for some js lib such as bootstrap-lightbox, there are no gems sometimes. In order to manage these asset automatically, I found the jail(https://github.com/charly/jail) gem. But it seems that project is not so active now. Are there any better solution then just download and past file?
Many of those "assets gems" are just a basic skeleton with js/css assets, it should not be too hard to build your own and publish on rubygems!
An advantage of this, beside locking versions in Gemfile, is that you have control over them and don't risk screwing everything up during a bundle update.
I have found issues using external gems for managing assets, especially with bootstrap ones, sometimes the precompilation will break or they will upgrade the assets inside, breaking the entire site (or minuscole portions that you may hardly notice) with not-so-wanted changes.
In section 2.2.2, "CSS and Sass", I'm told to put image-url('delete.png') in my sass. And so I have.
However, it is generating CSS like
background-image: url(/images/delete.png)
instead of the thing that I'm told everywhere it should be generating, the correct and obvious thing,
background-image: url(/assets/delete.png)
What. The heck.
I have spent literal days trying to figure out where this is coming from.
Here's a gist of relevant settings that are resulting in this behavior. Here's a gist of the same files in an earlier version of our code base (right after we implemented the asset pipeline and it actually worked for about a week before this frustrating behavior popped up). Can you spot the differences? Any other files you can think of that might be causing this?
Note
We're purposely using an older version of sass-rails because a newer version was causing Stack level too deep! errors when precompiling.
We're using Compass.
Two hackish attempts at workarounds
Because actually troubleshooting the asset pipeline kinda sucks.
1: Put images in /images
I attempted to just move all of the images to public/images and add that as a load path. This worked in dev (images are accessible at either /assets or /images), but precompiling for production puts the fingerprinted images in /assets only (obvs), so when sass-rails puts in url(/imagse/delete-120398471029384102364.png), it can't be found.
2: Make /public/images a symlink to /public/assets
This would probably work in production, but in development the /assets folder doesn't exist, so the url(/images/delete.png) directives result in unfound images.
If you do not have this already, name your css file *.css.scss (as opposed to .sass - if you do this, you might need to adjust the syntax of some statements). Then use the image_path helper instead of image-path, e.g.:
background-image:url(image_path('delete.png'));
I expect this to solve your issue. If it does not, what is the asset path generated by this approach for you?
This looks to be due to your version of sass-rails (3.1.0). I can reproduce your problem (thanks for posting the Gemfile) and it goes away when bumping to sass-rails 3.1.4.
Try upgrading to 3.1.4 and clearing tmp/cache. Also make sure you're not hitting any browser caches.
I know you said 3.1.4 was causing other problems... have you tried higher versions?
It really looks like this issue: https://github.com/rails/sass-rails/issues/57
If so you should try to find the good combination of versions between Compass and Sass-rails.
And maybe upgrade everything (Rails included) to latest versions, it's still the best way to do (use bundle outdated command in bundler 1.2 to know what Gems to upgrade)
This is our combo of haml-rails, compass and sass-rails. We're running rails 3.2.6 though.
This has worked well for us.
gem 'compass', git: 'git://github.com/chriseppstein/compass.git', ref: '3a4c5c75dca9f07f6edf2f0898a4626269e0ed62'
gem 'haml-rails', git: 'git://github.com/indirect/haml-rails.git', ref: '92c41db61f20a9f122de25bc73e5045cfccdbcd5'
gem 'sass-rails', '~> 3.2.5'
Not necessarily a solution, but certainly an available option: If you're open to using compass spriting, you'll cut down on the number of http requests and be able to manually specify your image path with a sprite map, ie '$sprites: sprite-map("PATH/*.png");'
Sanity check the file in your current asset pipepline. Check that it's in one of the directories listed in here:
<%= debug Rails.application.config.assets.paths %>
Next check at what relative path compass expects to find the image ( and see if it mat. According to the Compass config docs, one of these should tell you:
<%= debug config.compass.http_images_path %>
<%= debug config.compass.http_generated_images_path %>
I'm guessing it's the first one. Either way, compare their path to your image's asset_path:
<%= debug asset_path 'delete.png' %>
If the paths don't match, maybe you need to adjust the path in your environment configs (development.rb, ...) to this for example:
config.compass.http_images_path = '/assets.
Alternatively, you could move the image to where http_images_path or the http_generated_images_path expect to find it.
At the point, asset_path/asset_url (which are much less brittle than hardcoding) should hopefully work. I based this off of a similar technique I saw for stylesheets,
For me,
Changing image_path to image-path worked for .scss. Later on, I changed to image_path again and it's working fine now.
Deleting cache didnt help me.
After I edited my .scss file (added a space) and reload the page I got right result. After I removed the space it worked correctly.
I am quite new with Rails and I am having some irritating problems with caching of css files.
I have a .css.less file with imports inside it. It's the only stylesheet the app includes, so the other files get imported only once and by this unique stylesheet.
One of those imported .css.less stylesheets seems to be cached somewhere, because does not change in the browser when I change it's source.
I can only see the changes I made if I change something in the root stylesheet.
I have the server in development mode, so the caching should be off. I have also used <%= stylesheet_include_tag "style", :cache => false %>
I tried with Chrome and Firefox, with and without clearing their cache too. Always the same result, if I work only on that file the css the page receives when reloaded doesn't have the changes...
I also stopped the server and rm everything in the tmp folder of the app. No changes.
I am using Rails 3.1 with Ruby 1.9.3, with the less-bootstrap-rails gem. Both the root stylesheet and the imported one have .css.less extension.
What am I missing?
Thank you!
This is an area where I think the asset pipeline is broken, but I don't think there's a good fix.
If I remember correctly, to get changes in files you've included/required in your .css.less file, you need to change the .css.less file itself.
I had this on Rails 4.0.8, infuriating. The config changes mentioned above didn't help. Here's what seems to have fixed it for me:
Ensure NO FILES share a base name. For example, you have a reports.css.less and a reports.js.coffee? Doesn't matter if they're in the same directory or not. Rename or delete one of them. (I changed it to reports-styles.css.less).
Blow away your cache: rm -rf tmp/cache
Restart your Rails app.
This appears to be a decent fix but, since I don't know what's actually going on, this could be totally false and it's just working by coincidence now. Sorry this answer isn't more rigorous!
I've just came across the exact same problem.
I found that if you rename your *.css.less file (the one with the imports inside) to *.less, then this weird cacheing problem gets resolved.
Add this to your config/application.rb
# Version of your assets, change this if you want to expire all your assets
config.assets.version = '1.0'
See more at: Ruby on Rails Guide: Asset Pipeline
If you are using HAML and SASS in your Rails application, then any templates you define in public/stylesheet/*.sass will be compiled into *.css stylesheets. From your code, you use stylesheet_link_tag to pull in the asset by name without having to worry about the extension.
Many people dislike storing generated code or compiled code in version control, and it also stands to reason that the public/ directory shouldn't contain elements that you don't send to the browser.
What is the best pattern to follow when laying out SASS resources in your Rails project?
The compass framework recommends putting your sass stylesheets under app/stylesheets and your compiled css in public/stylesheets/compiled.
You can configure this by adding the following code to your environment.rb:
Sass::Plugin.options[:template_location] = {
"#{RAILS_ROOT}/app/stylesheets" => "#{RAILS_ROOT}/public/stylesheets/compiled"
}
If you use the compass framework, it sets up this configuration for you when you install it.
I always version all stylesheets in "public/stylesheets/sass/*.sass" and set up an exclude filter for compiled ones:
/public/stylesheets/*.css
Honestly, I like having my compiled SASS stylesheets in version control. They're small, only change when your .sass files change, and having them deploy with the rest of your app means the SASS compiler doesn't ever need to fire in production.
The other advantage (albeit a small one) is that if you're not using page caching, your rails process doesn't need to have write access to your public_html directory. So there's one fewer way an exploit of your server can be evil.
Somewhat related, but it's a good idea to regenerate your CSS during your capistrano deployments. This callback hook does just that:
after "deploy:update_code" do
rails_env = fetch(:rails_env, "production")
run "#{release_path}/script/runner -e #{rails_env} 'Sass::Plugin.update_stylesheets'"
end
Update: This should no longer be necessary with modern versions of Haml/Sass.
If I can manage it, I like to store all of my styles in SASS templates when I choose HAML/SASS for a project, and I'll remove application.css and scaffold.css. Then I will put SASS in public/stylesheets/sass, and add /public/stylesheets/*.css to .gitignore.
If I have to work with a combination of SASS and CSS based assets, it's a little more complicated. The simplest way of handling this is to have an output subdirectory for generated CSS within the stylesheets directory, then exclude that subdirectory in .gitignore. Then, in your views you have to know which styling type you're using (SASS or CSS) by virtue of having to select the public/stylesheets/foo stylesheet or the public/stylesheets/sass-out/foo stylesheet.
If you have to go the second route, build a helper to abstract away the sass-out subdirectory.