Let me start by saying I am using Ruby 2.0.0 and Rails 4.1.1
I've worked my way through the Treehouse basic RoR course; ending in a very basic version of Twitter. I have the application running just fine on my local install, but when I pushed it to Heroku it seems to be missing the files in the /public directory; namely the /assets css and javascript.
I've precompiled my assets as instructed, and verified that they area indeed showing up on my GitHub remote that is using the same branch. I was told that Heroku will not compile your assets for you.
All my routes and HTML is displaying just fine, but I cannot pull any of the files that live in the /public directory (404.html, 500.html, etc)
It feels to me like it is a permissions issue or something with the /public directory, but I haven't found a way to actually browse what files are on my Heroku instance. I've tried re-pushing several times while making small changes, and the css/js never seems to appear.
In case that you have already set:
config.serve_static_assets = true
in your config/environments/production.rb
And still not working, you can actually see the logs from your heroku app using heroku logs or heroku logs -n NUMBER_OF_DESIRED_LINES_HERE in your terminal.
Related
My Rails 5 application is behaving weirdly. The application is on heroku.
I am using the gem tinymce-rails. Recently, this gem got updated to version 5 which uses new functions. After deployment I faced an issue where one of the plugins (the link plugin) could not be loaded due to using the old syntax.
I am using chrome to open the website. For some reason the tinymce plugins javascript files are not up to date. They also don't have that fingerprinted name with the hash in the end. All other javascript files do however.
I ran heroku run rake assets:precompile; heroku run rake assets:clobber;. It was no good.
I then tried to open the website in incognito mode and found that the tinymce plugins are the up to date ones. Still though without the fingerprinted file names.
How can I force that the old plugin javascript files be invalidated? I will not have control over my users to ask them to clear their caches.
How can I force using the fingerprinted files? I have inspected the heroku server file system and found assets/tinymce/plugins/link
having both fingerprinted and non-fingerprinted files however the non fingerprinted files were the ones used.
After following this tutorial, I tried was able to set up a rails application on an ec2 Ubuntu instance, running nginx web server and puma app server, deployed with capistrano 3. However, none of my assets are showing up, and I'm getting routing errors for basic functions of the Devise gem such as logging out. The chrome dev tool console shows 404 errors for the compiled application.css and application.js files.
I think the assets are there because if I ssh into the instance and go to the folder where my app is, I can see a bunch of files under public/assets. Also, if I check the capistrano logs, I can find the line bundle exec rake assets:precompile, and the status for that is successful. I tried things like going into the production.rb file and changing config.serve_static_files = ENV['RAILS_SERVE_STATIC_FILES'].present? to config.serve_static_files = true
but still no assets. I think the biggest suspect is that there is some sort of routing error, because I don't really understand how web servers, app servers, and aws instances interact with each other. Could anyone point me in the right direction on debugging this? If you need to see a specific config file please comment below.
Ok it turns out all I had to do is copy the secrets.yml from the local repo for my app to the shared folder that is in [my_app_name]/shared/config. So my app didn't know where to look for the secret key base.
Although I'm still confused on why not having the secret.yml would prevent assets from served...
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 face a problem with a rails (3.2.6) application on our production server (nginx + passenger 3). After a
rake assets:precompile
one static page works like a charm but after a few minutes I receive an asset not found error for an existing image. If I recompile the assets again it works but a few minutes later rails raise the file-not-found error again.
Here you can see production.rb and Gemfile: https://gist.github.com/3937589
Is there any way that your code is doing any manipulation of the /public folder?
Have you verified that the asset in question is indeed in the /public folder?
Are there cron jobs or other processes at work that maybe interfere with your file system?
What the assets:precompile does is simply work through your app/assets and copies these over to /public/assets.
It does so normally in 3 favors: uncompressed original file, original-file + hash that gets used when referenced from a helper (asset_path) and the gzipped file.
You can simply go to your production server and look into /public/assets to verify if anything is missing. If the file is there and the user still gets errors I'd look at my nginx configuration.
The problem in a nutshell is that in development mode we'd make changes to CSS or JS files but would always get cached/old versions of these files. Nothing I did had any effect. I checked configuration dozens of times and tried every combination of config values but always kept getting the same results: stale/cached files. I had to actually run in production mode and restart the server after every change to test.
I spent days tearing my hair out over this issue, looked at dozens of stackoverflow questions on the asset pipeline but never found one that addressed it so I thought I'd post it here for posterity.
We use Heroku and precompile our assets because Heroku fails to precompile for us (we also use devise which apparently is the cause of the heroku precompilation failure). So in order to push our precompiled assets up to Heroku we have to check them in to git.
Here's the problem.
When we upgraded to Rails 3.1.1 asset precompilation produced files both with and without the MD5 hash in the name. I didn't think much of this and went ahead and checked all these files in so I could push to heroku. Sometime later I noticed the problem with cached results in development mode. The precompiled and checked in assets without the MD5 hashes were being served from /public/assets as static files which prevented us from seeing any changes we were making in /app/assets.
After finally realizing this I ran git rm /public/assets and everything works again. So the takeaway is: Be careful checking assets into git!
To turn this into a question: how do others do this? Am I missing something obvious? What I'd really like is for Heroku to precompile my assets for me but it is failing with a db connection error that I gather is because of devise. I had hoped Rails 3.1.1 fixed this but it didn't.
Have you checked out this devise issue on github? Specifically Jose Valim says
Rails 3.1.1 final has a method called
config.assets.initialize_on_precompile. If you set it to false, you
should be good but it won't allow you to access model information on
your assets (which you probably shouldn't anyway).
Maybe this will allow the precompile to happen on Heroku for you.
The reason the asset precompilation does not work could well be, that the Heroku ENV vars are not present on slug compilation (deploy) as stated here:
http://devcenter.heroku.com/articles/rails31_heroku_cedar
There is an (experimental) way to enable the ENV vars during deploy for exactly this reason, find information here:
http://devcenter.heroku.com/articles/labs-user-env-compile
Hope this helps.
Check this guide from Heroku. It outlines the 3 ways to deploy Rails 3.1 apps. Two of these do not required local precompilation.