Due to circumstances beyond my control, my production Camping site appears at mysite.example.com/mysite. I'm pretty sure this is a common Apache / Passenger configuration issue, and I'm not interested in how to fix it right now because the server is out of my control. Suffice to say, the controller for "/" points there and I can't change that any time soon.
Now, for a long time, this wasn't an issue, because R(MyIndexController) points to the correct place. However, I serve my site's CSS using a Rack::Static call to make $SITE_ROOT/public accessible. This means that the stylesheet is at mysite.example.com/mysite/css/style.css. Here's where the problem comes in: the Camping URL() method, when called in my layout, gives http://mysite.example.com, not http://mysite.example.com/mysite. So I can't get it to point to the /css subdirectory, because it's missing a "hop" in the middle. When I run rackup locally, everything is fine (because this file is at localhost:8080/css/style.css), but on the production server I don't know how to fix it.
My question: is there another method (maybe directly from Rack?) that I should be calling instead? I really want to avoid hardcoding it, and/or having a hack to determine whether I'm running locally (for debug) or in production, for every rendering of the layout.
ETA: OK, this gets stranger. Obviously I've abstracted out some of the actual details above, part of which I think I "over-scrubbed". The "top level" URL is actually more akin to /mysite/rest (the developer-centric HTML presentation of our RESTful interface), as opposed to /mysite/management (accounts) or /mysite/ui (JQuery'd / "nice" UI). These are set up in our config.ru, via run Rack::URLMap.new(Hash['/rest' => RestModule, '/ui' => PrettyInterfaceModule, '/management' => UserManagerModule], etc.
So in answer to the comment below, R(Index), from a view in the RestModule, actually returns /mysite/rest/. As an example, I have a "home" link in the layout, which looks like a :href=>R(Index), and generates code that looks like <a href="/mysite/rest/">. The server is configured to serve files from ./public directly at the "site root", so ./public/css/style.css actually does apppear at http://mysite.example.com/mysite/css/style.css, as noted previously. It's that link that I'm having trouble automatically generating, and it's because of the Rack::URLMap that I thought I may have to rely on a native Rack method (not a Camping abstraction) to locate this resource.
So in this case, URL() actually returns http://mysite.example.com/mysite/rest/?
What about something like this?
URL().merge('../css/style.css')
This is an old question so I assume that you did already find a workaround but the new passenger + apache (or ngnix) behaves correctly for camping as far as I could replicate. Your app would be on the Documents root and all the includes in the /public folder so /public/css should be routed correctly regardless of you using a sub folder /mysite or not as passenger doesn't make a difference (again) as far as I can replicate. Therefore this should be easily solvable with passenger 3 + Apache or ngnix.
Related
Please can someone point me in the right direction for what I'm sure is a simple problem, but is causing me to go round in circles.I have three domains
.com
.com.au
.co.nz
I'm trying to keep a single code base for maintenance.
I've done some manual localisation work to change titles, contact details etc based on the url, using request.original_url and stripping out the relevant parts and setting some constants in the application controller (SITE, EMAIL, TELEPHONE etc).
It all works fine, except for my config.action_mailer.smtp_settings in the production.rb.
These obviously should change so the localised email account is used (info#...com or .com.au etc) but
I can't get the constants to be initialised before the environment is loaded. It makes perfect sense why it's not working, but I have no idea how to fix it.
I've tried putting it in initializers, the application.rb and setting it in the production.rb itself. If I move the code anywhere out of the application controller I get a no method error on request.original_url.
Is there a way of pulling out mailer settings so they can be exposed to variables? Or is the production.rb loaded at app start up and after that is unaffected by the end user.
Also, even though the language is remaining the same should I look at i18n for manipulating the site for these features? or is it not worth the effort for the few variables I want to change.
Thanks in advance.
You can just change settings in runtime:
ActionMailer::Base.smtp_settings[:host] = 'yourhostfromrequest'
You could just change the constants in your mailers, since constants in Ruby are mutable.
I'm having a problem with a specific function in a CFC being cached, no matter what I do.
Here's the scenario:
The CFC is instantiated in the Application scope, via ColdSpring. The site is live and all is well.
I wanted to make a change to one of the functions, called 'productSearch' within this CFC.
No matter what I do, no change is respected, ever.
I usually restart the application to reinstantiate the CFC, but this has made no difference.
I've tried creating a test page and explicitly instantiating the CFC locally, but it makes no difference.
I've restarted Railo, restarted Tomcat, restarted the server, to no avail.
In fact, the only time that I can see the change I've made, is if I literally rename the function. The fact that this works suggests that the CFC file itself is not being cached, otherwise the newly named function would not be available.
What's more, this only happens on the production server. If I make the exact same change on my dev server, everything works as expected.
I've never seen this before and I'm at a bit of a loss.
I really don't have much code to show that would be of any use - for testing, the function now contains the following:
<cffunction name="productSearch" access="public">
<cfdump var="#CGI#">
<cfabort>
</cffunction>
This fails, but if I rename it to 'productSearch2' it works correctly. For clarification, when I say 'fails' I mean runs the function as if it hadn't changed at all - there was all manner of logic in it before, returning a struct.
Does Railo store a parsed version of CFCs anywhere or something? I just can't see how this is happening!
Turns out this issue was down to a methodology I'm using in my code...
I split my components down into manageable .cfm files, which I then include using DirectoryList and CFInclude from inside a base .cfc file
This works very well for me, however in this instance, a recent merge of dev and live versions of the file in question left me with a .orig file - and as my files are included using DirectoryList, it seems the .orig was being included in the component after the .cfm version was loaded - thus overwriting any functions that exist within both files. This is why renaming the function worked!
I was hoping to make a Rails app usable both as an Engine and as a standalone Application.
Specifically, I have a nascent app which I'd like to plug in to a customer's site, but ideally, I'd like to just as easily use the app as a standalone system. However, if config/environments/*.rb exist in the enginified version of my app, I get an Uninitialized Constant error at the time the app that I'm having take a dependency on my engine starts up; Rails complains that the MyEngineModule::Application constant can't be found in development.rb, which I think is simply a load order issue, since this does NOT occur when I run the app standalone. If I delete development.rb, the original initializers that reference my MyEngineModule::Application complain, so then I tried to delete those, and all is well.
Great, except that the original app doesn't work, since its configuration is gone.
Is there some tweak I can make to the initialization load order (or load paths, in the Engine < Rails::Engine class definition) that would prevent the original configs and initializers from being loaded when in an engine context, and allow me to leave them in place for the app context?
The simpler answer is probably this, but I'm feeling stubborn, and would like to know what it would take to make my original goal possible:
extract the code for MyEngine into an engine, remove the config/environments/* files and config/initializers/* files, and make the client app depend on this.
Make a "new" minimalist app depend on MyEngine, and move the environment files and initializers to NewApp.
Assuming I feel some unnatural compulsion to keep my original application runnable as it was, if I want to prevent the "engine" from loading the "application" configuration, what's the best way to handle that? I presume this is only really a problem during development, because I can prevent the environments/*.rb files from being pulled into the gem itself, but I like being able to test locally while I'm developing the engine and its client app.
Continuing my tradition of answering my own esoteric questions, it seems like one passable alternative is to include a guard clause in the engine's environments/*.rb and the initializers that goes something like this:
if defined? CuteEngine::Application
CuteEngine::Application.configure do
config.whatever = something
end
end
This gets around the problem of having two Rails::Application objects at a relatively small cost. Not very happy about it, but I'll live.
Bumping this for new comers.
Rails 3.1 comes with mountable engines, which sounds like exactly what you are describing. The docs aren't great for converting existing code, but it looks like this will do what you want:
module CuteEngine
class Engine < ::Rails::Engine
isolate_namespace CuteEngine
end
end
In your other app's routes.rb file, you'll add:
mount CuteEngine::Engine, at: "/cuteness"
http://edgeguides.rubyonrails.org/engines.html#mounting-the-engine
http://railscasts.com/episodes/277-mountable-engines
In an MVC framework, I have a model with an "identifier" field. This field can be whatever is used by the user as their unique identifier. I then use this identifier field in URLs to access the relevant resources.
/people/<identifier>/
In one such case, the user is using identifiers of the format 00/000. The quick among you will have spotted the problem straight away - how do we know which part is the identifier, and which part the action?
The obvious solution is to use URL escaping (%2F being the relevant code). However, this confuses my apache load balancing proxy as well as the application server on our demo box (running passenger). Although annoyingly this works fine on the local development servers. URLs including %2F seem to cause 404 errors from the server (not the application!).
What i'm looking for is a general approach to solving this problem, while keeping a tidy URL.
The stack which caused this problem is: Ruby 1.8.7, Merb 1.0.12, Apache load balancing to a thin cluster on production, Passenger on the demo server, and working with unproxied thin on development.
The cleanest way would be to prevent the user from entering in a forward slash character in the first place. If it is necessary to support this format, then there is no way around having to use URL escaping.
You could always use a home-grown encoding that replaces / with some other character that is never used in your identify field and then converts it back when reading it from the URL.
For example:
http://yoursite/people/00/000
becomes
http://yoursite/people/00-000
Whenever two concurrent HTTP requests go to my Rails app, the second always returns the following error:
A copy of ApplicationController has been removed from the module tree but is still active!
From there it gives an unhelpful stack trace to the effect of "we went through the standard server stuff, ran your first before_filter on ApplicationController (and I checked; it's just whichever filter runs first)", then offers the following:
/home/matchu/rails/torch/vendor/rails/activesupport/lib/active_support/dependencies.rb:414:in
`load_missing_constant'
/home/matchu/rails/torch/vendor/rails/activesupport/lib/active_support/dependencies.rb:96:in
`const_missing'
which I'm assuming is a generic response and doesn't really say much.
Google seems to tell me that people developing Rails Engines will encounter this, but I don't do that. All I've done is upgrade my Rails app from 2.2 (2.1?) to 2.3.
What are some possible causes for this error, and how can I go about tracking down what's really going on? I know this question is vague, so would any other information be helpful?
More importantly: I tried doing a test run in a "production" environment just now, and the error doesn't seem to persist. Does this only affect development, then, and need I not worry too much?
This is a bug in Rails 2.3.3:
https://rails.lighthouseapp.com/projects/8994/tickets/2948-exception-a-copy-of-actorscontroller-has-been-removed-from-the-module-tree-but-is-still-active
There is a patch for it (but incomplete?) in 2-3-stable:
http://github.com/rails/rails/commit/d37ac7958fc88fdbf37a8948102f6b4e45c530b3
You have a few options to address the problem:
Revert to Rails 2.3.2, wait for 2.3.4 to come out, probably at the end of August. 2.3.3 has a couple bad issues, so that might be best.
The problem should not happen in production mode, nor will it happen in development mode under the Thin server. If you are having this issue on Google Engines in production mode, the patch is your only hope. If it's only in dev mode, you can just run your local server with Thin instead of Mongrel.
If it is Google Engines, you can move off of Google Engines and host your app another way. This seems like a lot of work though.
Best of luck, this is a really bad bug many people are running into.
I addition to the workarounds mentioned in the other answers, I have encountered two others:
Add "config.cache_classes = false" to your config/environments/development.rb file. This has the unfortunate side effect of requiring you to restart your server whenever you want to see your changes.
Add 'unloadable' inside your controller classes in your engine. See http://strd6.com/?p=250 and http://dev.rubyonrails.org/ticket/6001
I haven't tried the second approach, since I found the other solution first, but there is of course a trade-off between avoiding having to edit plugin code, which may be reverted if a newer version of the plugin is downloaded, and then the ease of development provided by not having to restart the development server all the time in the second solution.
i faced with same problem for my new engine on rails 2.3.4 and i found solution here.
calling unloadable method solved my problem.
Weird.
Trying running "rake rails:update" to make sure the configs are scripts are up to date. You may have to check the existing ones against a template application.
i had this error and from memory it was one of one of these three things that fixed it.
1) I needed to update mongrel/rack
2) I had an environment variable from restful authentication that i had moved into the production.rb and development.rb files from the environment.rb - shifting it back to environment.rb seemed to help
3) will_paginate was out of date
We called out to an activerecord model in a namespaced module which overrides the "name" class method. Rails expects that the name method returns Product::Categories::MilkProducts::Firstproduct but gets just Firstproduct and throws an error. So if you get this error first check if you redefined self.name.
Firstproduct.method(:name).owner should be Module
Firstproduct.method(:name).source_location
source:
module Product::Categories::MilkProducts
class Base
def self.name
self.to_s.demodulize
end
end
class Firstproduct < Base
self.product = Product.first
end
end