I have a Rails app running on a shared web host under a folder in my root direction called 'mintrus-ror/'. There is a symbolic link 'public_html/' that points to 'mintrus-ror/public/'. My Rails app loads in the browser but the stylesheets don't load. Looking at the rendered source I noticed the assets path it is using is '/mintrus-ror/assets/application.css'. I am trying to figure out how to change it so it does not include the 'mintrus-ror/' directory in the assets path. Any ideas?
You can try playing with the config.assets.manifest configuration option in config/environments/production.rb. There are other variables that influence this, one being the web server configuration. I've got no recent (less than six years ago) experience with shared hosts, but I've read that on some systems, you can edit the .htaccess file.
I also presume that you're running in production mode and have previously compiled the assets with rake assets:precompile during your deployment step. Capistrano does this automatically when the asset pipeline integration is turned on.
The Rails Guide on the Asset Pipeline may be useful.
Your best bet may be to host on Heroku. It's free for small sites and a lot less hassle.
Related
I've started learning rails and I've already built two apps, one simple blog app and one store app. Now I ran into a term precompile assets when uploading to heroku, can someone explain it to me is that necessary when deploying an app to production, because i've uploaded my store app to heroku without any problems?
Assets is your css + JS. Precompile assets mean that they get joined into single .css and another single .js. file (to load it in one HTTP request). And special mechanism of minifying get applied to both these files (to make them smaller). Rails by default is setup in a way, that it uses average files in dev and compiled files in prod. You can easily change this in configs, but you shouldn't do this unless you really know what you do.
If you want you can compile this files locally running rake assets:precompile and then put it into git. I think that you can disable/enable precompile during heroku deploy in heroku config. But, in general, I would stick with the very defaults.
More info on asset pipeline: http://guides.rubyonrails.org/asset_pipeline.html
Rails has an assets pipeline which consists of Sprockets and the assets helpers.
The assets pipeline will concat and minify your CSS and javascript and takes care of setting the correct paths to images and other assets. This is known as compiling the assets.
In development this is done on the fly for each request which lets you immediately see changes.
In production this would be far to slow so instead the assets should be compiled once at deploy time. Heroku does this automatically for you in a post-commit hook.
Pre-compiling is when you run rake assets:precompile locally and then upload or push the result to a server. This is done if you are deploying to a server without the support for the assets pipeline. For example if the production server does not have a javascript runtime which is required to run uglifier.
It adds tons of noise to the git change history and manually doing anything is a common source of user error. So pretty much it sucks and you only do it if you have to.
i have a Rails application deployed on Openshift. I added marker for hot deploing and hot deploying itself works fine, but during the time application is hot deployed css and js files are not served. When hot deployment ends these files work fine again. I also use Bootstrap and Sass in this application (gem 'bootstrap-sass'). Do you have any idea why this happens?
The files are being served by Apache via the Passenger module. The files are being replaced "in place" which causes them to be removed/rebuilt, which is causing them to not be served during that time, and since they are static assets, they are not stored in memory. Unfortunately there is currently no way to make hot deploy work fully with Rails to keep the site 100% working while it is deployed.
One solution is to have your assets in a separate running project, since there is no easy way to have them available as all times as #developercorey explains..
It's probably not the best solution, but would be a simple patch-solution which is not tightly coupled to one particular hosting platform.
I fixed this issue, and it works now. I will explain what I did, maybe it will help somebody.
Basically there is need to precompile your assets locally, and commit and push them. This is done byrake assets:precompile RAILS_ENV=production
But there is a gotcha!!! Locally precompiled assets doesn't match those that are generated on Openshift. How is this possible? There is a bug on Openshift, that assets are generated on production with RAILS_ENV=development :/ More info here:
https://github.com/openshift/origin-community-cartridges/issues/8
so there is need to add environmental variable on your application:
rhc set-env RAILS_ENV=production -a app_name
then generated assets match.
So after fixing it, when during changes to assets, we need to precompile them again. And to make them work during hot deploying there is need to have both old precompiled assets and new precompiled assets in repo. For example:
If you have old file:
application-10770925dc8abd4ceab34119af4032163cc5a94f3523d60d321f33a999171d58.cssand new precoimpiled file:
application-82f6fca47056cbda52cb32086051f031b880e2630a137f0e41e96cb2eef923ee.css
they both have to be in repository. During hot deploying old asset is still referenced, so it has to be in repository. After hot deploying ends, new asset is referenced. In the next commit and push old asset may be removed.
So basically this issue is fixed for me, and hot deploying works fine now.
I have some images (svg) in my app/assets/images folder. According to the Rails Guides, all the files in the assets folder should be automatically precompiled.
However, when I reference the the image using image_tag('filename'), it shows me an Sprockets::Rails::Helper::AssetNotPrecompiled error
Asset was not declared to be precompiled in production.
It tells me to declare the file to be precompiled manually, but why should that be necessary? On top of that, why does it concern itself with the production environment when I am doing everything in development?
If you added the image after you've started the server in development, restart the server. Sprockets will then precompile that image and the error will go away.
I'm pretty sure Rails doesn't support .svg yet, hence why it would ignore it.
You'll need to include the file extensions in your config/application.rb file:
#config/application.rb
config.assets.precompile += %w(.svg)
In regards the application concerning itself with the production environment, you have to remember that the precompilation process is meant for production:
The first feature of the pipeline is to concatenate assets, which can reduce the number of requests that a 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.
Concantenating assets essentially means to compile your asset files into a single file, which is typically then minified.
--
Although this can be done in real-time, it's mostly the realm of static assets (which have to be precompiled). This means that if you run the rake asstes:precompile task, it will work on the development environment, unless you call RAILS_ENV=production rake assets:precompile (which sets it to the production environment for that request.
why does it concern itself with the production environment when I am doing everything in development
The application is going to run in production, not development.
Ultimately, everything you do in development should make it easier / better to work in production. In the sense of your assets, it means that you can use many of the quirks of Rails' asset pipeline, from sprockets to preprocessors such as SASS & Coffeescript
It's probably because you didn't specify the complete image name. I ran into this problem after updating the gem too. Before I just used image_tag 'some-image', but it seems that you now have to specify what type of image/extension you want to use.
Try this: image_tag 'some-image.svg'. It worked for me.
Cheers.
I have the option to precompile my assets locally in development or on my production server. I deploy with git, so I'd prefer not to have to check in all these assets (especially if they're using cache-busting digests).
Is there any advantage to precompiling assets locally (other than lacking write-access on the production machine)?
Your site doesn't need to be down when you precompile assets. If you use capistrano or similar tools, you precompile the assets in the server, then (after this and more steps have been completed) restart the app. Meanwhile the app is being served from the old code (and assets).
On the other side, I disagree about the "cache-busting" comment. Git is smart enough to understand a diff between two differently named files if possible. So the result would be exactly the same whether the names changed or not. In which case I completely agree that it's nonsensical to load the repository with generated data, like compiled assets.
I've found that compiling assets locally is much faster and then your site is down for a shorter period.
Of course, that depends on your server setup etc...
In rails 3.1, when you precompile the assets, rails create public/assets directory and add files there.
Do you version-control public/assets/*?
I use Capistrano to deploy. The last step is compiling the assets. Nothing like that gets checked into version control.
https://github.com/capistrano/capistrano/wiki/Documentation-v2.x
Checking in compiled assets, .gz files/etc, will just clutter up version control.
I was looking for an answer to this too. I found the official Rails Guide has some thoughts on this:
http://guides.rubyonrails.org/asset_pipeline.html#local-precompilation
Here's a quote of the relevant section (emphasis added):
There are several reasons why you might want to precompile your assets locally. Among them are:
You may not have write access to your production file system.
You may be deploying to more than one server, and want to avoid duplication of work.
You may be doing frequent deploys that do not include asset changes.
Local compilation allows you to commit the compiled files into source control, and deploy as normal.
There are three caveats:
You must not run the Capistrano deployment task that precompiles assets.
You must ensure any necessary compressors or minifiers are available on your development system.
You must change the following application configuration setting:
In config/environments/development.rb, place the following line:
config.assets.prefix = "/dev-assets"
The prefix change makes Sprockets use a different URL for serving assets in development mode, and pass all requests to Sprockets. The prefix is still set to /assets in the production environment. Without this change, the application would serve the precompiled assets from /assets in development, and you would not see any local changes until you compile assets again.
In practice, this will allow you to precompile locally, have those files in your working tree, and commit those files to source control when needed. Development mode will work as expected.
So, it looks like it might be a good idea to put precompiled assets into VCS on occasion.