SLP not Functioning with Most Recent Update

Home Forums Store Locator Plus SLP not Functioning with Most Recent Update

This topic contains 8 replies, has 5 voices, and was last updated by  Lance Cleveland 2 years, 5 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #28019


    Since updating the plugin and updating wordpress to 4.1, SLP is not working for me. No matter what, it says, “No Locations Found.”



    I am having a similar problem. The results are displaying about half of my locations. What can I do?



    I am having the same problem as well. Will there be another update soon to fix this? It seems to be a problem quite a few others are having. I am getting calls from our dealers wondering why they are not showing up. Please advise.


    Lance Cleveland

    Please provide an example search request and what you expect for results.


    Screen shots of your search entry and the relevant location from the admin manage locations page would help.



    I cannot get tagalong to work. When I enter the code [SLPLUS only_with_tag=”jade”] it shows ALL locations, not just those tagged with “jade”

    It was working before, before the last update. I tried using the pre-release, and it’s not working either.

    I installed TagAlong and pretty much all of the other plugins. I thought maybe it was my theme, but even with the default 2015 WP theme, the filtering isn’t working.



    Just came back to report that SLP 4.2.31 works with Tags just fine. Seems something happened with the newer versions. Lost a lot of hours figuring this stuff out, but I still love this product anyway. It’s really great. I hope my post helps someone else and that you can figure out what the cause is.


    Lance Cleveland

    It may be related to the private location listing marker.  Some versions of MySQL are setting the boolean field to NULL instead of true/false or blank.

    Please try the latest prerelease and let me know if this fixes the issue.

    I cannot reproduce on any of my test systems unless I forcibly set the privacy field to NULL so I am not certain the upcoming patch fixes the issue.

    The prerelease is available for free here:


    This is NOT a production release.  Make sure your system is backed up before using this on a production website.



    BTW, only_with_tag is a Pro Pack shortcode attribute.  only_with_category is used with Tagalong (confusing, I know, eventually Pro Pack tags will move to Tagalong).



    The issue came up again, seemingly random (without me doing anything). So I started thinking…I’m on a virtual server with lots of load balanced MySQL servers, maybe one of them is out of sync?

    So I reinstalled your current production version, and then I used you janitor tool to rebuild the database….and it worked!

    I realized that it broke when I upgraded to the current release. I don’t think it’s the private location issue because the filtering stopped working <b>before</b> I tried using the private feature (which I used only out of desperation).

    Now that I have used the product more, I’ve noticed that it doesn’t always display my custom marker even though it appears in the backend. I resolved it by replacing the default image on FTP. I know that’s a separate issue but I just thought I would mention it.

    The janitor plugin is quite useful. Thank you for making it free and easy to use.



    Lance Cleveland

    The latest version of SLP, 4.2.38 , addressed an issue where some MySQL installations — especially legacy installs — had marked the privacy flag as NULL.   NULL was the default value for boolean fields for older legacy MySQL installs that carried forward even if people upgraded MySQL.  Newer installs typically set a boolean field to blank (or false) which is why newer entries would show up but older ones would not.   Same thing if you edited and saved a location.

    This private location field has been in the database, unused, since its inception 3+ years ago.   The latest code assumes NULL values for that field mean the location is NOT private, which is how it used to behave prior to the 4.2.36 release.

    Hopefully this fixes the issue.


Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.