Forum Replies Created
-
Posts
-
Hai Alan,
Using the premium version of the Extenders add-on, you could add social media buttons to stores. They could appear in the pop-up or on the search results.
The free version can be installed via the WordPress repository (see https://wordpress.org/plugins/slp-extenders/), the premium version can be obtained via the Freemius platform (see https://checkout.freemius.com/mode/dialog/plugin/3300/plan/5247/).Hope this helps.
Best regards,
DeBAATHai JT20,
The SLP Gravity Forms Plugin has been reenabled again.
You could find the free version in the WordPress repository (see https://nl.wordpress.org/plugins/slp-gravity-forms-locations/).
The premium version can be ordered via the Freemius site.
If you have any issues, please let me know.On the other hand, reading your request, I wonder whether you would benefit much from this add-on. Its main purpose is to aid creating new stores using the Gravity Forms.
You might be looking for another add-on for Gravity Forms.Another solution might be to add a new link to each store leading to a dedicated form that has the store ID, name or email as hidden parameter to ease manually following up actions. Or you might add the stores as a selection parameter to the form which enables the visitors to choose the store themselves.
Hope this helps.
Best regards,
DeBAATSomeone changed that in your database — this is the default label definition — “Identifier”.
The default settings are defined in this code snippet below. The first entry is the gettext() entry for the label for that field.
You’ll need to change it in the SQL extendo meta table.
$this->slplus->database->extension->add_field( __( 'Identifier' ,'slp-power' ), 'varchar', array( 'addon' => $this->addon->short_slug , 'slug' => 'identifier' , 'display_type' => 'text' , 'help_text' => __( 'The identifier field is meant to store a unique location record ID from an external data source. ' , 'slp-power' ) . __( 'During a CSV import, this field is used to match up incoming data with existing locations. ' , 'slp-power' ) ));
Thanks for the detailed error report.
The add_message() method call has been patched and will be out with Power 5.5.3 in the next week or less.
This should not be causing WP_Cron to respawn the import job every minute. Do you have other cron managers running in your WordPress stack?
Kevin — if WPE is network activating your SLP plugin then I’m going to assume you are running WordPress Multisite. I don’t see any indication of that above and it is an important piece of information.
Your Premier License must be licensed on the primary site of a multisite install. This is typically the FIRST site in your site list, but can be changed via wp-config. If you are using multisite you should know which site is the primary Blog ID. Adding that information on a subsite will not work for validating the license.
As far as communication with the SLP license server, you can ask @WPE to check that standard web requests are working between your WordPress install and this URL: https://wordpress.storelocatorplus.com/wp-json/wp-dev-kit/v1/license/validate/slp-premier/999/8888
This can be tested from within your PHP environment with a simple PHP script that uses a curl or file get contents operation.
That said, it is very unlikely WPE is blocking communication to any external URLs. If you go to the Store Locator Plus info tab and are seeing “Latest News” with August 2019 dates then the problem is not likely blocked communications via a firewall. The issue is most likely an incorrectly typed subscription ID or setting it in the wrong place on a multisite install.
You have extra security on your server blocking the REST API requests.
{"code":"rest_cannot_access","message":"DRA: Only authenticated users can access the REST API.","data":{"status":401}}That is a WordPress issue — usually a proxy server or plugin blocking access.
Looks like you have a WordPress subdirectory install.
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/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/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/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/
Andrew —
You can rename the permanlink endpoint (last part of the URL) to anything you’d like based on the WordPress standard page editor . The default of using the page title as the URL is a WordPress default. We’re not going to change that as there are other tools and plugins that do it; With Power 5.X every Store Page also gets loaded with a complete set of meta fields (custom fields) that is initially loaded when the page is created with their SLP field values. That means any plugin (or WP Theme) that can utilize custom fields to change a permalink for a custom post type (i.e. Store Page) will be able to set this by default for you.
Same idea for meta title and keywords. Now that Store Pages get those custom fields set you should be able to modify your theme or find a plugin that will do that for you.
We’ve not had enough demand to warrant putting these features in our Premier plugin as part of the standard offering. If you feel these are important for your site we do offer retainers for customizing Store Locator Plus® and making these features part of a standard product release. You can learn more at our Cyber Sprocket affiliate.
Adam — I’ve improved the WSLP messaging when the Google API key fails to help people resolve Google key setup issues sooner. SLP 5.0.4 will be out soon with those changes and CiCi can get a copy of the SLP 5.0.4 prerelease for those that are having location lookup problems and think it may be something to do with how their Google API keys are configured.
Andrew —
Did you port this site over properly?
How is the /portal/ being set in the site_url for your configuration on the live site?
SLP uses the WordPress call to get the REST URL, and that call reads the value of the site_url option in your WP database.
Your live site is here:
https://barreamped.com/But the code thinks your REST listener is here:
https://barreamped.com/portal/wp-json/If you can help us understand the porting process from staging to live we might be able to come up with a solution in the code. However it looks like the port did not change all references in the WordPress database properly.
Is there is a reason you have left the site_url set to the /portal/ subdirectory?
This sort of thing is why I’ve told every single client and contact that has asked my advice to STAY AWAY from WordPress 5.
It may look shiny and new but it is garbage IMO.
Maybe if they fix the trazillion bugs they introduced by WordPress 5.1 it will be a good tool. In the meantime the few sites we are running WP 5 on have become a nightmare to work with and manage. Too many “little things” we keep finding on a daily basis.
I cannot even reply to this post in WordPress 5.X from the front-end / standard form. I’m using a custom admin back-end form and manually setting the POST ID to write this.
I can reply to all other posts EXCEPT this one with the UTF-8 characters.
I’m guessing WordPress 5 is still a mess.
Have you tried downgrading/testing this on a site using WordPress 4.X with the latest SLP 5 release? I’m thinking it will work on WP 4.9.8 with SLP 5.X plugin versions.
Glad it is working, Barry.
If you haven’t left us a plugin review and have a minute to do so it would be much appreciated.
Some people haven’t been able to figure this out and have been slamming our plugin on the review site. We need all the positive reviews we can get:
https://wordpress.org/plugins/store-locator-le/#reviewsRead this article:
https://www.storelocatorplus.com/protecting-your-google-api-keys/Your Google API key is not valid.
Read this:
https://www.storelocatorplus.com/wordpress-store-locator-plus-google-api-key/If you only have a single Google API key:
1) It MUST go in the browser key field.
2) I CANNOT HAVE ANY restrictions.
By adding an HTTP Referrer restriction you’ve now prevented your web server from talking to Google which will break ALL GEOCODING.
With Store Locator Plus® 5 all geocoding, including the find address on the map, now goes through your web server.
Turn off all restrictions with your Google API Key.
Google uses the OVER_QUERY_LIMIT response for this message as well:
Keyless access to Google Maps Platform is deprecated. Please use an API key with all your API calls to avoid service interruption. For further details please refer to http://g.co/dev/maps-no-account
Piss-poor design on Google’s behalf, but the bottom line is that Google is not receiving your API key in the request.
That indicates you have either not set your Google API key properly under Store Locator Plus | General | Server or you are running code on your server that is mangling the URL request we send to Google.
Re-check your settings and make sure you are using only the Google Browser Key or using both keys with proper API security credentials.
Since you are talking about “geocoding requests” it is likely you are referring to adding a location via the admin side of things. If that is what is not working then your PHP code is being mangled in some way. If you’ve somehow “customized” Store Locator Plus either directly or via the multitude of hooks and filters that could be part of the problem. If you’ve not done that but have ANY plugin or theme that is modifying the build-in WordPress URL retrieval methods that could also be the problem.
Since you know how to use command line you should be able to run a network monitor and watch for the Google Maps API request that is going out from your server to figure out what it is being changed to.
The standard Store Locator Plus URL format which is Google’s official URL as of 2017 should look like this:
https://maps.googleapis.com/maps/api/geocode/json?language=en&key=<your-valid-google-api-key>&address=<address-to-be-geocoded>
The key and address fields will be valid text not the <> placeholder shown.
Actually — nevermind, that is not it.
The map renders from Google & SLP , it is when the server responds with all 950+ of your locations (not a great idea, but OK… that is going to hammer browsers and some phones will crash on that page).
Definitely needs more investigation — but there are no code errors coming back. It could just be Google running out of memory trying to render map markers for 950+ locations.
Thank you for removing the minify & cache — I can now see the source and dissect what is going on.
What is your map width/height set to under the SLP > Settings > Map?
You need to make sure you have a height and width that renders a div size that Google can read when their map lib loads.
If you set this to 0px 0px Google will not load the map tiles.
On *MOST* themes if you set it to 100% wide x 100% high it will also fail because most themes do not define a static vertical height for the inner content boxes on a theme. I usually tell people to start with something like 800px x 600px and see what happens. Then try 100% (wide) x 600px.
Google is fickle about that.
Not certain that is the problem — but it is a place to start.
You need to provide a staging site where you can turn on the Power add on and leave it that way or turn on Power on the production site so we can look at the responses coming back from the server.
It is very likely a setting you have enabled in Power that is filtering out your results or changing your location filters in a manner you have not considered.
Let us know when you have a site setup showing the problem or have enabled Power on your live site so we can take a look. It may take us 24 hours to get in and look at the site, but we’ll try to do it as soon as possible to limit the locator down time.
I’m assuming, from CiCi’s post that this is the URL:
https://ala.asn.au/find-a-course/If that is not correct please provide the URL to the site where the problem is appearing.
The problem has been located and is patched in the 4.9.12 release that was published moments ago.
If you updated to 4.9.11 you will need to restore your SLP settings from a backup of the site made prior to the SLP 4.9.11 update.
Experienced users can restore the following two entries from the wp_options table from a prior backup of the site if you do not wish to do a full site restore:
option_names: csl-slplus-options and csl-slplus-options_nojs
If you are not sure how to restore select options from the wp_options table your best alternative is a standard full site restore.
No locations are lost/changed during this process. They are stored in a separate location.
Debbie –
The order_by clause it not being sent along to the data query processor when set via the shortcode. It appears to only be processing the order set on the main settings page.
This is something I’ve added to the development task list for a future update. Not likely in SLP 4.9.8 as this is already in testing but a later release. No ETA yet.
Thanks for reporting this.
– Lance