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"
Related
Before I start, I'd like to stress that I've looked for answers and I've tried to solve the issues by myself.
I have 2 types of controllers -
A controller with a set of methods that render JSON - works perfectly
A controller that actually renders HTML
This code is working perfectly on my local machine and the problem that I have with the second controller is on my production machine.
I've added 755 permissions to all my files but my file owner is the only user on my server which is "root". I've added the files to the www-data group though.
My controller is simple.
class AdministratorController < ApplicationController
def login
end
end
And my file is views/administrator/login.html.haml.
I'm getting an error -
ActionView::MissingTemplate (Missing template administrator/login, application/login with {:locale=>[:en], :formats=>[:html], :handlers=>[:erb, :builder]}. Searched in:
* "/var/www/sitename/app/views"
):
Try to add to your Gemfile
gem 'haml-rails'
And run bundle install.
The issue has been resolved. I'm not sure what exactly went wrong with the template but I began seeing a different error relating to compiled assets. I just recompiled the assets and restarted the server. Thanks for all your help!
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))
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)
Currently working on a project where we need to drop in various static html pages + static assets for those from time to time that "just work." We cannot have anyone editing the html directly to place paths in for the assets. We need it to simply work such that the html + asset folders are placed directly into /public and the content is served up as it was generated.
When testing this behavior in production, it's a no go with errors such as:
ActionController::RoutingError (No route matches [GET] "/some_folder/some-image.png"):
I assume this is a result from what I'm reading from 3.1.x's asset pipeline.
How do you alter the routes such that these will be served up directly? Or is there a preferred way to keep this precise behavior? (Ultimately this will be deployed on heroku.)
Adding some more details as current remarks have not yet pushed my issue over the edge in terms of a solution:
In my present scenario I'm running it straight on WEBrick rails s -e production to test it out. In development mode this does work properly; the only exception is in production.
I am also running this prior to running the server:
bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile --trace
When I actually attempt to load the page in production, I see the following output:
cache: [GET /] miss
cache: [GET /test_files/index.css] miss
cache: [GET /test_files/index.js] miss
cache: [GET /test_files/logo.png] miss
cache: [GET /test_files/background.png] miss
cache: [GET /test_files/horizontal.png] miss
cache: [GET /favicon.ico] miss
Upon further scrutiny of the production.rb I am seeing: "config.serve_static_assets = true" that when set to false by default evokes the issue experienced in webrick. So when setting that to true it serves the files up properly.
From some additional reading it appears that perhaps Heroku needs this set to false as well, which is the environment to which we're deploying.
Thanks for the input, but this appears to be the approach to take for now and I'd certainly appreciate any further input if this is NOT the correct answer or if there's a better approach.
As of Rails 3.1.1 the precompile task creates non-digested as well as digested filenames, so you can refer to these in static files (while still having the digest version in dynamic files).
The only problem is if you use far-future headers on the assets directory; changes to the undigested files won't be pick up by remote clients that still have a copy and believe the cache to still be valid.
You may need to look at an approach the replaces the non-digested filenames with the correct name during the deployment process.
If you do not use far-future headers in the directory then it does not matter - you can use either name.
For me the #ylluminate's answer helped: I've changed the config.serve_static_assets option to true in the config/environments/production.rb file and restarted the server with
$rails server --environment=production
and now it serves compressed assets.
NOTE: I've also precompiled the assets with
$bundle exec rake assets:precompile
(call rake this way assure will be used the rake version choosen for the project but I guess use just rake assets:precompile will work 99% of the times)
If you have /public/some_folder/some-image.png physically present (no matter if you just copied it there manually or it was generated by assets precompile), it must work. The server (e.g. Apache) will first check if the requested path exists in public, if it does it won't even call Ruby on Rails.
As far as digested filenames are concerned there is an option to turn this feature off, but I wouldn't recommend that for reasons already mentioned by someone else here.
Also you can put files that refer to assets in the app/assets folder and add a .erb extension AT THE END. Then you can use <%= asset_path ... %> inside that file, so no manual editing will be necessary. This will work even if you already have some other preprocessing on the file, for example sass - style.css.scss.erb will work. First the erb code will be evaluated (putting in the correct filenames for assets) then the sass compiler will be ran.
Oh and have a look at the sprockets-image-compressor gem, just add it to your Gemfile and it will automagically compress image assets too (losslessly using pngcrush and jpegoptim)...I don't know if the gem is rock-solid but from what I've seen I love it!
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