To prevent conflicts in the Drupal.settings namespace the javascript settings added should be wrapped in another variable, using usually the module name in camelCase.
See API doc.

This will avoid as well to do the hacky test if (isNaN(m)) in ip_geoloc_gmap_multi_loc.js. And it will make alteration by other modules (through hook_js_alter()) easier.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gabriel.achille created an issue. See original summary.

gabriel.achille’s picture

Here is my suggested patch for that.
Note: In the end I did not replace the hacky test if (isNaN(m))... because it has other purposes ;)

Tested ok with a view "Map (Google API, via IPGV&M)" but it need other tests for different usages.

RdeBoer’s picture

Thanks for this. So where is the conflict exactly?

gabriel.achille’s picture

Actually they were no conflicts... yet. But in the (unlikely) situation where we are using a submodule called ip_geoloc_locations, and that this module is adding setting, wrapped in a variable using the same name, then there will be a conflict, overriding of setting variables.
API doc says:

All modules should wrap their actual configuration settings in another variable to prevent conflicts in the Drupal.settings namespace.

In my situation I needed to override some of the ip_geoloc settings with hook_js_alter (to alter gmap styles) and it was hard to target safely ip_geoloc settings in the javascript['settings'] object.

I think ideally we should as well remove the ip_geoloc_ prefix in all settings variable of this module because it will become useless with the proper wrapping variable.

RdeBoer’s picture

Yep point taken.