I've moved a Rails 3.2.5 app from Heroku to a VPS and while the app was working beautifully on Heroku in terms of the log drain output, unfortunately all log output on the VPS and even running locally lacks timestamps or any other tags I'd like to prepend.
After attempting to create a fresh test app and including the following one of the config/envrionments or config/application.rb I've found that it prepends the indicated tags:
config.log_tags = [:uuid, :remote_ip, lambda { |req| Time.now }]
Notwithstanding, I've tried everything I can think of so far from combing through the app gems to grepping everything for any occurrence of "log" within the config and lib folders and subfolders (such as initializers).
I don't know, if somehow the Rails logger may be disabled, how can I find this out? Or what else could be going on here? Or what should I look for precisely?... Or should I attempt to force Rails logger and, if so, where & what should I insert Rails logger reset code to find out in an attempt to isolate where during system init the problem is occurring?
I had the same issue, you probably need to use ActiveSupport::TaggedLogging.
config.logger = ActiveSupport::TaggedLogging.new(Logger.new($stdout))
Related
I'm trying to introduce dynamic_sitemaps over resources with friendly_id. The issue is the production rails (rake / rails c) doesn't see the slug method. I've try to specify it by force by specifying an attr_accessible :slug, but it doesn't help either.
$ rake sitemap:generate
Generating sitemap...
rake aborted!
undefined method `slug' for #<Article:0xa9e4d14>
The funny thing it works smoothly on the local environment, and it should not be so much different with the capistrano/rvm deployment.
The column exists in the DB and is used by the rails app itself (which works fine too).
Added: it should be tied to either the environment or the specific gem version issue, but I'm not sure which one is the trouble, and how to debug it. The same pair works good for a different project with a pretty similar libraries bundle.
As the capistrano always do the dirty work, I forgot about the RAILS_ENV environment variable - so the console and cron job tried to operate against the dev DB and obviously failed.
I am experiencing some problems with assets on production: missing ones, stuff compiled into the wrong files (javascript for "/admin" getting compiled into the frontend code and so on). Most of the assets come from engines. I want to debug and optimize this.
For that, I need to precompile, serve and fail on my development environment just like it is done on production.
I have added some lines to my config/development.rb:
config.serve_static_assets = true
config.assets.precompile += %w( store/all.js store/all.css admin/all.js admin/all.css ) # #TODO: clean up, and optimize.
config.assets.compile = false
Running this with rake RAILS_GROUPS=assets RAILS_ENV=development assets:precompile gives me all the assets and the manifest.yml in public/.
But then the server fails:
Sprockets::Helpers::RailsHelper::AssetPaths::AssetNotPrecompiledError in Spree/home#index
Showing /xxxx/app/views/spree/shared/_head.html.erb where line #13 raised:
favicon.ico isn't precompiled
favicon.ico isn't precompiled. But it is! Its there, in the public dir, in manifest.yml, and I can fetch it with the browser (or wget): http://localhost:3000/assets/favicon.ico.
NOTE Favicon is simply the first asset called. If I strip out favicon, the problem simply surfaces with the next asset, being "all.js", or, when that is stripped, "all.css", and so on. I can strip it untill "footer_bg.png", and it will then fail there. Again: the problem is not favicon, but the fact that the development environment does not see the precompiled assets at all.
What more is needed to get development asset pipeline similar to production?
EDIT: More explicit explanation that favicon is not the problem, merely a symptom.
I ended up installing an apache, passenger on localhost to troubleshoot.
Apache (could probably be any passenger-able server) because of the static asset serving.
Furthermore, on localhost I can bump the verbosity of apache in its logs very high, offering me enough debug information.
Passenger to emulate the ruby version and the gem-loading as much as possible as on production.
Running on webrick is just too different, even when emulating as close as possible, it proved too different from a production stack; which is why I could not reproduce the production problems in there,
Firing up the whole stack as if it were production allowed me to troubleshoot. Which lead me to conclude that several problems were causing the asset-woes: a gems assets not being picked up; a permission issue (compiled assets not readable by www-data) and a few assets not being compiled properly.
I think you may want to leave favicon.ico in public...
alzabo0:~ $ rails --version
Rails 3.2.3
alzabo0:~ $ rails new ojoijoijo
[...]
create public/404.html
create public/422.html
create public/500.html
create public/favicon.ico
create public/index.html
create public/robots.txt
[...]
Just a guess, but try adding to your precompile list:
config.assets.precompile += %w( store/all.js store/all.css admin/all.js admin/all.css favicon.ico)
Background
I have an app that I recently updated to Rails 3.2.1 (from Rails 3.0.x) and have refactored the JS and CSS assets to make use of the new asset pipeline. The app is hosted on Heroku with the Celadon Cedar stack.
App Config
I keep application specific configuration in a YAML file called app_config.yml and load it into a global APP_CONFIG variable using an initializer:
# config/initializers/load_app_config.rb
app_config_contents = YAML.load_file("#{Rails.root.to_s}/config/app_config.yml")
app_config_contents["default"] ||= {}
APP_CONFIG = app_config_contents["default"].merge(
app_config_contents[Rails.env] || {} ).symbolize_keys
Asset Compilation on Heroku
Heroku has support for the Rails asset pipeline built into the Cedar stack. When you push an app to Heroku it automatically calls rake assets:precompile on the server as a step in the deploy process. However it does this in a sandboxed environment without database access or normal ENV vars.
If the application is allowed to initialize normally during asset precompilation an error is thrown trying to connect to the database. This is easily solved by adding the following to the application.rb file:
# Do not load entire app when precompiling assets
config.assets.initialize_on_precompile = false
My Problem
When initialize_on_precompile = false is set, none of the initializers in config/initializers/* are run. The problem I am running into is that I need the APP_CONFIG variable to be available during asset precompilation.
How can I get load_app_config.rb to be loaded during asset compilation without initializing the entire app? Can I do something with the group parameter passed to Rails::Application.initialize! ?
Rails lets you register initializers only in certain groups, but you need to use the Railtie API:
# in config/application.rb
module AssetsInitializers
class Railtie < Rails::Railtie
initializer "assets_initializers.initialize_rails",
:group => :assets do |app|
require "#{Rails.root}/config/initializers/load_config.rb"
end
end
end
You don't need to check if AppConfig is defined since this will only run in the assets group.
And you can (and should) continue to use initialize_on_precompile = false. The load_config.rb initializer will be run when initializing the app (since it's in config/initializers) and when pre-compiling without initializing (because of the above code).
Definitely check out asset_sync on github. Or our Heroku dev centre article on Using a CDN asset Host with Rails 3.1 on Heroku.
The issues with environment variables have recently been solved by a Heroku labs plugin, that makes your application's heroku config variables accessible during compilation time. To enable this, read about the user_env_compile plugin.
Also. There is quite a big performance improvement in using asset_sync vs letting your application lazily compile assets in production or serving them precompiled directly off your app servers. However I would say that. I wrote it.
With asset_sync and S3 you can precompile assets meaning all the assets are there ready to be served on the asset host / CDN immediately
You can only require the :assets bundle in application.rb on precompile, saving memory in production
Your app servers are NEVER hit for asset requests. You can spend expensive compute time on, you know. Computing.
Best practice HTTP cache headers are all set by default
You can enable automatic gzip compression with one extra config
Here's what I came up with. In the assets that need app configuration, I place this line at the very beginning:
<% require "#{Rails.root}/config/initializers/load_config.rb" unless defined?(AppConfig) %>
... and add .erb to the file name, so that video_player.js.coffee becomes video_player.js.coffee.erb. Then I can safely use AppConfig['somekey'] afterwards.
During the asset pre-compilation, it loads app config despite the initialize_on_precompile set to false, and does it only once (which avoids constant redefinition issues).
Yes, it's a kludge, but many times nicer than embedding configs in asset files.
For Heroku I am running the Asset Sync gem to store my files on a CDN to avoid hitting Heroku for static images. It works nicely. I also have initialize on precompile false, but the Asset Sync runs it's own initializer so you could put your code in that. https://github.com/rumblelabs/asset_sync
Although your intializer is not run when the assets are precompiling, you should still find that they run as Rails boors up as normal, however, this will be on the first hit to the application rather than at the deploy step.
I'm not entirely sure what the issue you're having is, but if you follow the Rails conventions the deploy will work as expected.
I am having issues with Heroku and Haml, I am able to run my app on localhost no problems, all test pass to, however when I go to run it on Heroku I get the following error:
We're sorry, but something went wrong.
We've been notified about this issue and we'll take a look at it shortly.
I read another post on Stackoeverflow that basically said to add a .gems file and add:
haml --version '>= 2.2.0'
I did that and I'm still having the same problem, so I'm wondering what I am doing wrong.
Update: I fixed that problem had to do with cache - and Heroku being read-only however now the theme I've selected via web-app does not load up on the Heroku page it shows up on local host however correctly. I looked at the log file for Heroku and it doesn't show any errors, so is it another permission issue?
Here is the log file - https://gist.github.com/1173667
Thanks,
Looks like your stylesheets are not included as part of the layout.
Assuming your stylesheet is available as public/stylesheets/styles.css, try adding the following line inside the head tag in application.html.haml
= stylesheet_link_tag 'styles.css'
That should resolve the theming issue. If not, post the code in application.html.haml
UPDATE:
From the logs, looks like you have two layouts: layouts/sign and layout/application. If they are there for a reason, you need to address that.
Else, change your home controller to render the new layout:
class HomeController < ApplicationController
layout "sign"
end
I have a rails application I would like to use for multiple sites, each with different designs.
I would like to change the rails installation /public directory to something else (dynamically eventually). However, I have run into a problem (bug?) changing directories...
In my application.rb file I change the paths.public path to something other than "public" (let's say "site_one"). Here is the code:
puts paths.public.paths
paths.public = "site_one"
puts paths.public.paths
The two "puts" commands are for debugging. Now run "rails s" and you will see:
/home/macklin/app/public
/home/macklin/app/site_one
This verifies the path is changed correctly. However, shortly afterward, rails throws the following error (let me know if you need the full trace):
Exiting
/usr/lib/ruby/gems/1.8/gems/railties-3.0.3/lib/rails/paths.rb:16:in `method_missing': undefined method `javascripts' for #<Rails::Paths::Path:0x7f422bd76f58> (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.3/lib/action_controller/railtie.rb:47
My guess is it cannot find the javascripts directory even though it is clearly sitting in the "site_one" folder.
Does anyone know why I am getting this?
I know this question is pretty old, but I think I found an answer for this in Rails 4.2.
You just simply have to put this line in your config/application.rb:
middleware.use ::ActionDispatch::Static, "#{Rails.root}/another_public_folder_name", index: 'index', headers: config.static_cache_control
This makes all files in /another_public_folder_name to be served by Rails.
This is the way Rails use to setup the standard /public folder. I found it checking the sources:
https://github.com/rails/rails/blob/52ce6ece8c8f74064bb64e0a0b1ddd83092718e1/railties/lib/rails/application/default_middleware_stack.rb#L24
Duh. Just add 2 more rules for stylesheets and javascripts (I guess they get wiped when you change the parent path)
paths.public.stylesheets = "site_one/stylesheets"
paths.public.javascripts = "site_one/javascripts"