I am trying to: display the distance of some CPTs from the user current position on a mobile
Link to a page where the issue can be seen:
I expected to see: every time I resfresh the page I expect to see the updated distance (when the user changed his position)
Instead, I got: always the same distance (the first calculated / retrieved from the mobile device
The issue seems due to the way the position is figure-out: in toolset_maps_location.js the code first trys to retrieve the position from the cookie and if not found, the position is retrieved from the mobile. However, this way, as log as the cookie is valid, the position never evolve (according to the new user localization).
Toolset Maps plugin is using Google Map API to retrieve your current location, so when you changed your position, please open official Google maps: hidden link
Make sure you phone device can get current real-time location.
I don't need real time distance update, I just need that the distance between custom post types and the user current location is correct when the page is displayed (in several views displaying list of CPT in the proximity of the user). And according to Toolset documentation it is the expected behaviour.
However it doesn't work. The user position is retrieved from the phone only once, stored in a cookie and then retrieved from the cookie. So the distance calculated (when the view is displayed) can be totally wrong.
You can add the map shortcode [wpv-geolocation] to let your user to refresh their location data manually:
For example:
[wpv-geolocation message_when_missing="We need your location to show this content"]
// Everything inside will only render when the location is saved and will have that location available on backend
[/wpv-geolocation]
Hi Luo, actually I know how wpv-geolocalization short code works, I use it. My problem is that when using the short-code "toolset-maps-distance-value" with the user location as the center ("the location of the current visitor"), the location is not figure-out when the view is generated but just once, stored in a cookie ("toolset_maps_location") and reused till the cookie expire. Which means that if the user move (possibly even during several days), Toolset will always use the same location. Not really what you would expect for a "mobile" application centered on the user location.
Have you tried to wrap the [toolset-maps-distance-value] shortcode with [wpv-geolocation]?
For example:
[wpv-geolocation message_when_missing="We need your location to show this content"]
[toolset-maps-distance-value ... ]
[/wpv-geolocation]
So user need to refresh their location then see the distance value
Hi Luo, yes of course I wrapped the toolset-maps-distance-value short code within a wpv-geolocation short code (as requested in the official documentation). It works, but once the geolocalization is asked once, is never asked again : for the following needs (ex. when the page is refreshed or a new view requiring the user localization) your code relies on the value savec in a cookie ("toolset_maps_location"). This feature is supposed be used for mobile applications ... but if the localization is not updated when the page is refreshed, the implementation is useless.
FYI I had to code a work around on my side, that update your cookie if the new position is at more than 20m from the saved position. But I would expect from Toolset to fix this issue (ideally in a more elegant / efficient way than my work-around).
Reviewing the source code, it looks like the user location is set just as a session cookie (no expiry is specified, so the cookies will expire at the end of the browser session).
Imagining how this might be changed in a way that was simple to implement and represented a reasonable compromise for different users and their respective use cases, how about a time limited cookie?
I could suggest that to the developers. Maybe 15 minutes? I don't think this would be something where the developers would be happy to add more settings to an option page for such an interval, and it has to be something that seems generally workable.
As you have access to the cookies, you could add some code triggered by a user interaction which checked how old a cookie was and deleted it after an interval of your choosing, so that Toolset would retrieve the current coordinates from the browser API instead.
Hi Nigel, thanks a lot for taking the time to look at the code and spot the issue. On my side, pending a fix from toolset, I choose to refresh the cookie value whenever the new position is at more than 30m from the previous one. I think it's better to check and refresh the cookie based on distance than on time (expiration) because if the user is in a car, the distance can change significatly in a very short period of time (and not seeing any change in the app would compromise his confidence on the information provided). On top, I'm not an expert, but I don't think that getting the new position in JS takes much time / resources on the mobile (it's likely an information regularely updated by the phone for any application requiring it). So for the time being I'll use my workaround, but I'm sure I'm not the only one using this feature for mobiles 😉 So it would be good to have an official fix.
I'm not sure that makes much sense, certainly as something that we would implement in Maps.
The cookie is set so as to avoid requesting the current location from the browser.
Your solution—reset the cookie when the user has moved some distance from the location stored in the cookie—requires asking the browser for the current location so that it can be compared to the cookie location. Given that the purpose of the cookie is to avoid requesting the location from the browser, having a cookie at all becomes redundant.
I can foresee that adding an expiration time to the cookie might make sense, but as its not something you would use and as we don't have any other requests for such a feature, I think we can put this on the long finger, and revisit it if we get similar requests from other clients.
My suggestion was rather to add some JS code (similar to your toolset_maps_location.js) to the code generated by the short code wpv-geolocation: when the page is loaded, the JS code would check the current position against the cookie, and in case of significant discrepancy, would update the cookie and kick a window.location.reload. But OK no problem if you don't consider it a bug. I've my workaround. I'll close the ticket.
