Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#2 | ip_geoloc-wrap_js_settings-2606780-2.patch | 12.85 KB | gabriel.achille |
Comments
Comment #2
gabriel.achille CreditAttribution: gabriel.achille at Demonz Media commentedHere 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.
Comment #3
RdeBoerThanks for this. So where is the conflict exactly?
Comment #4
gabriel.achille CreditAttribution: gabriel.achille at Demonz Media commentedActually 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:
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.
Comment #5
RdeBoerYep point taken.