Google Maps API version 3.26 retired breaking site

+1 for the quick patch.

Nowadays v3.8 is the current [stable] "release." v3.7 is "frozen", and v3.9 is the current "experimental". So this version string train will need to keep moving.

Note: Omitting the minor version number will always use Google's stable version, if you don't want to keep changing version strings.

With what @Chris Charlton said in #5, I recommend altering the patch as follows:

diff --git a/ip_geoloc.module b/ip_geoloc.module
index bfd8f53..234f249 100644
--- a/ip_geoloc.module
+++ b/ip_geoloc.module
@@ -1016,7 +1016,7 @@ function ip_geoloc_build_google_api_url() {
   // Add query params to API url.
   if (!empty($query)) {
     // Include version number as it's required for Premium plans.
-    $query['v'] = '3.26';
+    $query['v'] = '3'; // Was: '3.27'. Use the major version only, and Google will automatically serve the latest stable minor version of the v3 API.
     $google_api_url .= '?' . drupal_http_build_query($query);
   }
   return $google_api_url;

The comment I added should probably be amended or removed. That was for clarification here only.

I just did this manually and it works fine. The RetiredVersion warning error no longer appears in Developer Tools Console.

+1 for this recent suggestion/change as a stopgap.

At the time of writing this the current version of Google Maps API is at 3.30

Added patch with @JoelCC's code from #6

Grmbl, wrong patch format...

Retry

Thanks, @Spokje!

+1 to this change!

Would be great if this was also patched on stable 1.31?
I can't imagine this breaking anything and it is a huge leap forward keeping google satisfied!

Confirming that the patch in #10 applies to the latest release and gets rid of the JavaScript error.

Tests pass. RTBC by multiple people. Let's do this! :)

Confirmed here also we should roll this into the dev at least

Adding an updated patch with uses a variable to define the version
It defaults to 3

@sumachaa #19, I would recommend against allowing direct input of the API version number, or at least the whole thing. The integer part should be hard-coded to “3”, period. While I can maybe see a reason why the decimal part could be configurable, it should only be done if some add-on module that interfaces with ip_geoloc depends on some quirk of an earlier version. But then again, Google is just going to retire and disable that older version anyway, which is why this Issue even exists, so even then I don’t really see the point. It just gives site admins another easy way to accidentally break key site functionality, and for no gain that I can see.

If and when Google comes out with a Maps/Geolocation API v4, it’d be a major change that would very likely break ip_geoloc and other Drupal modules that use the Google APIs, so allowing configuration of the integer part is just asking for trouble, Google would likely keep the v3 API up for awhile in a deprecated-but-not-retired status, to allow time for coders of modules and such to transition over to v4 (I believe they did that with the v1–v2 and v2–v3 transitions).

If you do allow configuration of the decimal portion, it should query Google for the minimum non-retired version and not allow the input to be less than that, nor greater than the most recent available stable (or maybe beta — allowing beta versions could be a checkbox-set boolean variable) v3.x version, and perhaps have a cron task that re-queries Google every day or week or so and increments the setting automatically if the configured one gets retired. The decimal input should allow entry of only one to three digits, and if not empty, the version string should be formed by appending a U.S. decimal point (period) and the contents of that field to the hard-coded “3” to form the final version number.

Again, though, I really don’t see the point. Specifying just the decimal part / major API version number solves the issue and has no downsides that I can see. Doing this in an “idiot-proof” (no such thing, of course) way that would make it as unlikely as feasible for a site admin to accidentally break his site with this setting would be a lot of work for no appreciable even potential gain that I can see. If you know of even a potential realistic use case, I’m willing to be proven wrong on this.

I think that the point of inputting the value is valid. I could see issues where people assume things should work by adding v4 and they don't. I would //really// love to actually get this issue closed and the patch that I submitted ported. I mean this is live for over a year now, and at this point people shouldn't have to drop in a patch to make things move :/

I also agree to the manual modification this wasn't the initial intention so I'll revert it back to the previous. Please pretty please can this get committed.