Forum Replies Created
-
Posts
-
Have you enabled the pages module via the checkbox under the General tab?
As for plugins you only need 3 from us:
Power
Experience
Premier
If you use any of DeBaats functionality you’ll still need to install his plugins separately.
What is your website URL? The page where you have your locator installed will help us see what you have running in your WordPress stack. Something is modifying the admin panel output and interfering with the add on JavaScript.
Your site is breaking because one of your plugins or your WordPress theme is not WordPress 4.5 (or later) compatible.
See:
https://docs.storelocatorplus.com/blog/q-my-map-is-not-showing-up-what-did-i-do-wrong/
This part applies to your site:
Is something breaking the JavaScript on your site?
Check your web browser debug console. All modern web browser have it including Internet Explorer (IE), Chrome, Firefox, and Safari.
When WordPress was updated to version 4.5 it included a new version of jQuery. That version is far more strict on checking JavaScript syntax. If you have poorly-written JavaScript in a plugin or your WordPress theme you will often see this manifest as a [href#] syntax error in the browser debug console.
Missing source maps files (the .css.map) file is a non-issue. It is a debug info notice for some browsers that process source map files. If you run a source-map-aware browser in debug mode (web console is open for example) the browser will scan all source files including the css file for the /*# sourceMappingURL=… */ line and then go and look for that source file. Since neither the source nor the map file are included in production releases of our product (nor should they be in most production release products) you will see the 404 error.
The TableSorter jQuery library is trying to sort your results table on the 5th column. Normally this will be the number of results returned. I read the source and by default this outputs 5 columns. Unless there is another error in your WordPress debug.log file I suspect something else is tampering with the results report table either before or after it is being output to the browser.
I’ve added a patch to be released in the next version of the Power add-on. You can replace the /wp-content/plugins/slp-power/js/reporting.js file with the version attached to see if that helps. It should eliminate the jQuery error but I’d still be suspicious of why your results table is not showing 5 columns.
Some of these have been fixed in 4.6.3 of SLP and various add on packs.
If you can share the full debug.log by uploading here or providing your site URL that would be helpful.
You are not running with WP_DEBUG turned on with a live site, correct? Those messages are for internal logging if the code generates incorrect text but will not appear unless you are running a site in debug mode.
Cluster markers is purely a visual aid and does nothing to impact searches. It groups markers that are close together on the map grid into a single graphic image.
1) Make sure you are on 4.6.3 of SLP + Power + Experience ; there were some updates in Power and Experience that changes the discrete filter on city/state/country. It likely won’t address the issue but it helps with possible “bug hunting” to know you are on the latest version.
2) Your settings for things like “State Selector” are very important in determining how future searches are handled. [slplus state=”X”] will filter on the initial page load. What happens AFTER that depends heavily on your settings.
If you do not have the selector set to hidden then whatever the drop down menu has selected will be the new state selection sent to the back end. This is by design for sites that only want to filter the initial results but not restrict users to ONLY a specific state.
Other things affect the results as well including the radius selector and radius selections set by default.
First things first though – update to the 4.6.3 or newer releases and report back. Provide the exact URL to your locator page as well as a “then enter XYZ in the search box and click find”. Tell us what you expect to see versus what we will see when we repeat those steps.
Version 4.6.3 fixes a bug introduced in SLP 4.6.2 where changing the Plugin Style was not changing the layout properly.
Update SLP and Experience to 4.6.3.
SLP 4.6.3 will also fix the issue if you are using Enhanced Map/Search/Results Legacy releases.
There is a patch coming in SLP 4.6.2 for that issue.
The problem is the function used in the SLP 4.6.1 code is only available in WordPress 4.4 or higher. The 4.6.2 patch for SLP replicates the code for that broken function within SLP itself. Not a great way to do things for performance reasons (re-inventing the wheel) but to maintain compatibility with older versions of WordPress the extra overhead needs to go into the SLP code.
As an aside – if you need assistance ferreting out the problem we do offer WordPress consulting services for non-SLP issues via Cyber Sprocket.
The map is not loading because your target location pages are full of JavaScript errors. These errors are preventing the page from ever reaching the Store Locator Plus code that loads and manages the map.
Use your web browser developer tools and look at the “console” item in developer tools. You will see dozens of errors any number of which may be forcing the JavaScript to stop early.
Example:
http://frsteam.com/store-page/frsteam-of-virginia/Errors:
SyntaxError: missing ] after element list in core.js part of /gre/modules/commonjs (not part of SLP)DOMException in tidyUtil.js (not part of SLP)
Connection closed on your listener for the Promise backend (server likely timed out due to service failure, not part of SLP)
Inline error “initMap is not a function” (not part of SLP)
In addition you have an expired Google Maps Key loaded somewhere. Maybe part of your rogue map plugin/theme that you have living beside Store Locator Plus.
[caption id="" align="alignnone" width="1081"]
FRS Team JavaScript Failures[/caption]IMPORTANT:
“You have included the Google Maps API multiple times on this page” indicates that you have another plugin loading Google Maps (or your WordPress theme is doing so). SLP will only load the map source ONCE on any page is manages. You can turn OFF Google Maps within SLP if they are provide by your theme or another plugin in order to avoid conflicts, but I cannot guarantee that your theme or other plugin is loading the correct version of Google Maps and thus cannot guarantee it will perform as expected.
My recommendation : figure out what plugin or theme element is loading Google Maps and make it stop doing so on your SEO pages like the one noted here.
Oh – and the icon packs are no longer supported in the latest version of SLP. They have notable issues that impact locator performance. I plan on launching an improved version using a subscription service for SLP icons for Premier customers as part of the Premier plugin but there is no ETA for that service. In the meantime download the icons you need put them in the WordPress Media Center and reference their URL directly wherever you set the icons in the locator.
Dennis –
I am still working with WPML on compatibility. At the moment we are at a “it should work” moment from WPML. I am now tracing through how their gettext() processing is working so I can tell them why their “should be working” system is not working. Since I do not know their code nearly as well as mine it is taking some time.
One thing we have discovered is the for some reason SLP is only working on translating strings if a COMPLETE language file for the alternate language is present in your Store Locator Plus languages directory. If your main site is English and you use WPML to switch to Spanish (or Dutch or Italian) you will need the complete Spanish (or Dutch or Italian) language file in place for WPML to show the proper text.
You can use the free Loco Translate to create and save the alternate language files. If you do create a new complete translation that we are not shipping with the product, please send us the .po and .mo files and that way they will be present next time you upgrade SLP so you do not have to recreate your work.
Documentation on Loco Translate as well as some of the WPML compatibility is here:
https://docs.storelocatorplus.com/?s=translationOnce we figure out why WPML cannot translate the static strings in the product we are going to work on making things like the “Find Button Text” and “Search Label”, which are stored in the WordPress options (admin settings) translate consistently. At the moment sometimes WPML translates the strings but sometimes it does not. Very aggravating, especially when they are only telling me “well, it should work”. :/
I will get it working. Eventually. Hopefully soon.
Thanks for your patience.
Dennis –
I am still working with WPML on compatibility. At the moment we are at a “it should work” moment from WPML. I am now tracing through how their gettext() processing is working so I can tell them why their “should be working” system is not working. Since I do not know their code nearly as well as mine it is taking some time.
One thing we have discovered is the for some reason SLP is only working on translating strings if a COMPLETE language file for the alternate language is present in your Store Locator Plus languages directory. If your main site is English and you use WPML to switch to Spanish (or Dutch or Italian) you will need the complete Spanish (or Dutch or Italian) language file in place for WPML to show the proper text.
You can use the free Loco Translate to create and save the alternate language files. If you do create a new complete translation that we are not shipping with the product, please send us the .po and .mo files and that way they will be present next time you upgrade SLP so you do not have to recreate your work.
Documentation on Loco Translate as well as some of the WPML compatibility is here:
https://docs.storelocatorplus.com/?s=translationOnce we figure out why WPML cannot translate the static strings in the product we are going to work on making things like the “Find Button Text” and “Search Label”, which are stored in the WordPress options (admin settings) translate consistently. At the moment sometimes WPML translates the strings but sometimes it does not. Very aggravating, especially when they are only telling me “well, it should work”. :/
I will get it working. Eventually. Hopefully soon.
Thanks for your patience.
Dennis –
I am still working with WPML on compatibility. At the moment we are at a “it should work” moment from WPML. I am now tracing through how their gettext() processing is working so I can tell them why their “should be working” system is not working. Since I do not know their code nearly as well as mine it is taking some time.
One thing we have discovered is the for some reason SLP is only working on translating strings if a COMPLETE language file for the alternate language is present in your Store Locator Plus languages directory. If your main site is English and you use WPML to switch to Spanish (or Dutch or Italian) you will need the complete Spanish (or Dutch or Italian) language file in place for WPML to show the proper text.
You can use the free Loco Translate to create and save the alternate language files. If you do create a new complete translation that we are not shipping with the product, please send us the .po and .mo files and that way they will be present next time you upgrade SLP so you do not have to recreate your work.
Documentation on Loco Translate as well as some of the WPML compatibility is here:
https://docs.storelocatorplus.com/?s=translationOnce we figure out why WPML cannot translate the static strings in the product we are going to work on making things like the “Find Button Text” and “Search Label”, which are stored in the WordPress options (admin settings) translate consistently. At the moment sometimes WPML translates the strings but sometimes it does not. Very aggravating, especially when they are only telling me “well, it should work”. :/
I will get it working. Eventually. Hopefully soon.
Thanks for your patience.
Google is now (as of a few days ago) requiring API keys on ALL map requests from any domain that has not had a map request in the past few months.
That means EVERY SINGLE NEW WEB ADDRESS where you place a Store Locator Plus map will need to have a registered Google API key. They key is free but they only allow so-many page loads per day before you have to start paying for map loads.
I saw the writing on the wall over a year ago when they “suggested” getting an API key. It was more obvious in the past 6 months when you started seeing “No API Key” warnings in all JavaScript calls if you did not enter a valid Google API Key under Store Locator Plus General /Server / Google Server API Key. Then last week they turned that warning into an error.
I’ll be updating SLP to be more obvious about this, but the short answer is that you must now have a Google API key registered for every website.
I am only working on the base plugin WPML compatibility at the moment. There appears to be a number of challenges to getting WPML to work properly; at least when using the documentation they provide. I’ve sent them a detailed description of the technical issues and am awaiting a reply.
Only Power, Experience, and Premier will be updated at some point in the future to be WPML compatible. It is far too much work jumping through WPML technical hoops to go back and port all the older add on packs.
In the meantime the latest SLP 4.5.07 prerelease is available for free from the SLP website:
https://wp.storelocatorplus.com/product/store-locator-plus-prerelease/
Also read this:
https://docs.storelocatorplus.com/blog/using-language-files-to-help-wpml-with-gettext/
Short version: You must have a complete language file for your alternate languages presented on your website front-end with WPML. If your site is in English and you want to provide Spanish translations for things like “no results found” you must create a Spanish version of your page with the [slplus] shortcode AND make sure the Spanish language files are up-to-date with the latest version. I use Loco Translate to first Sync and then use Google Translate to fill in any missing translations.
Once WPML starts answering some of my half-dozen technical questions I can start working on more complext issues.
Currently SLP 4.5.07-beta-02 appears to be changing the UI elements of the base plugin such as the radius drop down entries (“10 miles” to “10 millas” for example) and the Find Locations default text on the find button.
4.5.07-beta-03 (not out yet) will also tell Google which language is being used to view the page with the [slplus] code and will change the Google Map Elements (“satellite/map” and copyright and town names) to match the selected language.
Still waiting to hear back from WPML on how to make things like user-settable labels like “Search Labels (Experience / Search / Search Labels)” settings like the Address Label and Radius Label translate on-the-fly without incurring the TRIPLE execution speed performance hit (it is 3x slower loading the page if I use their register/translate string filters).
Please test and give feedback based on translation issues with the base plugin. I’m planning to publish an updated WPML friendly release of the base plugin version 4.5.07 production by Sunday AM.
If it helps, I noticed a few things when analyzing this url:
https://www.thegraciousgourmet.com/retail-locator/1) Your location data does NOT specify the protocol.
For example: http://www.ourhandmademarket.com is the URL for Our Handmade Market.
If you enter http://www.ourhandmademarket.com in the URL field it should prevent mangling of the URL.
2) The SLP location processor uses the WordPress esc_url() function to get a proper web link from that URL field.
The function will NORMALLY always prepend http:// as the protocol. You can see the function reference and source here:
https://developer.wordpress.org/reference/functions/esc_url/#source-codeHowever any plugin/theme can change this a number of ways, the most common being via the ‘clean_url’ filter built into WordPress.
I am guessing that you have a plugin or theme component that is using clean_url to improperly apply the https:// protocol any time something on your site uses the esc_url() WordPress function.
Let us know if you need more assistance regarding this matter. Hopefully the above info will give you the insight you need to get this resolved.
I cannot reproduce this issue on any of the test systems running on an https:// protocol. The destination link remains with the original http:// protocol in the URL.
I’ve tried this with my locator site set via the WP General Settings to have a url with http://localhost/ and https://localhost/ for the WordPress Address and Site Address.
I’ve also tried this by specifying http://www.
.com and www. in the SLP location data for the website address. In either case the http protocol is used by default. The ONLY way I can get the link in the location listing to come up as https is if I specify it as https.
There are ways within WordPress to force SSL URLs using WP hooks and filters. It may be that a non-SLP plugin is changing your URL processing rules and forcing https on ALL content including the JSONP response coming back from the WordPress AJAX processor. Hopefully that is not the case, but it appears that the problem may not be within the Store Locator Plus codebase.
What is your website URL so we can see this in action on your site?
If you do not want to publish it here please email support @ storelocatorplus.com.
As an aside, SLP 4.5 now has an “apply to all” button. Select delete from bulk actions on the manage locations tab then click “apply to all”. It does the same thing as Janitor delete locations.
As per the email response, posting here as it may help others:
you replied
If I search Chicago IL within 500 miles I get a list of locations back from the server.
The map markers are not displayed. The marker is set blank. There are a few ways this happens:
1) The default marker is set to blank, not set, or set to a URL that is not valid/available to the public.
Go to the Experience / Map tab and make sure your map marker is set properly. Copy the marker URL into a new private browser window and make sure it loads in private mode to test that is is readable by the general public.
2) The category marker is set to blank, not set, or is an invalid URL. The category marker takes precedence over the default marker unless “Use Default Markers” is set under the Tagalong tab.
Go to the “Category Manager” on the Tagalong tab and check the markers/icons assigned to each category using the same method as above.
I also noticed the “search by tag” field is displaying, the second entry box on your search form. Not sure if that is intentional. You can turn it off if desired via the Experience/Search tab. If you want to keep it you may want to consider prefixing it with a label.
Make sure you have SLP 4.5.01, it should be the version sent out from WP Update not version 4.5.
Provide your plugin environment AND the direct URL to your live site running under WP 4.5. Or spin up a WP Engine staging site and upgrade THAT to 4.5.
Most likely you have another plugin, not SLP, that has a broken JavaScript file when it runs under WP 4.5.
The Google Maps No API warning is a non-issue. You can get an API key and put it in under the General / Server tab but it is not necessary.
One of your scripts loading on the page is disabling all web console output. Disabling the console logging is a neat way to hide errors and warnings in code, but it is stops virtually all problem debugging when you find some JavaScript is not loading, like the Google Maps loader. Which is exactly what is happening on your site.
Something in JavaScript is breaking. Unfortunately one of your plugins or themes decided it is better to hide JavaScript errors which means we have no way of telling exactly what broke. Maybe a SLP script, but probably not.
If you can figure out what plugin (or WP Theme option, or CDN / cache / minification process) is doing that we can probably help you figure out what script is breaking in WP 4.5.
SLP is fully tested in WP 4.5. I have contributed to 4.5 (and 4.4) WordPress Core and have been testing the 4.5 release for nearly 4 months through each-and-every iteration while developing updates for my plugin.
If you don’t have a way to figure out which plugin is disabling logging you’ll need to do the one-at-a-time deactivation until you see real console logs in JavaScript and/or the SLP map re-appears.
I like Divi theme, but there are literally thousands of themes that work well with Store Locator Plus. Maybe it is time to start a new post on this site that lists some of the themes we know of and have tested and allow users to comment on their theme experience.
BTW, make sure your WP site is not blocking WP REST API.