(Note that the URL for the website is now hidden link)
This map searching issue has returned. If you search for counselors within a 25 mile radius of zip codes 07057 or 24138, they return over 1300 results all over the US.
I tried installing the patch provided in the previous ticket on our staging site, hidden link, but it didn't fix the issue this time.
Would it be possible to get a new patch or some other way to resolve this issue?
Hello. Thank you for contacting the Toolset support.
I would like to inform you that the fix that was proposed is already included with the latest Toolset Maps plugin version.
Can you revoke the fix you applied on your staging site and send me admin access details of your staging site and also share exact steps I will have to follow to see the issue and what is your expected results with all required problem URLs and access details.
*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.
I have set the next reply to private which means only you and I have access to it.
I would like to know - do you have any posts with zip codes 07057 or 24138 within the 25 mile radius? if no: Do you mean when there is no result found - it should display no result found message?
Hello Minesh,
I have confirmed through other searches that there is at least one counselor within 25 miles of both those zip codes, so this does not seem to be an issue of not getting any hits. As an example, if you search for counselors within 25 miles of zip code 24060, Blackburg VA, you'll find that there is a counselor right in that town, which is less than 20 miles from zip code 24138, Pilot, VA. Doing a similar search while setting the search radius to 100 miles using the 24060 zip code shows that there are several counselors in that radius, but when performing the same search using 24138 (which should return similar results, given the proximity of the towns to each other) it returns the same erroneous result of all the counselors in the country.
To answer your other question, yes, if it turned out that there were no counselors within the search radius, it should return a No Results Found message rather than returning a listing of all the counselors in the database. And in fact, this is what it does. Try a search for counselors within 25 miles of zip code 82501, Sand Draw WY. There are none, so it returns the result of, "No counselors match your search. Please try again."
When I click on the "Check API" button I get the following error:
REQUEST_DENIED - This IP, site or mobile application is not authorized to use this API key. Request received from IP address fda3:e722:ac3:10:2c:c8f5:a80:c, with empty referer
Can you please create unrestricted Google Map API and try to register it.
I have confirmed through other searches that there is at least one counselor within 25 miles of both those zip codes, so this does not seem to be an issue of not getting any hits. As an example, if you search for counselors within 25 miles of zip code 24060, Blackburg VA, you'll find that there is a counselor right in that town, which is less than 20 miles from zip code 24138, Pilot, VA. Doing a similar search while setting the search radius to 100 miles using the 24060 zip code shows that there are several counselors in that radius, but when performing the same search using 24138 (which should return similar results, given the proximity of the towns to each other) it returns the same erroneous result of all the counselors in the country.
=====>
I'm bit confused.
I will use the following page to check:
- hidden link
Do I will have to use only zipcode or full address as you shared "24060, Blackburg VA". Can you please tell me what post is having this address assigned?
I , too, had seen the error message when I clicked the Check API button. However, when I removed the restriction and tested, though the error went away, it did not fix the search so I re-added the restriction.
Interestingly, during subsequent testing on the Dev site, the two zip code searches started working correctly. I confirmed that they're still broken on our Prod site, and know that no one on my side made any changes on the Dev site, so I'm confused as to why it's working. Did you make a change?
Regarding your testing the search, you only use the zip code. I had provided the name of the town to let you know it was near the other town whose zip code is failing when searched on. I can see how that wasn't clear. My apologies for causing any confusion.
Well, I realized that when I had removed the restrictions from the API and done the zip code searches, the results had been cached in Toolset, which is why the correct results continued to show after I had re-added the restrictions. When I removed the cached entries, the searches broke again.
That made me wonder, so I removed a different zip code, 80918, from the cache, and the search for it broke as well.
In order to protect our APIs, I'm unable to remove restrictions, so this is not a solution. We therefore still need this fixed or direction on where else to look to fix it.
As stated with Our Doc:
- https://toolset.com/course-lesson/creating-a-maps-api-key/#known-issues
you can enter a second API key for Google Maps, in the Toolset settings. When added, this second key is used exclusively for server-side requests. This means it is never exposed in HTML and does not need restrictions. If you want extra security, you can restrict it, but only by IP addresses, not by domains.
When you go to Toolset => Settings => Maps page you will see two input boxes to register the Google Map API key.
What if you try to create "unrestricted" Google Map API key and register that with the 2nd API input box as stated it will not be exposed in HTML and used at server side only.
Hello Minesh,
I'm needing to check with someone on this side as to whether I can be permitted to do this, but he's out till tomorrow. I'm also checking on another possible cause that another teammate mentioned. I'll get back to you as soon as I have answers from both of them, hopefully tomorrow.
Hello Minesh,
Upon further investigation, we are now thinking that the issue is caused by a change made to the server hosting the website which removed the stable egress IP. We are working with our hosting provider to address it. We will, however, be keeping your suggested solution regarding removing the restriction from the server-side API as a back-up. If we run into other issues with it, we'll submit another ticket.
