Forum Replies Created
-
Posts
-
Someone added custom CSS rules to your site.
Look in the theme Custom CSS or under Store Locator Plus > Settings > View additional CSS.
This rule is pushing the button to the far left:
flex-direction: row-reverse;Removing that will put the button on the left. You can set right padding to adjust as necessary.
Whomever is editing your CSS seems to have a clear understanding of CSS rules and should be able to handle this for you.
The directory listing does not work that way.
If you need to add additional parameters to your directory output to limit it to X locations and/or auto-detect the users location while in DIRECTORY mode it will require custom coding.
The location sensor is a Google Maps specific thing that requires the map to be active, present, and displayed to grab a user’s location data. It also requires you are on an HTTPS site and the user has allowed the data to be sent. If you have a page with no map displayed it will not work.
The directory builder, is NOT tied directly to the Google Maps interface. It uses the Store Locator Plus location database to build the lists. It does NOT talk to Google Maps at all. Therefore it has no way to detect the user location.
We could probably create a non-Google Maps solution for this but that will require customization. If you would like us to quote a time estimate we can do that but be aware customization purchases are only available to Premier members. All customization work is at least 1 code-day at $500 , something like this is probably in a 3-4 day range. We won’t know until we research this in more detail.
Ben – Power is not breaking your search. It is enabling categories and since you have set your site to FORCE a category by removing the “Any” option it is going to automatically filter your list to the first category on the drop down.
If you’ve set the center of your map ( Settings > Map > Center Map At ) to the United States and set your initial radius ( Settings > Search > At Startup > Initial Radius ) to 100 miles and have turned off the “Any” (show all) option on the category drop down you end up with this on the first map load:
Show me all locations within 100 miles of the center of the USA that are in the category “ABC – First Category”.
Now if someone enters their zip code and you have the radii options default ( Settings > Search > Radii Options , the default is in parens) set to 200 miles and STILL have that forced category then someone typing in 29464 as their zip is going to get:
Show me all locations within 200 miles of 29464 that are in category “ABC – First Category”.
I have been working with a number of clients the past week on various customization and support retainers that are using categories and Power 4.9.1 + SLP 4.9.2 without any issues.
Maybe the issue is in Power 4.9.1 but I’m guessing it is your configuration you’ve put in place not the software itself.
Jaap –
Maybe SLP 4.9.1 searches broke something on your site but I cannot even start debugging it on your site. The SLP location search code isn’t even running after the page first loads because the Recaptcha bug is stopping the SLP search code from running. That makes it impossible for me to look at how the search is working on your site.
Try disabling/fixing the broken JavScript code from your other plugins/themes first. Start by disabling any plugins or theme options that enable Recaptcha. Since it looks like custom code, it may be baked into your theme.
As outlined in my latest article and video, if ANYTHING breaks in JavaScript before the SLP code runs then the SLP map search will not work. This is because JavaScript loads in an indeterminate order. That means that today your page may run the SLP code BEFORE Recaptcha but tomorrow it may run the Recaptcha code first. There are a million variables that affect this.
My guess is something else updated besides SLP from 4.9 to 4.9.1. Maybe you did not explicitly perform an update but something is different besides SLP. Maybe Google’s Recaptcha library updated and broke your custom Recaptcha code. Maybe WordPress did an automated security update that changed the order the scripts loaded (did WP update from 4.9 to 4.9.1 as well?). Or Maybe your plugins auto-updated, many do especially if you you services like Jetpack and a dozen other security plugins.
Start the process of getting the other errors fixed so I can at least see our SLP search code running and then I can possibly hunt down any SLP 4.9.1 bugs.
Hi Jaap –
I assume this is the locator page: https://www.alpha-audio.nl/hifi-audio-winkels/?addressInput=netherlands
First – awesome job on the styling! I may need to have you send me come CSS skills to I can create some nice-looking Plugin Styles like that!
What I tried:
- https://www.alpha-audio.nl/hifi-audio-winkels/
- Allow Location Detection
This put me in Charleston SC with no locations. I’m guessing that is correct as I’m thinking you have no locations in this area.
- Type in Netherlands in the address and set distance to 200km, click Find Locations.
- Locations show up near Harleem.
I then tried to zoom out on the map because my knowledge of local towns/cities over there is “typically American” in that I could not name one. But the Google zoom out is broken.
Because the core Google functionality is not working I’m guessing something is seriously wrong with the JavaScript (or possibly CSS if you have layers/divs set incorrectly).
In Safari I go to the Develop | Show JavaScript Console (you’ll need to enable Developer Tools in preferences first to see that menu) and I can see the JavaScript errors on your site. All modern browser have an equivalent to Developer Tools and the JavaScript Console if you’re interested to see the errors yourself.
Since SLP requires a fully loaded and functional JavaScript environment to operate properly , you’ll need to fix these fatal errors in other plugins/themes to get it working again.
- Error: ReCAPTCHA placeholder element must be an element or id
- ReferenceError: Can’t find variable: socialRHSHide
Sorry – those debugging lines do not go in wp-config.php – that was not clear.
Add these 2 lines right above the line that originally caused the error: store-locator-le/include/SLPlus.php on line 401
error_log( ‘SLP->dir: ‘ . $this->dir );
error_log( ‘SLPLUS_PLUGINDIR: ‘ . SLPLUS_PLUGINDIR );
If you are not using opCache and it is a lowercase directory (Linux/Unix doesn’t care about file/directory case sensitivity but our autoload does which is why lowercase is important) then I’m guessing something is causing $this->dir and SLPLUS_PLUGINDIR to not be set the same way.
If you can add those lines and let me know when the debug.log is on your site (or you can attach it again here) it will tell me if that theory is correct.
Something on your specific configuration or server setup is messing with how our autoload works, but it is odd it is only affecting the REST file. A LOT of things in the SLP 4.9 release use autoload now as it is cleaner, faster, and easier to maintain over item (less security holes and breaking things between releases, which I’m sure everyone will like). Why it only seems to impact the REST file on your setup is odd. 😕
Tony –
Can you send an email to support@storelocatorplus.com and provide an admin login to your site.
I’d also like to have permission to turn on debug mode on your site, but it may output some PHP coding messages on the live site if any of your plugins or themes have issues. It will be temporary but since your site is live customers may see that while looking into possible issues.
As for checking things out, the first step is to see if the location CSV file made it into your media files list. The location import now stores the uploaded CSV in the standard WordPress uploads so it now appears there as a location CSV file.
WordPress Media showing a locations file from my test site:
If the file is NOT there that means you either do not have permissions to upload files to WordPress (unlikely if you can get to the import tab) or the built-in WordPress media uploader has been disabled.
If the file IS there you can click on it to see if the file is being processed by WordPress. On the file details you will see on the top right side the current status of the file. It should say Data Type: location_csv and a status. In my example below the file has been processed and shows all 9 records loaded. If it is NOT being processed you will see that in the status and the current file offset will appear showing how far it is through the file.
My test file AFTER being loaded: Status = Processing complete, current offset not shown, Records Loaded: 9
Offset 0 means your background processor in WordPress (WordPress Cron) is not running. You can try to force it to run by adding /wp-cron.php to your website address in your browser. For example:
https://rocktape.com.au/wp-cron.php
Reload that media page by clicking Media in your WordPress admin panel, then click on the file to see the details.they only update when the media list first loads so make sure you’ve clicked Media in the admin page again even if you are already on the page.
Look at the file details, if it is no longer stuck at “Offset zero” then something on your site, usually a security configuration, is preventing scheduled tasks (WP Cron) from being started from a WordPress plugin. This should be a non-issue for a public site with any traffic.
If “kicking WP Cron in the backside” didn’t help by going to that wp-cron.php page (it should come up with NOTHING, a blank page is correct) then something is preventing WP Cron from running. You can tell if the file details stay stuck on offset 0. If that happens either someone on the tech team managing your site has turned OFF WP Cron processing completely (some website management/dev shops do this) OR a plugin/theme is breaking when Cron runs due to a coding error. Turning on WP_DEBUG is the easiest way to catch coding errors like this but it can output some ugly messages on the public site when in debug mode (it can be turned off once the debug log is created when you try to access the wp-cron.php URL again while it was on).
The require is no longer be necessary at SLP 4.9 uses PHP’s autoload.
1) Check your install
Can you verify that in your plugins directory the path under store-locator-le is /include/module/rest/ (lowercase) if not then something is not allowing your normal plugin install to execute normally.
The CORRECT path is a lowercase REST. If it is uppercase then autoload will not work.
A normal plugin install should be clearing the entire store-locator-le (Store Locator Plus) plugin directory on an update so any uppercase REST directory should no longer exist.
2) If the path is correct you can help me by adding some debugging on your install
Since you know how to edit code can you enable the WP_DEBUG log in your wp-config.php file and on line 100 add these 2 things and let me know what shows up in your log file:
error_log( ‘SLP->dir: ‘ . $this->dir );
error_log( ‘SLPLUS_PLUGINDIR: ‘ . SLPLUS_PLUGINDIR );
They SHOULD output the same thing. If it does then something special is going on with your server to prevent autoload in SLP 4.9 from working properly.
PHP’s autload will load the file from the correct directory UNLESS something else , another plugin or your theme is break PHP’s autoload functionality. Something that is easy to do if a plugin author does not check that the autoloaded object belongs to them BEFORE executing their own autload function. WordPress Core uses autoload , with the proper control structure, as do several other major plugins so the methodology is sound as long as every piece of your installation does it properly.
3) If all these things check out the only thing I can think of is you have opCache (or another PHP object cache) running on your site, but given the line number of your error message that doesn’t appear to be the case.
You are talking about this site, correct?
https://sienna-x.co.uk/help-support/therapist-locator/1) There is no Google API key. Make sure you put it in the browser key entry in SLP. This is what comes up looking at your JavaScript on the page:
Google Maps API warning: NoApiKeys https://developers.google.com/maps/documentation/javascript/error-messages#no-api-keys2) Your plugin/theme running Lightbox is breaking JavaScript for the entire page.
jQuery(‘.responsive_lightbox’).lightbox is not a function. (In ‘jQuery(‘.responsive_lightbox’).lightbox()’, ‘jQuery(‘.responsive_lightbox’).lightbox’ is undefined)Store Locator Plus does not use Lightbox.
Since this is a fatal error all JavaScript code from that point on stops running.
The locator processing runs AFTER the entire page loads, so when something like this breaks the locator interface can no longer function properly.
If you look at the JavaScript debugging on your site it is coming from a minified JavaScript file that is using ColorBox.
/*!
Colorbox v1.5.10 – 2014-06-26
jQuery lightbox and modal window plugin
(c) 2014 Jack Moore – http://www.jacklmoore.com/colorbox
license: http://www.opensource.org/licenses/mit-license.php
*/
You need to fix whatever else you updated first and get rid of that error.
Ran testing with SLP 4.9.1 and Power 4.9 on several languages and the Store Pages custom post type is showing up if Enable Pages is on for a default install and on some legacy test sites we are running.
Spanish, for example, has no translation files at Translate.WordPress.Org or available locally for the Power add on and had no issues with the Pages interface.
Check to make sure the pages are still enabled in the General tab and that you are logged in with a user with the proper capabilties.
Are you still seeing OVER QUERY LIMIT when you try to add a location?
If so then your API key is not being honored or it is not setup properly.
Found the error. It will be fixed in 4.9.2 which should be entering testing and out this week/weekend assuming all goes to plan.
The secondary tabs being blank is fixed in SLP 4.9.1 and has been verified as such by several users running non-English sites including SV_se, and NL_nl i18n domains.
You should be aware that Google Map services has again increased their restrictions, so having a Google API key is even more critical than it was a month ago.
Much like their push to make all sites have an HTTPS URL with a valid SSL certificate.
Anyone running a map on their site, whether with SLP or any other plugin, should be on HTTPS and have a Google Maps API Key. If not you may not have problems today but it will become an issue over time as Google tightens up their security and access policies.
Your over limit error is because your site has used up all 2,500 Google geocoding queries assigned to the server for the day.
If you are on a shared host the limit is shared between all sites on that server. For a GoDaddy server, for example, there can be 30,000+ sites on a single server.
Get a Google API key and make sure you sign up for pay-as-you-go services from Google to avoid hitting this limitation.
https://docs.storelocatorplus.com/blog/getting-started/Step 1: Go To the Google Developer Site
Step 2: Select “Create A Project” at the Google API Keys
Step 3: Enter your website info at Google.
Step 4: Copy your API Key.
DO NOT add any restrictions by website address, IP address, etc. despite what Google tries to talk you into. That will hamper the key functionality.
Make sure you are not using a localized language file or if you are that it is setup properly. It is recommended you use the WordPress Translate site for translating the base plugin. For the Power add on you will need to make sure the language file is complete and matches any translations in the base plugin.
Also make sure you are using SLP 4.9.1 which patches a language issue when switching sub tabs and that you have cleared and localized caching especially if you are using opCache.
If you have Pages enabled with Power addon via Settings | General | Server |Enable Pages the sidebar menu should appear. That is handled by WordPress via a standard custom post type configuration. You’ll also need to make sure you have the proper permissions to manage custom page types. That means you have manage_slp_admin in your capability list. It is added automatically for admin level users only.
Also coming in SLP 4.9.1
* NEW FEATURE Settings | General | Admin | Messages | Enable WP DEBUG to enable the WordPress debug log to help catch late-process coding errors on your site. This will also allow people to see why a URL is failing like those that create the map marker warning.
Is your site behind an extra security layer such as a staging/dev site with an extra authentication layer like basic auth?
If so the utility that checks that the file exists cannot get authorization to retrieve the marker as it uses a generic web request to check the marker is available to the general public. It does not account for systems behind basic authentication sites.
If your CA files check out that is the problem.
SLP 4.9.1 has extended error logging, you’ll need to enable WP_DEBUG to see it in the log files, that will help provide clues as to why a URL the plugin is validating is failing the validation.
Give me the URL to your image and I can check it from our servers.
If you have command-line access to your host you can use a direct get or curl command (Linux/MacOS – you’ll need Windows bash tools if you are on a Windows host).
For linux/MacOS:
# wget ‘<your marker url>’
This will uncover errors your browser may be hiding.
If you are seeing that notice pop up it is because WordPress is getting an error or security warning back from the marker URL. In either case some users, depending which browser they are using, will NOT see the markers which is why we use that WordPress core utility to test markers and report it on the admin panel. That test was added after chasing down a “my markers are not appearing for some users” issue reported back in 2013. The warnings are there for a reason.
@Dan – thank you for the report. I was able to find the changes in SLP 4.9 that are causing the problem. Some of the code that I added to 4.9 turns out to be supported with PHP 5.4+ only.
I am working on the SLP , Power, and Premier 4.9.1 updates that restore PHP 5.3 compatibility. I hope to have those 3 updates out within the next few days.
For our PHP 5.2 users, unfortunately we can no longer support that release of PHP. We are using a new architecture based on a PHP function that was added to PHP in February 2012. That change in SLP 4.9 means sites using PHP 5.2 can no longer use PHP.
For all users, you really should be on PHP 5.6 at a minimum. There are literally dozens of security patches in PHP between each point release (5.2 => 5.3 => 5.4, etc.) some of which are significant.
For reference, here is the PHP Version Release History. Supported until means the last date the PHP language was fixing problems and patching security holes.If your host is not allowing you to upgrade to a newer release or a WordPress plugin or theme breaks on PHP 5.6+ you should ask why. WordPress (and Store Locator Plus) run perfectly well on PHP 7 which is the current recommendation from WordPress due to the notable performance improvements in version 7.
Try pasting the marker URL, exactly as it appears, directly in your browser then check the certificate details from your browser.
If the marker appears then it is very likely due to the fact that your web server is getting a security certification violation. This happens most often because your server has not been updated with the latest intermediate certificate authority (CA). Since Symantec sold their SSL license business to DigiCert due to questionable authentication practices ALL web servers (and laptops, phones, etc.) must update their Intermediate CA files. If your server is NOT updated then WordPress will generate an “untrusted certificate” error when checking a web resource that lives on a server without the latest security patches.
Why does this matter? Store Locator Plus uses the built-in WordPress “check this web address is valid” function to validate that a URL you used for a map marker points to a valid image that can be server remotely to ALL your site visitors. Keep in mind some browsers skip over security warnings, some flag them, and some block the offending resource which means no markers will appear for those users.
When you see the warning pop up on our admin panel about a bad marker, WordPress is reporting an error when trying to get the map markers. Typically it is something simple like typo and when you try to paste the marker URL in a new browser window it comes up with a 404 “not found” message. However, since this great new SSL certificate debacle that impacts hundreds-of-thousands of servers has come about we are seeing reports of long-valid map markers being reported as invalid by WordPress. So far it has always been a now-invalid SSL setup on the server where WordPress has been installed OR the server from which the map marker is coming (usually the same thing).
We had this happen on a few of our own servers. We found our installed SSL certificate did NOT have the updated intermediate CA information. When we updated our certificate to be compliant with the new November 2017 root and intermediate certificates everything was back to normal.
Check to make sure you have all the latest security patches installed on your host. If you do then make sure you’ve updated all your Let’s Encrypt certs as well as the supporting cert-building libraries or you’ll end up with a self-issued certificate linking to the old Symantec servers as an issuing authority. All Symantec-based certs not redirecting to Digicert are quickly being marked as a security risk and/or invalid.
Also, if you are pulling images from an https-backed server make sure the marker URL starts with https otherwise some users will get an ‘insecure resource’ warning in their browser.
As an aside, the map marker test has been in Store Locator Plus since SLP 3.0 (2013) and has not changed. If you are seeing the message now it is not because SLP changed. It is because WordPress is now reporting issues with possibly insecure content as part of their ongoing focus on security improvements.
This happened sometime in the past couple of releases. We are not sure yet if it was with the WordPress update or SLP update.
We are working on a patch to SLP so that the admin tabs do not lose content when using a non-English site. Changing the site to English (or your user) will bring back the tab content until we figure out what needs to be patched.
We expect to have an SLP 4.9.1 patch out in the next 7-10 days, immediately after our Power 4.9.1 update is released.
Make sure your install has not disabled the default WordPress media uploader.
SLP 4.9 now uses the built-in file uploader provided by WordPress Core instead of a custom file import script. First thing to look at is the Media Library in WordPress. Do you see the CSV file you just imported? If not then your site has disabled the WordPress media uploader. Since you said the prior release worked I am going to rule out your AJAX functionality being disabled as both the WordPress default file uploader and our previous custom script did the same thing.
If the file is there, click on it. It should show you in the file meta what the file size is and the current offset. The offset is where the background process is while importing the file. If it is at zero then y our WordPress Uploads directory for the media library has been set to non-standard restricted access meaning the background location import process is not allowed to open the file after it was uploaded.
With SLP 4.9 the import is a 3-part process. Step 1 is the ONLY interactive portion with the browser where the file is read from your system and uploaded to the WordPress site.
Step 2 is where a background process, using WordPress Cron, reads the uploaded file and starts importing the locations WITHOUT geocoding them (yet).
Step 3 , after the import is loaded into the location list a similar background WordPress Cron process starts geocoding the locations. Since this is typically the slowest part of an import as your server needs to talk to the Google Servers this prevents the import of locations from stopping before it gets all the locations in the database.
If your file IS in the media library but never gets off the offset 0 setting then your server very likely has WordPress Cron disabled or is preventing the wp-cron.php from being triggered programatically. We do that so that sites with low-volume such as staging or local tests sites still import locations without waiting for someone to interact with the admin or front-end pages and trigger the Cron job.
This was done to allow large file uploads (10,000+ locations) on smaller hosts or even moderate size imports (600+ locations) on severely underpowered hosts. It is amazing how many people try to load 10,000 locations into a $10/month GoDaddy site. It is common enough that people would get half-imported files because their server would die before it could finish the job.
We are still updating the documentation to reflect the new import process and should have that out within the next week. There is also an update to Power version 4.9.1 that has an improved interface for import notifications showing the import progress and geocoding progress in real-time so you know how far along both processes are without looking at the media library.
Check into the media library and offset issues and let us know what you find.
Try SLP 4.9 with Power 4.9 and let us know if it resolves the issue.
1) You need to specify a complete Font Awesome class reference. Throwing fa in front of something is not a font awesome class specification. You need to specify an icon part of the class as well. For example:
http://fontawesome.io/icon/bandcamp/2) If you are going to use FA styling in the SLP results you are going to need to make sure your theme is supporting it and loading it on all pages or get a plugin that will load FA on all pages for you.
NEVER edit SLP code for anything unless you want to break your upgrade options. We also cannot provide support on edited code installations.
You can do what you want by updating the Results Layout setting via SLP | Settings | Results | Results layout and learning a bit about how Font Awesome works. The other option is to put basic HTML image tags in place, though a CSS/Font-based solution will be much faster and more scalable for different screen resolutions.
I would start by throwing a verbatim example from the SA site for an icon into results layout and getting that to render first. That will let you know your page is loading the FA library properly, which is a function outside of SLP. There are far too many font and CSS frameworks to start randomly loading all of them up on every SLP page, thus we leave it to the WP Theme or other plugins for users that want to extend the look & feel of the SLP UI with those libraries.