[BUG] Google map API key not used

[pascalthivierge]

Describe the bug
Google API key in settings is not used when adding a Google Map.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Settings'
2. Click on 'Google API'
3. Enter your Google Place API key in the text field and save.
4. In a page, add a Google Map, add a search query, add the Google Place ID and save.
5. When looking a the live page, there is an error: "Google Maps Platform rejected your request. The provided API key is invalid".

Expected behavior
A Google map should appear.

Additional context
When looking at the encoded URL, the key parameter is None.

[wamcvey]

I looked into this a while ago and discovered that the issue (or at least an issue) is that coderedcms.models.page_models.CoderedLocationPage.save() (and .get_context() ) only uses the GoogleApiSetting associated with the default site. If the Setting is attached to a non-default site, it's not used.

For example:

coderedcms/coderedcms/models/page_models.py

Line 1794 in fa852eb

if self.auto_update_latlng and GoogleApiSettings.for_site(

I was going to write a pull request for this issue, but while the solution for the get_context() method was obvious (use the request context to find the appropriate setting), I really didn't know the right way to handle the retrieval of the setting for the save() method which lacks a request context and therefore the method doesn't really know the appropriate site to pull the setting from. A fix that addressed the API key setting in the template context but not at the underlying model save() (and therefore could result in different results) seemed wrong so I never finished the patch/pull request.

[vsalvino]

Considering the save() belongs to a Page object, each page is tied to a Site (via its chain of parent pages, all the way up to the Root page). So we should be able to get the correct site on page. It would require a bit of introspection into Wagtail's Page object.

[vsalvino]

@wamcvey I created a separate issue for the site settings problem (Issue #341) and attempted a "simple" fix (PR #342) which proved to be a more systemic issue. Please continue discussion there.