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.
the __construct method in class GoogleMaps always receives null values for locale, region, apiKey and useSSL always receives false. And so requests to google don't have the API key in, resulting in frequently receiving the error "Quota exceeded".
This is despite having set the config values /admin/config/system/geocoder, and seems to happen regardless of whether geocoder caching is enabled or not.
Comment | File | Size | Author |
---|---|---|---|
#4 | geocoder-8.x-2.x-2955125-4-document-how-to-add-config.diff | 557 bytes | alberto56 |
Comments
Comment #2
nicrodgersComment #3
nicrodgersApologies, seems to be an issue with search_api_location. see https://www.drupal.org/project/search_api_location/issues/2954999
Comment #4
alberto56 CreditAttribution: alberto56 at Dcycle commentedI think this should be documented in the README because currently one might assume that the configuration is being used whereas you need to pass it in manually.
This patch would have saved me a lot of head-scratching!
Comment #5
itamair CreditAttribution: itamair commentedIn the Readme.md file, under the installation and setup section it’is already stated;
“From the module configuration page it is possible to setup caching and custom
options for every available Geocoder Provider”
and it should be quite obvious that at least a Google Maps API key should be set for using Google Geocoder/Geocoding service.
How the Geocoder module might set it up for you out of the box? Google Maps API key is specific and user related.
Moreover this Drupal 8 module is relying on the Php Geocoder third party library.
Neither any specific integration with Search API location module is highlighted and might be considered expected.
Yes ok ... everything might have been better done and documented, but please consider that here we (the maintainers) are dedicating their free time, and trying to make their best accordingly.
Comment #6
itamair CreditAttribution: itamair commentedComment #7
itamair CreditAttribution: itamair commentedAnyway I am sorry ... and I DO apologize.
Now I better (and properly) get this issue matter.
I became maintainer of the Geocoder D8 module after this main API was built/setup ...
Probably in this way the Geocoder APIs do stay more agnostic and independent from the specific module settings,
...
but yes indeed the geocode and reverse methods in the Geocoder services should fetch the plugin options (at least as default values) from the correspondent Drupal configurations (geocoder.settings.plugins_options). The methods third parameter ($options) might be used as possible & manual overrides in the APIs.
In my opinion, this indeed require a better refactoring of the Geocoder Service for what concerns the geocode and reverse methods, and all the invocations to them in the module itseself (geocoder_field.module for instance). And this shouldn't be much work at all (opening a new related issue on this).
For the time being it is a good option to patch the documentation to possibly avoid further missunderstanding on this, in this meanwhile ...
Comment #9
itamair CreditAttribution: itamair commented... closing this as fixed for what concerns Readme.md documentation updated (temporary),
I opened this new related issue regarding the possible Geocode Service and APIs refactoring.
Comment #10
alberto56 CreditAttribution: alberto56 at Dcycle commentedThanks for the quick response! The module is great and very useful by the way ;)