[Plugin: Google Maps via Store Locator Plus] Google API sensor error

Have you tried turning on/off “force load javascript” in the Pro Pack (this will be a standard feature in v3.5 btw).

Is location sensor is not checked then the sensor settings should always be coming back false & Google Gears is not loading so it should be working ok.

Unfortunately no change. Not even with the latest firmware. Our Webdamin just told me, he had this issue with another project already and tries to find out, what the problem was. Something with the vers.3 sensor. I will keep you updated, as soon as we found the solution.

Well, our webadmin with real code experience could solve the problem really fast. Here is, what he did:

path: wp-content/plugins/store-locator-le/include
file: storelocatorplus-actions_class.php
lines: 415 – 418 (417)

———————–
wp_enqueue_script(
‘google_maps’,
‘https://’.$sl_google_map_domain.’/maps/api/js?v=3.9&key=’.$api_key.’&sensor=false’
);
———————–

‘https://’.$sl_google_map_domain.’/maps/api/js?v=3.9&key=’.$api_key.’&sensor=false’

Apparently the “&” output is not correctly. The browser displays “# 0348,” instead of “&”.

He has changed the first line and “& sensor = false” in first place after the set ‘? “

https://’.$sl_google_map_domain.’/maps/api/js? sensor=false’&v=3.9&key=’.$api_key

Probably that solved the problem already – but he still tried to reach a recoding to have a better result from the upper block like here:

—————————-
$GoogleM_url = urldecode(‘https://’.$sl_google_map_domain.’/maps/api/js?sensor=false&v=3.9&key=’.$api_key);

wp_enqueue_script(
‘google_maps’,
” . $GoogleM_url . ”
);
————————–

With this solution the plugin now works well on all networks. No more Google API-errors. We are very happy now.

Maybe you can take care about this issue for further releases, we would be very glad. If you can confirm this topic please, I would mark this topic then as resolved!

Best regards from Germany.

I’m moving the sensor parameter to the “front” of the string just after the ?. That will help fix this problem for sites that are not operating in a standard environment.

Default WordPress installation will not encode the URL passed to wp_register_script() or wp_enqueue_script. I just read the entire call stack for both functions and there is no inherent string manipulation going on with the source URL.

My guess is a PHP setting, a WordPress plugin, or WordPress theme is active and adding a text filter and mangling the URL. That would explain why it is nearly impossible to reproduce this issue on any of our servers.

Doing this:
wp_enqueue_script(‘test’,’https://a.b.com/blah?x=1&y=2′);

Should NOT end up with the URL being called as:
https://a.b.com/blah?x=1#0384y=2

The only reason & would be translated to #0384 instead of &amp (which would be a normal default encoding) is because a special language filter is catching the URL. A smart language filter should NEVER change a URL string like that. #0384 is NOT the accepted international replacement in a URL string for &.

Why wrapping urldecode() around the string changes the behavior is also suspect, so I left that part out. On “vanilla PHP”, the two strings are identical:

$x = ‘https://a.b.com/blah?x=1&y=2’

and

$y = urldecode(‘https://a.b.com/blah?x=1&y=2’)

and

$z = urldecode($x)

return the exact same string.

Passing $x, $y, or $z to wp_enqueue_script() should be returning the same exact result in all 3 cases. My guess is this is having zero impact and the only thing that fixed the issue was putting ?sensor=false first. This forces that required parameter to be put first, before your language filter mangles the URL.

I only share all this with you because something odd is going on with your install and there are likely side effects you are not aware of. Hopefully nothing serious, but mangling URLs can cause issues even if they are not visible including warnings filling up log files and degrading system performance. Also, the API version in our URL with Google (v=3.9) is not critical today, but who knows if/when Google will change their mind on that, at which point I’m guessing this “fix” will not work.

Thanks for sharing your findings & giving me the info to improve the plugin!

I’m having the same problem as described above – where anytime I access my site I receive this error. <i>The Google Maps API server rejected your request. The “sensor” parameter specified in the request must be set to either “true” or “false”.</i>

<b>Basic Information:</b>

• I don’t have the Pro version, as I’m currently testing out the plugin, before diving in.
• I’ve tried turning off other plugins as well as the ones using google maps and it still comes up.

I’ve had a look at storelocatorplus-actions_class.php and noticed that in the newer version of the plugin (which I have) you’ve already made the changes outlined above. I’ve even tried going a step further and using a variable as mentioned by the previous poster.

None of it seems to work and the source code for my website just reads:
<script type='text/javascript' src='https://maps.google.co.uk/maps/api/js'></script>

Nothing after the js? is being passed through by the wp_enque_script()

I can turn off the error using the option <i>Turn Off SLP Maps</i> but that’s not really useful to me since the maps stop showing.

One thing that did peak my interest was some code I noticed in the file storelocatorplus-actions_class.php

<i>`//todo:character encoding ???
//”https://$sl_google_map_domain/maps?file=api&v=2&key=$api_key&sensor=false{$sl_map_character_encoding}”</i>

I would have tried to implement it myself but I’m not so confident that I know exactly what it is I’d be trying to do.

I have a strange server set-up (using AWS) so perhaps part of the security is removing characters from the wp_enque_script(…) – any pointers in the right direction, or amazing solutions would be much appreciated ??

If you need the website just let me know.