Update URLs for Google Maps

I think that is a good idea. At some point between when this module was first created and now, Google changed its map URLs. We should definitely update the module in both 8.x and 7.x.

As a note, if your site has a custom theme you can fix this yourself for your site by putting the html.twig file into your theme and editing it there.

It would help if you could put the full URLs into the issue summary or a comment (the original and the redirect) and maybe we could figure out what is happening).

Also keep in mind that Google often puts a lot of extra stuff into its URLs that are not necessary.

Also... These URLs were originally derived from going to Google Maps, finding an address, clicking on the Embed link, and figuring out what the URL was. We can probably start over and do that again, to figure out where in the URL the language and address should go.

Thanks! So it looks like the address part is staying the same, encoded as IN%2C+West+Bengal%2C+Kolkata%2C+700071%2C+Queens+Way%2C%2C+Maidan%2C+Victoria+Memorial+Hall.
We'd probably need to experiment with the other map parameters to figure them out. ... In the original, we have hl=en , t=m , z=15, which are the language (en), zoom level (15), and map type (m). In the redirect, I see 6i15 which could be the zoom level, and 1sen which could be the language? Hard to say for sure.

So my suggestion would be to put some addresses into Google Maps and click the Embed button, trying with some different zoom levels and map types, to see what the parameters would be. Check the settings for this module to see what other things we'd need to vary to cover all the settings.

That patch is getting a "failed to apply" error...

When you upload a patch, please just set the issue status to Needs Review, which will automatically launch the correct test. You should not need to manually add tests. Thanks!

I took a quick look at the latest patch. I actually think it would be better to leave the settings form as it is, and instead when you are sending data to the theme layer, translate the map types to fit the current Google URLs. That will make existing sites still work. The way you have done it, if someone updates the module to the new version, their existing configuration for the field formatter will no longer work. So you would need to have an update hook that would go through and update everyone's configuration, which is not in the patch.

Updating the variables sent to the theme is also a problem, because if someone is using a customized theme template file, it will no longer be getting the same data.

So... I'm setting the patch to needs work. We need a patch that will make it so that sites that already exist (with existing configuration and perhaps customized theme templates) will still work if they update to the new version. This patch will not work.

I think the solution is probably to leave the configuration and the theme variables the same, and have the logic of translating the old map type to the new map type be done in the theme template. That way, old templates that are outputting the old URLs with the old values will still work, old configuration will still work (without an update hook), and the new template will still be able to output the new URL.

Yes, we need to fix the deprecations. See #3088320: Make sure Simple Google Maps is fully Drupal 9 compatible for that.

The patch looks like the right approach. I haven't tested it yet, and I think it needs manual testing. Thanks very much for all your work!

One question: I think when I first made this module, I experimented with taking bits out of the URL so that I had a minimal URL to work with. You might try that with the new URL. For instance, maybe it doesn't need the language code twice: !3m1!1s{{ langcode }}!5m1!1s{{ langcode }}? I am not sure, it would require some experiments to see if it still works without some of the little bits in the URL that we don't really know what they are.

Thanks for that testing! But that may be too short -- it looks like that patch doesn't output the language code?

That looks better! We should do a bit of manual testing with various options to verify that the field formatter settings still work for zoom, language, map type, and of course the address.

Meanwhile, you can of course put the new template into your site's theme and benefit from all of your hard work on this patch, which is much appreciated!

Iʼm not sure whether I understood the purpose of this module correctly, but as far as I see, Google Maps GUI now uses exclusively &mid= (named after probably "Map ID"?) parameter is its URLs. I tried many ways but did not manage to get a URL of my map similar to these exclamation mark-separated &pb=!1m4!2m1!1s… style which weʼre compositing.

Maybe Google just changed the embedding options since the last comment here and we have to accommodate with their new rules. When I require the embed code of my map I get the following markup offered:

<iframe src="https://www.google.com/maps/d/embed?mid=1GGjVwVq2A4YFsCbQ0Al1wzGBfpRRnVtG" width="640" height="480"></iframe>

Such sophisticated options this field formatter was used to offer are nowhere mentioned by Google on the GUI anymore. Correct me if Iʼm wrong, maybe thereʼs another "Google Map" service in the overwhelming Alphabet-universe I just missed?

The original embed code for this module was derived from reverse-engineering an embed generated by searching on the Google Maps web site for an address, clicking on Share, and looking at the embed code. It was not based on a published API. The no-API-key embed may fail to work in the future (or even now?) if they are publishing the embed with a map ID and keeping track of the options behind the scenes.

The URL link was also based on reverse-engineering links from the popup share button.

The static map option in this module does used a published API, and requires a Google Maps API key and payment to Google.

Today our production pages with simple_gmap stopped working and displayed a sameorigin error:

Refused to display 'https://maps.google.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

The patch in #24 solves the issue nicely and quickly.

I'd put this to RTBC since it seems that without it the module won't work properly anymore.

What would be the #24 patch for Drupal 7 version of this module?

Adding support, agree that the patch in #24 applied works and solves the issue.

Confirming patch in #24 solved my issue too

Agreed, just tested patch #24, it solves the problem for us as well.

This URL issue used to just be a minor annoyance, but now that Google has made changes on their end, the module is entirely broken without this fix. Making adjustments to the issue to reflect the urgency here.

Patch #24 should be committed to dev right away, and a new release including this change should be tagged. It looks like the current dev branch is 8.x-1.x, while the release versions are up to 3.0.0, but I'm not sure if that has to change in order to move this forward.

Here's a patch for the 7.x version based on #24.

Confirmation that patch for Drupal 7 as described in # 36 works and solves the problem!

Hi there! Thanks everyone for reviewing these patches.

I'm sorry but I'm not able to make the commit/release for about a week (away from office). Possibly the module co-maintainer for Drupal 8+ can take care of it before that.

Thanks for letting us know @jhodgdon! I messaged Martin directly to ask him if he could take care of it soon.

Thanks everyone who participated in this issue by creating and testing patches, as well as discussing the issue and how to fix it! And thanks for your patience. There are now a new 8.x/9.x and 7.x releases available on the project page, with this fix included.