CodeFish

Спасибо, Иван ??

I’m glad that you managed to solve the issue.

I’m still clued why there was a reference to ACF Google Map Extended’s scripts at GMB pages even though those pages didn’t include any map field.

Anyway, thanks for sharing the working solution. I hope this will be helpful for other people having similar conflicts.

Kevin,

the version of ACF Pro that you provided was 3.7.1, whereas in your latest message you claimed to have 5.3.2.2 (latest known).

In any case, I still don’t see the reason for the dequeue not working. It is really strange and I would appreciate, if you post eventually the resolution steps here.

Thanks.

You are always welcome!

Probably, you are right saying that users don’t know the correct translations for addresses. However, it is once again another domain and should be up to them to check for the right translations. Post content is not translated by its own as well. Someone should do the job. That’s my point. Also, imagine a situation that Google gives you not accurate or too long address and you simply want it to be different. Custom field is the simplest way around here. More flexibility and more chances for the users to know their content better resulting in a more accurate content. Hehe.

Thanks for the clarification. I clearly understand your use case now.

However, if a user gets results in German, because of their browser’s accept-language, it means at least that their system (OS) should have German as the default language and so they should know the language as well. Thus, what happens in the map component is an expected behavior. They type and get results in their OS’s/browser’s language.

Now, what you outline is that a German speaking user might want the address in English for the front-end purpose, but he/she might not necessarily know English and you want the map field to translate the address for them. I must admit here that this is a completely another domain – translation. We are not building or even trying to build an automated address translation component. Instead, it is a component with visual interface for adding locations.

I’m still convinced that extra ACF text field accompanying the map field will do the job for you. Only users creating locations know (or at least should know) the accurate addresses of the locations they add and they should care about the correct translation as well.

I was thinking to add country codes to limit Geocoder’s result output, but it doesn’t seem relevant for most of the people, as they are quite ok, if there is a country stated next to the address in the results so they can select the right one.

I would also discourage from trying to add language code to the Google map’s API reference URL. This matter can cause further issues, as Google maps stop working, if you reference the API more than once at one page.

Hi.
I gave the problem you raised another round of thinking and came up with the following solution.
Address bar above the map is bound to the Geocoder’s results. And, indeed, those results are influenced by the browser’s accept-language, if you don’t provide the language code, while referencing the Google Maps API. However, adding the language code doesn’t absolutely guarantee that you will be satisfied with the results of the Google’s Geocoder, as it can still set the marker in the wrong place (results are not 100% accurate). On the other hand, if you adjust the marker’s location in such a situation, then the address is also updated by using the reverse geocoding. And this is all an expected behavior for this plugin’s map component.
If you want to have the address to be different from what Google’s Geocoder provides, you need to go a bit beyond the plugin’s map component by adding an extra ACF field to your post. That should be a text field, which will store any address you want to associate with the map’s marker. You can also do it in any language you want and won’t feel yourself limited in a way. And this plugin will perform its function – providing a visual interface for setting a marker on the map along with zooming level.

Kevin,
my best guess is that your outdated ACF Pro version is causing the issues.
I tested within my installation of WP 4.4.1 with ACF 4.4.5 and ACF Pro 5.3.2.2 and dequeue likes it should be – no sign of ACF Google Map Extended in the HTML code. Moreover, there is no sign of it even without dequeue, as long as you don’t add the field to the GMB post, as ACF is smart enough not load not used fields.
That’s the maximum support I can provide you as it goes way beyond just plugin’s functionality and I feel like shooting with my eyes closed with the data I have.
Nevertheless, you gave me a good idea, that there might be problems and
I will add a JS variable allowing to alter Google Maps API loading by the plugin. Look forward for the next release.

Kevin,
If the page contains a reference to ACF Google Map Extended’s JavaScript file (input.js) and a reference tao Google Maps API JS, then I must say that dequeue is not triggered. Please add some debug code into the admin_scripts function I provided to check, if the routine ever gets there. The expected behavior is that no ACF Google Map Extended’s JavaScript is output at all.
Could you also provide the following information:

1. WP version
2. ACF version
3. Did you add ACF GME’s field to GMB’s posts?

Typically, there should be no script outputs from ACF Google Map Extended at pages that don’t use it – ACF controls that.

Kevin,
could you run a search for ‘maps.googleapis’ in the source of the problematic page and post all the lines, where it appears together with one preceding line? Posting your page’s HTML source code somewhere would also work.
It looks like there is some other plugin/code referring to Google Maps API, despite the fact you state that no errors appear, if you deactivate ACF Google Map Extended plugin.

Thanks.

It is my bad that I didn’t write my initial answer accurately.
In fact the code should be like this:

// vars
var args = {
  zoom : <?php echo empty($location['zoom']) ? 8 : $location['zoom']?>,
  center : new google.maps.LatLng(0, 0),
  mapTypeId : google.maps.MapTypeId.ROADMAP
};

Using $location variable not inside PHP will generate the error you mentioned. Thanks for pointing. I hope it will help someone else as well. The adjusted code example will either use zooming level saved with map or 8 as a default one. Feel free to adjust 8 to any other supported zooming level.

I hardly doubt, but who knows.
I will consider adding this feature in the next release. The disadvantage is that there will have to be a hard-coded list of all country codes supported by Google Maps.

Hi.
Front-end map implementing is not a trivial job, unless you are familiar with PHP, HTML, JS and Google Maps API. The example is nice start off.
From what I see, your code would just set the appropriate HTML attributes for the div tags having class marker, but that won’t show any map. Moreover, if it is Firebug that states ReferenceError: $location is not defined, then you are definitely using $location variable in the wrong place – in JS code instead of PHP code.
Regards.

Hi Kevin,

you can dequeue Google Maps using googlemaps-api handle.

Adding the following code to your theme should do the job:

function admin_scripts() {
  wp_dequeue_script('googlemaps-api');
  wp_deregister_script('googlemaps-api');
}
add_action('admin_enqueue_scripts','admin_scripts',100);

You might add extra conditions to dequeue the script at certain pages only like Google Maps Builder pages.

Making hard enqueue like ACF Google Map Extended currently does is not the most elegant way, but the dynamic loading through google.load (which is in place btw) had several compatibility issues.

Btw, Google Maps Builder implements the code, which prevents adding Google Maps twice. But somehow it doesn’t do the job.

I see what you mean now.
This feature was considered initially, but didn’t get implemented as its added value didn’t match the efforts it required. The reason behind this is that it requires Google maps library reloading. As you probably understand, this plugin is not the one using it in many use cases. Thus, it would influence other dependencies.
While loading the plugin checks if Google maps library was already initialized and skips that step preventing any ways to add the country code you want.

The easiest solution is adding an extra ACF field with a list of languages. This should cope with your needs. Could you provide a real world example of the use case and I might consider adding the language then?

P.S.: Thanks for the compliment!