This patch adds support for the Domain Access module, specifically setting a map API key per domain.

For more information, see #233054: domain specific keys e.g. Google Maps, recaptcha etc and http://therickards.com/api/function/hook_domainconf/Domain.

This patch is untested; I basically just copied-&-pasted the code that outputs the default map API key fields into the hook_domainconf() function. Reviews required.

CommentFileSizeAuthor
#3 openlayers-570236-3.patch3.68 KBAnonymous (not verified)
openlayers_domain-access.patch3.77 KBAnonymous (not verified)

Comments

zzolo’s picture

zzolo commented
Title: Support Domain Access module » Support Domain Access module for Layers Keys

At first glance, this patch looks good, but I don't necessarily have time to test this out (installing Domain Access and the such). If someone can actually test out this patch, I would be happy to put this in.

I think our plans for 6-2.x will conflict with this, but we can address it later.

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs review » Needs work

Doesn't work. Looking into it...

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs work » Needs review
StatusFileSize
new openlayers-570236-3.patch3.68 KB

Ok, this one works. I was adding it to the .inc file but apparently you have to add it to the .module file.

If no one else wants to test this you can just commit, it's working for me.

zzolo’s picture

zzolo commented
Title: Support Domain Access module for Layers Keys » Support Domain Access module for Layers Keys and Main Settings
Status: Needs review » Fixed

http://drupal.org/user/147331

I actually did not use your patch. I abstracted the form elements form the admin page, and re-used them properly. I also did the same thing with main openlayers module and the main settings. Also, updating project page.

BWPanda, if you are able, please test this out. Thanks.

zzolo’s picture

zzolo commented
Title: Support Domain Access module for Layers Keys and Main Settings » 2.x Port: Support Domain Access module for Layers Keys and Main Settings
Category: feature » task

Needs to be ported to 2.x. Note how we are changing how we are doing layers, so not sure if that part will apply.

phayes’s picture

phayes commented
Version: 6.x-1.x-dev » 6.x-2.x-dev
phayes’s picture

phayes commented
Status: Fixed » Active
Anonymous’s picture

Anonymous (not verified) commented

I haven't tested the code yet, but I wouldn't imagine you'd need to have separate settings for each domain...

The only reason we needed to support the domain module was because the API keys (for Google at least) only apply to a specific domain. We therefore need a different API key for each domain, but I don't think we need different settings as well...

zzolo’s picture

zzolo commented

Well, I don't see how it could hurt anything. It's all ust setting variables anyway, and if a site is using domain and has different variable tables, then it could be useful. Thanks.

Anonymous’s picture

Anonymous (not verified) commented

Well, I don't see how it could hurt anything.

I still haven't tested yet, but I figure this would work one of two ways:

1: Users configure the main settings which are applied to all domains. Users can then change the domain-specific settings on any of their domains thereafter.

2: Settings aren't applied to all domains and so users have to configure the settings for each domain separately.

If it turns out that it works the 2nd way, this could be a problem as I currently have about 30 domains (and am constantly adding more) and I've heard there are users out there with hundreds of domains. Having to configure each domain separately would be a pain...
If it turns out the 1st way, that should be fine.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs work

Ok, I've tested this out and have some thoughts...

- Get rid of the 'OpenLayers Source' and 'OpenLayers Debug Options' settings. As Domain Access only uses the one database and directory structure, the OpenLayers library will be the same for each domain, no point having it configurable per domain...
As for the debug options, if someone's wanting to test the output, they'd probably want to test across all domains. Getting rid of this setting saves them having to enable it for each domain (since it's generally only a temporary setting anyway).

- I suppose I can see the value in having a per-domain setting for the 'OpenLayers Default Preset', but if you're going to keep it there I'd highly recommend adding another (default) option being 'Use primary domain settings'. This would mean users don't have to update all their domains when they want to change the preset to something else.
All the other select lists have this option (provided by the Domain module itself), so it shouldn't be too hard to add in...

- Wrap all OpenLayers settings in a common fieldgroup for a nicer layout (the settings I mentioned above are currently just sitting on the page and it's unclear they relate to OpenLayers).

Other than that, looks good :)

BTW, I wasn't sure whether to set this back to 6.x-1.x-dev or not... I'll let you mark this issue as appropriate.

Anonymous’s picture

Anonymous (not verified) commented

Any update on this?

I also had the thought that we should add support for batch editing. Domain Access allows for exposing your setting to their batch editing screen, this'll make it easier to add API keys to each domain all on one screen.

tmcw’s picture

tmcw commented

I've changed the layout of API keys in 2.x, so that they can be supported by contrib modules and are cleanly built into the ctools plugin architecture instead of hardcoded into the module. If you enable a new module that provides a layer with API keys required, it can add its form to that page. However, here it seems like spaces enables us to support multi-domain sites in a much more clean fashion than Domain Access and has similar levels of adoption.

tmcw’s picture

tmcw commented
Status: Needs work » Closed (works as designed)

I've removed domain access integration in 2.x, since it isn't going to blend with the ctools/per layer settings concept, and because spaces does its job without required integration.