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.
Related
I am trying to add a Shipping Method to my install (first time adding a shipping method). When I visit this form (admin/shipping_methods/new), there are no shipping calculators available under the Calculator drop down. From the documentation, Spree ships with 5 calculators by default, yet there are none available.
I am using Spree 2-4-stable. I have browsed the repo and sure enough, the calculators are there. I have also researched the controller to see where the call is made to build the calculator array. The code within the controller is:
...
#calculators = ShippingMethod.calculators.sort_by(&:name)
...
This returns an empty array, hence why no calculators are showing up.
I have tried to pull a list of calculators myself in other areas with no luck.
# Returns an empty array as well
#calculators = Spree::ShippingMethod.calculators
The odd thing is, if I run rails console within my directory and once initialized run
# Returns the 5 default calculators
calculators = Spree::ShippingMethod.calculators
Naturally, I am confused. Does rails console pull from a different source? How is it I can pull the data from the console, but not the application. No errors, just an empty array from within the application.
This prevents me from adding a shipping method, which prevents me from completing my setup.
Any thoughts?
I would consider this more of a hack than an "answer", but either way, it's a solution.
I finally decided to just create my own Shipping Calculator by simply cloning one of the Spree defaults and renaming it. I followed the documentation for creating a custom Shipping Calculator. Once I copied the class and renamed, I added it via the config methods stated.
Upon adding the config statement, all of the default shipping calculators started to appear! As if to create another bug, my custom calculator was no where to be found however. I decided to remove the config line adding my calculator, but left the initial config line which kept the default calculators working.
So, while I am sure this is a bug of some sort, the solution was to add the following line at the bottom of config/initializers/spree.rb
config = Rails.application.config
Restarted the server and boom! Calculators available for selection now.
UPDATE:
Just to test, I removed the config line from the file and deleted my custom Shipping Calculator from the directory to see if it would break the Shipping Calculators again. Oddly enough, they still work. Perhaps loading the config using the method above saved a state in the system allowing it to continue functioning.
Either way, I hope someone else out there can provide some light on the issue.
I'm struggling with an issue for which I can't find an explanation. I have two development environments that I use for my projects. I created a simple module for Magento and I tested it on one environment. After overcoming all Magento's complications, the module works as expected. This is on XAMPP.
I then copied the module to the development Linux environment, on a hosted server, and it crashes miserably. I did some debugging, and I found out that a call to Mage::getModel() returns bool(false) instead of the instance of the Model I requested.
I double checked all files and directories, and they match. Database is not involved (not from my side, at least, I don't need tables) and both environments have only me as a User, with Admin permissions.
Any suggestion on where should I start looking is welcome, thanks.
Added on 2012/07/09
Model contains a class named Diego_ClientCustomModule_Model_ExternalUserData, which is invoked with $model = Mage::getModel('clientcustommodule/externaluserdata');. Model file resides in Diego_ClientCustomModule\code\local\Diego\ClientCustomModule\Model\. The curious thing is:
If model file is named Externaluserdata.php, it works.
If model file is named ExternalUserData.php (i.e. it matches the class name), it doesn't work.
I'm aware of case sensitivity stuff etc, but, if the alias is all lower-case, how comes it can load a file having the first letter capitalized?
Configuration file
0.1.0
Diego_ClientCustomModule_Helper
Diego_ClientCustomModule_Model
Diego_ClientCustomModule_Block
standard
Diego_ClientCustomModule
ClientCustomModule
Snarking about the framework for which you are asking for help may not be the best strategy for receiving help.
Your issue is likely one of cache (remove var/cache folder to check) or one of improper casing. Note that the first letter of each directory and filename for files loaded by the autoloader (blocks, models, and helpers).
It seems I have found the root cause of the issue, although I can't figure out what kind of logic has been implemented to make it happen.
Model's file name was UserCustomModule.php, which reflected the class name UserCustomModule. That made sense, and worked wonderfully in XAMPP. Once I installed the same module on a Linux box, Magento silently ignored the file and, as previously stated, there's been no way to track down Magento's actions.
Following benmark suggestion, I went through all the files again to check the casing, and everything seemed to match. I then made something, in my opinion, completely stupid, and I renamed the Model file to Usercustommodule.php, leaving the class name untouched (after all, PHP should behave the same on both platforms, unlike the file system). Magically, the module now works! The file name looks cr*p, but it works.
This solved the problem, yet it raises more questions:
For what reason Magento has troubles loading a file with a CamelCase name? If it's Autoloading, it should simply find a file and load it. After all, it loads the Controller, the Block and everything else, and they are all in CamelCase.
Is it written anywhere that one or more files must have only the first letter capitalized? I got enough surprises already, I'd like to avoid new ones, if possible.
Thanks again for the help.
I've searched around online but can't find what I'm after. Basically, during an install, we fire off a separate executable that basically brute forces a few folders to be read/write enabled for the user group "EVERYONE".
Now, the person that wrote this never took into consideration system language. I had a call with a customer in France that kept failing installation because "EVERYONE" isn't what we would expect.
I'm after an API call to Windows that would return a security group name which would be "safe" to use in a localized environment. Essentially I'm looking to safely edit this code so instead of hardcoding in "EVERYONE", we call a function instead.
The fundamental mistake here is not so much the use of EVERYONE, but rather that the code is using names at all. Instead of using names you should use the well-known SIDs. In your case you need S-1-1-0.
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
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.