When I looked at the HTML source for my main page, the CSS that Rails was linking to was in /stylesheets/application.css. When I tried to click that link, I would get a 404 not found error from Passenger (Apache).
So what ended up working was setting config.assets.compile = true in my config file and running rake assets:precompile. This then changed the CSS link to something like /assets/application-5310fa2adccd74453c084cf221eaeeef.css, and this was something I could click on and could be found.
So now what I'm doing is every time I edit my CSS file, I run precompile. Is this the correct way to do things? Do I really have to call this every time I edit my CSS file? Is this the purpose of precompiling, to make sure my assets are able to be served by Apache?
When you are running your application in production mode, it is advised to precompile the static assets to enhance the performance.
But if you want to skip it, you can use
In config/environmets/production.rb
config.assets.compile = true
After this, you don't need to precompile assets after any change in css but it can slow down the performance and speed of your page load.
Related
Before deploying a new version of my app on Heroku, I need to do this in my console (for css and js to work on Heroku): RAILS_ENV=production bundle exec rake assets:precompile.
I just picket this code line from a forum, and I my questions is:
1) Why do I need to do this?
2) Is it possible to implement something more permanent in my Rails code so it does this precompiling automatically (so I don't need to write it manually every time I do some changes in my css or js files)?
1) Why do I need to do this?
There are lot of js files and css file in rails app generally. The above command compress and minified all those files which will reduce the number of requests that browser makes to render a web page. Web browsers are limited in the number of requests that they can make in parallel, so fewer requests can mean faster loading for your application.
More
2) Is it possible to implement something more permanent in my Rails code so it does this precompiling automatically (so I don't need to write it manually every time I do some changes in my css or js files)?
Yes. Heroku automatically compiles your assets if you dont include public/assets/manifest.yml for rails 3 and in rails 4 it is public/assets/manifest-<md5 hash>.json
More
Related Answer : Automatically precompile assets before pushing to Heroku
In your production.rb
config.assets.compile = true
I'm developping a Rails4 application with heroku hosting, and i encounter a bit of a problem:
I have a helper method to randomly pick an image by its path in /assets/images/path_to_image and this helper method is called in my HAML file. It works perfectly in my local environment. The images urls are stored in the DB. The problem is that Heroku changes the image names from logo.jpg to logo-a6d14b20c77aa6466e616313edcd3d34.jpg which makes my helper method useless. Any idea on how i could solve this problem? Is it a matter of pre-compiling the assets ?
Thanks a lot
B.
In rails4 by default assets gets the digest URL with them and getting served.
If you want you can use some middleware to redirect assets from non digest path to digest path.
or you can turn off the digest in production.rb file all together like below.
config.assets.digest = false
If you want that redirect solution I can post here as well.
Let me know!
Is it a matter of pre-compiling the assets?
Yes, I would say so
The problem you've got is that production environments compile all your assets, and consequently give you the hashed file-name you're seeing. The reason why this is a problem is that if you're referencing a static file (logo.png) in CSS or HTML, the compiled path will be different, causing the problem to occur. We learnt if you're going to reference any assets, always use a dynamic file (.scss / .haml / .html.erb) and then use the provided helpers
The way around this is to use the asset path helpers, which are basically like this:
image_path
asset_path
Heroku
It seems you're well versed with Rails so I don't bore you with the details
Heroku works best by serving static assets & pre-compiling them before you deploy:
#config/production.rb
config.serve_static_assets = true
You then need to pre-compile the assets with the production environment, like this:
> rake assets:precompile RAILS_ENV=production
This goes through your assets & assigns all the correct paths, if you've used the asset path helpers as mentioned above. After that, push to heroku & I always pre-compile the assets when on Heroku too (we use the asset_sync gem):
> heroku run rake assets:precompile --app [app_name]
I am trying to figure out how to get boostrap-sass working in production mode. I am using apache to reverse proxy to either webrick or puma, but serve the static assets in public/assets directly. When I precompile assets, the bootstrap css gets included into the application-(hash).css and it works correctly.
However the compiled css references an image file (glyphicons-halfling.png) without appending the hash of the file contents. The image file is included in public/assets directory, and it is possible to browse to it by putting the correct filename in the address bar, but the filename in the css does not match it. I have created a simple demo app that demonstrates this problem, code is on my github page
The glyphicon filename is glyphicons-halflings-c806376f05e4ccabe2c5315a8e95667c.png
[EDIT]
Would still like an answer to this question, but i've just renamed the offending files to remove the hash. Since these files are unlikely to change frequently then this should work fine
Think I have it cracked, when you run rake assets:precompile, it seems that you must prefix it with RAILS_ENV=production in order for it to work properly in production mode (I guess that kind of makes sense). If you don't, some of your assets will get precompiled, but the helper methods will not generate the correct paths.
tl:dr, RAILS_ENV=production rake assets:precompile
After deploying a Rails app to Heroku, no javascript functions are working.
The files appear to have been compiled (though its not easy to see in the minified file).
What is a logical process of steps to work out why the javascript is not working (it works fine in production).
Thanks
This problem is associated with asset pipeline. You should compile assets.
To solve it,
Turn config.assets.compress to true in config/environments/production.rb,
ie
config.assets.compress = true
Then run RAILS_ENV=production bundle exec rake assets:precompile .
Push the code again.
Sometimes I have issues because of the asset pipeline and my misunderstanding of it. So what I do just to make sure things are being packaged up correctly is just put in a simple alert when the page loads (put it on some random page users can't get to, etc)
alert('some-unique-string')
Push the code up to the server. Then in chrome bring up the page and use the dev tools, goto the "scripts" tab. From there you can search for the string some-unique-string since your string literal wont be minified. If you don't see that then you know your javascript isn't being included for some reason.
That at least will give you a starting point.
This month, I upgraded from Rails 3.0 to Rails 3.1 - this week I tried to launch the server in production mode - today I have hit a wall !
I am unable to get my production environment server to serve up my public assets (JavaScript and CSS) via the asset pipeline, unless I set config.assets.compile = truein my environment.rb file, which for speed reasons I obviously don't want to do.
I have a large number of JS and CSS files, each of which tends to get used on one or two different pages. This means creating a single "manifest" file doesn't fit my usage, as each page wants something slightly different. I also expect some of the CSS won't sit together nicely. Therefore I have gone down the approach of "just get it working", looking to tidy up the large quantity of CSS / JS later.
Here is the production.rb file:
Implicit::Application.configure do
...
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
# I set this to true, as I am testing this locally, just running a local Thin server
config.serve_static_assets = true
config.assets.compress = true
# Setting this to false removes the issue - but is SLOW
config.assets.compile = true
config.assets.digest = true
# This is overkill - but does get EVERYTHING precompiled for now
config.assets.precompile += %w( *.css *.js )
config.action_dispatch.x_sendfile_header = nil
...
end
This is quite a new area for me, and so I've spent much of today toggling these booleans and stop/starting the local Thin / Rails server to try them out. But the only value that's made a solid difference is the compile flag.
My application.rb file is pretty much standard, and has config.assets.enabled = true and config.assets.initialize_on_precompile = false in it, the latter from a heroku post (and a guess, again).
I have a fully populated public/assets directory, created with the bundle exec rake assets:precompile command, that takes about 20 mins to run on my oldish laptop (5 years), probably something to do with that "catch all" precompile regex, although with that line commented it still takes over 10 mins (!)
With the compile flag set to true, I can see copies of these assets getting created in my /tmp/cache directory - this is clearly the application creating it's own "compiled copy" of the assets.
With the compile flag set to false, I am confronted with the error message (in the logs, unless I set requests to local, then I see it on the rendered error page) of jquery.reveal isn't precompiled. However, when I go to http://localhost:3000/assets/jquery.reveal.js the javascript file is served up.
The line of my application layout causing this is:
<%= javascript_include_tag "application", "jquery.reveal" %>
I have tried changing that jquery.reveal to jquery.reveal.js with no change. Removing it fixes the index page, except that the jquery.reveal functionality is gone of course ! So clearly the application.js is being served up correctly. I just can't figure out why jquery.reveal isn't, as I can see the precompiled files in the public/assets directory.
This is an interesting issue, and I think there may be two bugs - the one you've linked and another: the file is being being compiled to the wrong name. It might be worth trying to generate a minimal test case that you can submit with a bug report.
The workaround for this - and I suspect that this is why few people seem to have the problem - is to use a secondary manifest (linking libraries only via a manifest seems to be an evolving best-practice).
Create one called home.js and require just that one file to it.
This isn't a bad approach overall. These extra manifests have to be added to the precompile array (see the guide), and allow multiple libraries to be shared over several pages or sections without having to link them each time.
Answering my own question here, but looks like it might be a bug in parsing assets with "periods" such as jquery.reveal
An issue report (https://github.com/rails/rails/issues/3398) reports this and highlights a commit (https://github.com/sstephenson/sprockets/commit/4ba5b32764a9073671df5e77355df6ed2bb3d3c9) which occurs just after Sprockets 2.0.3 - the default version that rails 3.1.3 relies upon. Upgrading Sprocket would therefore involve moving onto 3.2-stable rails - a bit bleeding edge for this newbie !
But the bug report does say this only occurs when config.assets.compile = true - and I did see whilst that was the case in my code that jquery.reveal was being dynamically compiled to jquery-8fu...8g.reveal.js (instead of jquery.reveal-8fu...8g.js).
So perhaps this ISN'T the answer. At least I hope it isn't. But will certainly continue to look at this period issue, as the "non-period" containing CSS / JS files are being served up just fine, as far as I can tell.