Domain Access and Google Client Geocoder working together
| Project: | Domain Access |
| Version: | 5.x-1.1 |
| Component: | - Domain Conf |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
I have setup a Drupal installation using the Domain Access module to allow the sharing of content between domains. Until today everything worked perfectly. Today I decided to try out the Google Client Geocoder (GCG) module. The problem I am having is that in order for the GCG module to work, the Google Maps API Key must be set, and it is different for each domain. The Google Key is being saved in the variable table. I tried to prefix the variable table, but I started having problems with the cache. This led me to prefix the cash tables which was even worse than just prefixing the variable table. I have reverted the prefixing and am now looking for a way to get this working. Anyone have any ideas? I have a bad feeling this cannot be done without an enhancement to the Domain Access module.
Clarke
#1
We just had this discussion over here : http://drupal.org/node/150100#comment-777065
The Domain Configuration module allows the dynamic alteration of variables in order to address this issue.
If you use Domain Configuration, you need a hook_domainconf() function specific to the Google API keys. See the API documentation provided with the module.
If you do not use Domain Conf, see http://drupal.org/node/150100#comment-775278 for an alternative solution.
See also http://drupal.org/node/233054
#2
Awesome, thanks for the speedy reply. I see the example code in the other thread, but I am not sure which file would I be adding to.
#3
You would have to either:
-- Create a new module file.
-- Add the code to domain_conf.module [not recommended -- can cause upgrade problems]
-- Add the code to gcg.module [not recommended -- can cause upgrade problems]
-- Add the code to settings.php [not the best idea]
The best solution is to offer a patch to the original module, as in the example above.
Alternately, we could change domain_conf.module to look for a new file that would not be included in the download but that you could create in order to add such things.
If you'd like to try that, here is some code to add to domain_conf.module, lines 29--:
<?php$items[] = array(
'title' => t('Domain site settings'),
'path' => 'admin/build/domain/conf-reset',
'access' => user_access('administer domains'),
'type' => MENU_CALLBACK,
'callback' => 'domain_conf_reset',
'callback arguments' => array(arg(4))
);
// New code is the next four lines
$extra = drupal_get_path('module', 'domain_conf') .'/domain_conf.inc';
if (file_exists($extra)) {
include_once($extra);
}
}
return $items;
?>
Then create a file called domain_conf.inc, place it inside your domain_conf directory and put the code there.
Doing this would avoid (in theory) the risk of having your custom code destroyed when updating the module to a new version.
#4
I completely agree. The last thing I want to do is cut myself off from future upgrades. Of the options, it seems as though offering a patch would benefit others most, but is it wise to have references to other modules in the domain_conf code? I am new to Drupal development and just plain dont know, but I want to (learning experience and all).
Clarke
#5
No, you put the hook_domainconf() implementation in the other module. That's how hooks work.
So the patch goes in the other module's issue queue.
Domain anticipated this issue and supplies an internal hook system to address it. Contributed modules such as Views and Pathauto do the same thing.
There is no way I can implement this hook for every module. I simply declare it and ask others to implement it. The code in #3 is a stopgap solution in case other developers will not support the hook. In the case of #3, you put the code into a file that you control, which exists outside the domain update sequence.
#6
The domain_conf.inc trick is now in 5.x.1.1. This way, you can temporarily put the hook you need into that file, while waiting for the source module to be patched.
#7
Automatically closed -- issue fixed for two weeks with no activity.