As an example, if we search for counselors within a 25 mile radius of zip code 23024, we'll either get a result of 0 or we'll get a result of 1024 counselors who are all over the US. As another example, if we search for counselors within a 25 mile radius of zip code 38109, we'll sometimes get a result of 2, 23, or 27 counselors.
Did the changes you gave us in the patch not make it into version 2.0.12, meaning we should go back to the patch, or are there new issues with this version?
Thanks for your help.
Barney Royalty
Focus on the Family
Hello again, Nigel.
I was just able to get a copy of Prod made before the plugin was updated (meaning that it still has the patched 2.0.11 version) and install it on our Dev environment. I repeated the search for counselors within 25 miles of zip code 23024 and got similar erroneous results. (The only differences in the results between Stg and Dev appear to be content differences introduced by the different dates the backup copies of Prod were taken.)
This would seem to indicate it's a pre-existent bug, not something which was fixed by the patch but lost in the subsequent update to 2.0.12. Sorry for the false trail on that one.
I tried making some test searches as you describe above, and the results were sensible (e.g. 2 results, 0 results), until they weren't, i.e. refreshing the page several times eventually prompted the same search to take a long time and then eventually return what looks like pretty much all of the counsellor posts.
I added Query Monitor to see if I could spot a problem with the relevant query, but what I found on these occasions where the wrong results were—eventually—returned was that the server was being tied up in knots making a huge number of queries (over 5000 vs a typical couple of hundred).
So there is something wrong that is unrelated to the distance search issues we investigated previously.
There may well be something that shows up in the logs that could account for it, but I need FTP access to be able to investigate.
Could I get that from you? I've set another private reply.
I have successfully installed the copy of your site locally, where I also see the same problem, but I haven't tracked down the source yet.
It requires quite a deep dive to understand why your site is behaving so differently than a normal maps distance search, but I will try and identify the cause as soon as possible.
I suspect the problem is with your API keys (likely the second API key you add in the settings for server-to-server requests).
Toolset caches addresses and their coordinates so that it doesn't have to keep pinging the Google Maps API for addresses that have been queried before.
Not only does it cache the addresses added to the address field of your counsellor posts, it also caches addresses used in searches.
So if someone searches for the zip code 38109 its coordinates are looked up via the API and it gets added to the address cache so that if someone else searches for the same zip code in the future we already know the relevant coordinates and don't have to query the API again.
Because you demonstrated the problem with the zip code 38109 it should already be in the address cache table, but it's not.
If you search for a zip code such as 44108 which is already in the cache table then the search works correctly.
Searching for 38109 it seems like it cannot retrieve the coordinates from Google—and hence they don't get cached and are unavailable for the current search, which therefore gives erroneous results.
Please review both API keys in your Google dashboard to ensure they are correct.
Hello Nigel,
I've confirmed that the API keys in the Prod, Stg, and Dev environments are all correct. I've also confirmed that the IP address associated with the server API key is correct on all of them.
On the staging site I removed your API keys and used my own API key which doesn't have any restrictions.
I then went back to the Search Counsellors page and searched against the 38109 zip code and it returned 2 results as expected.
That does seem to confirm that the issue is with your API keys.
I have re-instated the keys on your staging site.
I suggest you go to the Google panel for these API keys and in the first instance remove all restrictions from the keys, and then perform a test search again.
I expect you'll find that it works.
You can then return to edit your keys in the Google panel and pay close attention to the restrictions you then apply.
Sorry for the delay in responding, Nigel. Up to this point, I've not had access to modify the Google API keys. My boss has been working to get me access. As soon as he's successful (hopefully later this morning) I'll test the changes you suggested.
Hello Nigel,
I got access to the API keys. I did a couple of tests. First, I deleted 38109 from the Stg environment Toolset Maps cached data and then did a search. It returned two results, and continued to do so with multiple repeats.
I then did a search on 23024. Multiple repeats gave different results each time. I then did as you recommended and removed the restrictions from the API keys. Multiple repeats of the search continued to return different results each time. I then went into the Toolset Maps cached data and removed 23024. Multiple repeats of the search after that consistently returned 0 results each time. Just to make sure, I widened the search radius from 25 miles to 50, and it consistently returned 3 results.
I then tried with another zip code reported to me, 80138. It seemed to stay to the correct area of the country, but returned a varying number of search results with each repeat.
Therefore, it doesn't seem to me that removing the restrictions addressed the issue. Clearing the cache for the specific zip codes, on the other hand, did fix them. The question is, why did they corrupt in the first place, and if cleared, how do we prevent them from corrupting again?
I'll leave the restrictions off of the APIs for now so that you can do your own testing. Other zip codes to test with are 94587 and 61462. I'll then re-add the restrictions tomorrow morning.
Hello again, Nigel.
If the issue lies with the cached search, wouldn't this imply that the bug is within the Maps plugin, or perhaps some module that it uses to create and/or read the cache?
Also, please let me know when you've finished testing. If I'm correct in thinking that the restrictions are not the issue, I'd like to put them back on the APIs to help protect them.
It involves what I think is a flaw in our code, but only in the context of how you have set up your distance search.
Specifically, you have disabled the auto-suggest feature from the filter for where to search, and are just entering zip codes.
Without going into too many details, the address caching system is based on the expectation that you use the filter as implemented, i.e. using the location auto-suggestions.
Given that you are not, it looks like we are failing to update the cache in some scenarios where users enter just a zip code.
I've made a small change to the relevant code, which in testing on your staging server appears to be working fine with the test zip codes you suggested.
If you want to do some testing to confirm that for yourself then you can update your production server with the same modified file.
