Store Locator Plus® for WordPress › Forums › Store Locator Plus › Google JavaScript API geocoder failed with status ERROR results undefined
- This topic has 11 replies, 3 voices, and was last updated 5 years, 9 months ago by Cici.
-
AuthorPosts
-
January 29, 2019 at 10:10 AM #58545webpromParticipant
HI!
Chrome shows https://www.—–.com/art/wp-json/store-locator-plus/v2/geocode/9a29e207757d96a36a7449aefb1967a0/us/Philadelphia 404 (Not Found)
8470a.js:1 Google JavaScript API geocoder failed with status ERROR results undefinedWP URL is located in /art/ folder, but site’s URL is domain with HTTPS.
https://www.—-.com/art/wp-json/store-locator-plus/v2/geocode/9a29e207757d96a36a7449aefb1967a0/us/san%20diego – “Not found” error from wp
https://www.—-.com/wp-json/store-locator-plus/v2/geocode/9a29e207757d96a36a7449aefb1967a0/us/san%20diego – {“code”:”rest_forbidden”,”message”:”Sorry, you are not allowed to do that.”,”data”:{“status”:401}}
I have both API keys and it’s working correctly on backend (settings > map > at startup test) but on frontend search is not working. I’ve read previous posts. Did you find any solutions?
Search was OK before update.
It’s already wp 5.03. I’ve tried to disable most of plugins but no change yet.
—
Second question: we had your pro pack since 2013. Is it deprecated now?
Thanks.
- This topic was modified 5 years, 9 months ago by webprom. Reason: added errors
January 29, 2019 at 2:21 PM #58556CiciKeymasterlooks like you disabled REST API for anyone that is not logged in
If backend geocode works (add location , it geocodes) but not the front-end it is almost always an over-zealous WP security issue.
message about the rest……WP version 5.0 caused issues when it came to the plugins that rely heavily on REST. With WordPress 5 some cannot even save pages or posts. It is riddled with REST API and JavaScript errors about invalid JSON responses. REST forbidden means your proxy server or a WP plugin is preventing REST API calls. SLP will not work — nor will any WP page/post edits.
Do not know if that is your situation or not without your site url.
If that is not the issue and you think it is the way you have set the Google API keys See the developers latest Article about the type of referrers and IP restrictions with the Google API keys.
Next Question
Tagalong, yes it will not work with current versions (or any SLP versions above 4.8.6) that was retired over the course of a 3 year process . Tagalong, proPack, and a couple of other add-ons were combined into the Power add-on. See info about Legacy. Most likely as a result of WP auto updates or updates to version 5 forced you to update SLP I assume. Now those legacy add-ons do not work. Frustrating i know but there were just too many one on add-ons and changes in the way everything is working now just required rewrites over time. See Legacy
January 29, 2019 at 4:29 PM #58563webpromParticipantAccording to this article https://www.storelocatorplus.com/address-lookup-failures-on-wpslp/ my setup is correct, I’m able to login from https://www.—-.com/art/wp-login/
Still there is an error 404 for locations.
—————–
REQUEST
GET /art/wp-json/store-locator-plus/v2/geocode/9a29e207757d96a36a7449aefb1967a0/us/san%20diego HTTP/1.1
Host: http://www.—-.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Referer: https://www.——.com/store-locator/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,he;q=0.8,ru;q=0.7,uk;q=0.6
Cookie: PHPSESSID=7f5666e1cee374f2664f4bce2caea9ef; caosLocalGa=GA1.3.997967176.1548725043; caosLocalGa_gid=GA1.3.1494446156.1548725043; wp_woocommerce_session_9a29e207757d96a36a7449aefb1967a0=34bbb21bbe63b29fb6c279ce8a7d86b9%7C%7C1548898848%7C%7C1548895248%7C%7C61d6f5dbdd32204b405b4302db944b74; woocommerce_recently_viewed=928—————
RESPONSE HEADERS
HTTP/1.1 404 Not Found
Date: Tue, 29 Jan 2019 21:23:49 GMT
Server: Apache
Pragma: no-cache
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Link: <https://www.—–.com/wp-json/>; rel=”https://api.w.org/”
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Vary: Accept-Encoding,Cookie
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8January 30, 2019 at 11:55 AM #58579CiciKeymasterThe issue is:
Your site made it so that the REST API on the public-facing site (front end) is disabled.
therefore SLP map (address box) cannot talk to your WP site via the REST interface to do an address lookup.
If backend geocode works (add location , it geocodes) but not the front-end it is almost always an over-zealous WP security issue. The server needs to be able to talk to the Google API to get the geocode location and return it.
Are you restricting access to your site for certain public access, such as an age restriction. We see that on some sites selling alcohol or , now medical purpose therapy etc.
If yes, your age restriction plugin/theme feature is very likely blocking all REST API requests to /wp-json…
You need to be able to turn that feature off for any of their AJAX or REST URLS.
most older plugins/themes already do that for AJAX but have not updated for REST — which is far more prevalent now with WP 5.
February 9, 2019 at 10:07 AM #58681webpromParticipantWhen will you release 5.04? Looks like all sites with wp url in a folder have this problem now.
February 9, 2019 at 6:21 PM #58689CiciKeymasterThere is a beta version out that addresses the map domains always pointing to US but it doesnt sound like that is your issue since the issue is the WP REST API in subdirectory even though they tell you you can do that, . If you have a dev or staging site we can send the pre-release.
The developer has been researching and researching and the problem is in URL routing of the REST requests — it isn’t getting to SLP validate the connection
if he hacks his code to work with WP in a subdirectory he is afraid that sites that are NOT having WordPress installs in a subdirectry will now break. he started routing the Geocode requests using the WP REST API back in October. no problem on the majority of sites. It seems that people started updating SLP to version 5 and if they had WP installed in subdirectory now it breaks. If you could provide us info , did you upgrade from SLP version 4.9.x to 5 or 5.03 recently or did you update WP to 5.0.3 and then the errors began?
Can you downgrade to earlier version 4.9 to see if that corrects the issue? The development downloads and earlier versions can be found here
https://wordpress.org/plugins/store-locator-le/advanced/
- This reply was modified 5 years, 9 months ago by Cici.
February 10, 2019 at 1:50 AM #58694webpromParticipantSLP worked ok with previous versions. Search is broken after update of wp5 and slp.
Developer can probably make 2 paths for sites with wp in directory and in the root, i guess. Or to use the same method that allows initial search of predefined location without a problem.
February 11, 2019 at 12:44 PM #58701CiciKeymasterYou didnt mention what version you had of SLP. The geocoding methodology changed in version 5. Refer to the changelog here
There was a reason why SLP was changed to have the communication go through the WP REST API instead of direct to Google. Going thru the WP REST API added Security. This prevents others from stealing your geocoding key so that it is not visible to the public . Too many of our customers do not know how to add IP restrictions and obtain the separate geocoding key.
Our developer has been researching to see if he can create a work around but after researching further he realized that sites set up with configuration using the old Codex docs and not the WP Developers handbook may not have their site configuration to use REST API set up correctly. . I am not sure how much time he is going to be able to invest to address customers with the specific issue. He will be writing an article about it for the tech savvy people such as yourself and how you can add the rules.
As I am not as tech savvy and am the go between for the lay person who is our regular customer base, bear with me with the explanation.
the issue is “– the web server configuration, regardless of which web server you choose, is NOT correctly re-routing requests to the URL that WordPress is “listening on”.
SLP now uses the address WordPress tells it…
So if you installed in /wordpress and set your “WordPress Address” to http://yourdomain.com/wordpress/ it is going to talk to yourdomaind.com/wordpress/wp-json/
If WordPress is not responding to REST requests there then you must add a rule to your web config to say “hey, re-route all requests coming in at /wordpress/wp-json/ to /wp-json instead.
The SLP developer will write an article on this issue but will not be re-writing an option immediately. . In the meantime you can add an additional rule for REST API requests to make sure they get routed correctly. (hosting companies allow users to adjust this)
February 11, 2019 at 12:59 PM #58702webpromParticipantok, waiting for the article then. i have all latest versions of slp and wp.
thanks.
February 11, 2019 at 10:58 PM #58710Lance ClevelandKeymasterIf you have WP installed in a subdir AND are using permalinks (any setting other than “plain”) you MUST have the correct wp-json rewrite rule in your Apache or nginx config.
Most of the Codex examples predate the REST API and do not properly account for it when permalinks are enabled.
https://www.storelocatorplus.com/wordpress-subdirectory-installs-and-the-rest-api/February 12, 2019 at 4:14 PM #58738webpromParticipantI confirm search is working again in v.5.04, no need to create special redirect, thank you!
February 15, 2019 at 3:51 PM #58763CiciKeymasterHmmmmmm,,,, it shouldnt have if the issue was the redirect. There was a different issue fixed, the region lookup for geocoder was patched. Perhaps that was the issue with your site. Anyhow, gkad it is working for you. if you have any issues with htaccess in the futre, we did have some customers add the route redirect and posted in the forums. Thanks for your patience.
-
AuthorPosts
- You must be logged in to reply to this topic.