The attached duplicator features a Map on the /find-an-artist/ page.
Below the map, there is a Custom Search for Distance.
1. Attempt to search by 25mi from Washington D.C., DC, USA (use the autosuggested address for "Washington" please).
2. You will see several results returned on the map.
3. At least one of them is not in Washington D.C., DC, USA, rather it is in Charlotte, NC, USA - which is several hundred miles away from Washington D.C., DC, USA
1) Now, edit that result (Charlotte, NC, USA) and make its address to be Zurich, Switzerland or anything very far, very different from USA.
2) Reload the map, and search again for Washington D.C., DC, USA
3) You will see the post for Zurich, Switzerland (Previously Charlotte, NC, USA) returns again in the results. This time, it is several thousand miles away from Washington D.C., DC, USA and has absolutely nothing to do with anything USA.
I installed the site and noticed there were 2 posts being returned that should not have been (with ID 3545 and 3544).
(To make it easier to see what was going on I had simplified the output of the View to include just the post title and ID, location, and distance.)
There was something odd about these 2 posts: they both had postmeta entries with a key "Location" that had addresses close to Washington D.C., although the wpcf- address fields had different locations much further away.
Somehow the distance calculation used in the modified post query seemed to be getting the coordinates from these fields, and I don't know how that might have arisen.
In any case, I resolved the problem by just deleting those two postmeta entries (with meta_id 37230 and 37227 respectively), and that fixed the issue. (I checked and there doesn't appear to be an active field with key "Location".)
Thanks for the help on this.
Indeed, I had seen those fields as well (they probably are from the import process from their old HTML based site). I had not considered deleting them because clearly the View should (and according debug info of the view query) does query by a wpcf- field.
Does this warrant more investigation, since it seems that if a post has any field with a value LIKE%% location, it picks that one as the address?
This should not happen, since the query is set for a particular, precise field key.
I confirmed that simply adding a (Toolset Types) single line field with Name "Location" immediately brings the issue back.
I did not try on clean install but I am relatively sure this is replicable, and thus sounds like a BUG to me, it seems like the plugin queries fields by a LIKE%% location key instead of a precise key (even thou, according the SQL log that is not the case...)
SELECT TGB_posts.*
FROM TGB_posts
INNER JOIN TGB_postmeta AS tmapsmeta
ON ( TGB_posts.ID = tmapsmeta.post_id )
LEFT JOIN TGB_toolset_maps_address_cache
ON TGB_toolset_maps_address_cache.address_passed = tmapsmeta.meta_value
WHERE 1=1
AND TGB_posts.post_type = 'artist-listing'
AND ((TGB_posts.post_status = 'publish'
OR TGB_posts.post_status = 'private'))
AND ST_Distance_Sphere(ST_PointFromText('POINT(-77.036871 38.907192)'), TGB_toolset_maps_address_cache.point) < 40233.6
GROUP BY TGB_posts.ID
ORDER BY TGB_posts.post_date DESC
Notes that it doesn't specify a post meta key at all, it looks at all postmeta entries for any that have a value included in the maps address cache.
I tested by adding a custom field with the key "bananas" and it also came up in the results.
I'll circle back to this a little later to escalate properly.
It will be Monday before I create the tickets to escalate, but I just wanted to share with you that my suspicions were that a postmeta condition for the address field key may only be added when ordering by distance, and sure enough that is the case.
Your problem is that you have implemented this using Blocks (!), and the option to order results by distance was never added to the View block, you can only add it when creating a View with the legacy editor.
