- This topic has 11 replies, 3 voices, and was last updated 5 years, 8 months ago by .
-
Posts
-
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.
looks 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
The 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.
There 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/
You 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)
If 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/Hmmmmmm,,,, 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.
- You must be logged in to reply to this topic.