Getting "Near…" geo search to work in 5.4.4.3
-
Separate thread made from https://www.ads-software.com/support/topic/feedback-on-5443-the-2-beta-of-55?replies=5#post-4510200:
7. On https://demo.wp-events-plugin.com/events/ when you write something to the “Near…” field, you get several autocomplete options. We didn’t get any autocomplete for this field on our site. We’d like to have whatever the demo site is having with a side dish of magical customization abilities.
-
We didn’t get any autocomplete for this field on our site.
in your geoname account – https://www.geonames.org/manageaccount
did you enable free webservices ?
Will keep that in mind as an option. Thanks!
For the future, it’d be nice to have an autocomplete that would use the contents of the site itself. This could be done as follows:
1. Event or location in a new town is submitted
2. EM queries Google Maps for:
– Address: $town
– Town: $town
– Country: $country
3. EM saves the geolocation for that city – country combination in DB.
4. EM provides an option at Events > Settings > GEO APIs to use only the internal towns for the autocomplete.This would provide all we need at the moment, and might cover the use cases for many others. No creation of external accounts, only clean autocomplete results that aren’t bogged down with results from countries not relevant to the site in question.
As a great upside that autocomplete can be easily expanded to allow searching for anything near any added location. GeoNames API might not know the skateboard park that your visitors frequent, but your locations list does.
are you on 5.4.4.3? that update has removed the use of GeoNames and that API section in your settings area, it’s now using Google services via JS.
Based on what I hear from people, an autocomplete based of the DB wouldn’t be ideal, because it’s an extra burden on servers and not fast enough (the autocomplete on submissions has similar issues), whereas the new Google autocompleter is near-instant and doesn’t query your server (and no API keys needed).
Good call. I’ve updated that dev site to 5.4.4.3, but perhaps some other dev work we have done reverted it to 5.4.4.2.
The new Google autocompleter works and is fast in 5.4.4.3. Some questions:
8. How to set the default event list to show locations near a certain place (town), exactly as if it would have been supplied as a alue for this form and submitted?
9. Can we limit it to give results only from certain country or countries?
10. Any suggestions for removing the Powered by Google part?
11. How easy it is to replace with a custom autocompleter on our own server?
8. you’d need to modify the $args variable in the events-list.php template (I think there’s a hook somewhere which you can do this too, maybe in /em-events.php first function)
9. For one country, yes, but not multiple. That’d be $args[‘country’]
10. that’s the downside. it is possible to remove that powered by but it’s against Google’s usage policy afaik. I did manage to get it working with the jQuery autocompleter for example, but scrapped that in favour of google’s library. Maybe CSS will work too.
11. You could override the templates/templates/search/geo.js file and write your own autocompleter. You’d also need to hook into WP and catch/reply to the ajax request
btw, unless you’re on a blazing fast server or have an overly optimized auto-completer, the user experience is phenomenally better using an autocompleter that queries a service like google.
8. Thanks!
9. I was a bit unclear: In 9 I meant to ask whether it’s possible to limit the autocomplete results to be within a certain country or countries?
10. Will have to seek that usage policy then to make sure whether it’s ok to remove. If it’d be far smaller and neater it’d be more acceptable, but now the colourful Google logo is the first thing that gets noticed when autocomplete results are displayed.
11. Thanks, will keep this in mind.
12. On speed: We have Search Autocomplete on our main search box. Haven’t noticed any slowness so far. Now that you mentioned, it is slower than the Google one, but not enough to be an issue. We would choose that slightly lower speed with higher configurability any day over higher speed with the Google logo and a not-completely-suitable location list.
In my estimation the server isn’t blazing fast but it’s definitely faster than your average shared hosting. If a convenient way to use a custom autocompleter would require having the Pro version of EM we wouldn’t mind at all. So far we’ve paid for EM Pro to support your work but have used the regular EM as we don’t use the booking features ??
9. yes, but you’d need to modify our script according to the Google places library
10. I agree, but see these two:
https://developers.google.com/places/policies#attribution_requirements
https://developers.google.com/maps/documentation/javascript/places#adding_autocomplete (see the note)Not every site will show a map on that page so we’re borderline. This would be worth its own topic for discussion.
11. it’s you’re happy with the speed then so be it ??
9. Thanks for the links. I was able to limit the search to a country by changing in templates/templates/search/geo.js the line 5 from:
var autocomplete = new google.maps.places.Autocomplete(input[0]);
to
var options = { componentRestrictions: {country: 'fi'} }; var autocomplete = new google.maps.places.Autocomplete(input[0], options);
However, it seems that there are other places where the use of the
option
parameter should be added, too, like lines 37-38:autocompleteService = new google.maps.places.AutocompleteService(); autocompleteService.getPlacePredictions( {'input': input.val(), 'offset': input.val().length }, function listentoresult(list, status) {
Marcus, what do you think of adding the
option
parameter to the relevant parts of the default template so webmasters would only need to set its value? And then, hopefully, adding a way to set that option from a custom .js file? Then one could just set the value without having to check for updates to the template on every EM update.This would be quite neat as the option parameter enables many settings and is the only allowed parameter besides
input
.10. We’ll let the logo be for now. How to switch to using the dark one from https://developers.google.com/places/policies#logo_requirements, though?
12. To clarify, does that mean you’ll provide a convenient way to use only an internal towns and/or places list?
9. Wasn’t able to get this to work in a custom template. Only modifications to the core file affected site behavior in 5.5.
12. To clarify further, Search Autocomplete doesn’t allow setting the geo field values. That would require some custom coding. The question is that as such a feature could benefit many EM users, could it be included in EM core?
10. would have to look into that can consider this for a future update, could also add an event trigger that can be hooked into in the meantime
12. we probably won’t any time soon
10. Great! Hoping both get implemented; the template change for
option
and the ability to use a custom geo.js file.you should be able to use a custom geo.js file already
A custom geo.js file in
templates/search/
doesn’t have any effect for us in 5.5, same as 5.4.4.3. The above patch for item #9 only works if we apply it in EM core geo.js. A file scope.php in the same custom template directory works as intended.Where is that geo.js included (queued)?
- The topic ‘Getting "Near…" geo search to work in 5.4.4.3’ is closed to new replies.