New SLPLUS_PLUGINDIR apparently uses the wrong path

Home Forums Store Locator Plus New SLPLUS_PLUGINDIR apparently uses the wrong path

Tagged: , ,

This topic contains 10 replies, has 3 voices, and was last updated by  Cici 9 months, 1 week ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • #35267



    I already posted the issue here:


    The update 4.3.13, breaks the Plugin for me.

    I have moved the plugin directory outside my wp directory (which is totaly fine for wordpress and the other plugins).
    However, the new SLPLUS_PLUGINDIR seems to point to the wrong path.

    I guess you are using dirname(__FILE__) or the WP plugin_dir_path( $file ) to get the plugin path. This is ok for PHP scripts (you will get the full server path). Unfortunately, this is not ok for URLs like for the import of your CSS scripts, images, js, etc.

    What you want use is: plugins_url()

    You can find more information here:

    I’m sure you guys can fix it pretty fast.




    Hi Dom, aka Rocket


    Lance is out this week, but I will put a note in his schedule to look at this. Thanks!

    P.S. we are up to 4.3.14 , Info news.


    Lance Cleveland

    SLPLUS_PLUGINDIR should only be used for the PHP files; and yes, it uses plugin_dir_path( __FILE__ ) to ascertain that location.

    NONE of the CSS , JavaScript or other items being enqueue or referenced by URL should use that variable.

    What specific element of SLP do you see that is using the SLPLUS_PLUGINDIR instead of the URL?


    Lance Cleveland

    I just rescanned the code and do not see any improper use of SLPLUS_PLUGINDIR or SLPLUS_ICONDIR.     I also see where icon file paths replace ICONDIR with ICONURL which is based on plugins_url(  ” , __FILE __ );

    This should be functioning normally.


    If you can tell me what specific part of SLP is not doing what you expect AND you can outline what you did to harden WordPress it will help me isolate & resolve the issue.  If you don’t want to disclose specifics but can cite an online resource and say “I did part 3 in this article” I can probably figure out where you put wp-content and what you changed in the WP code to tell it the directory moved.




    Thanks for the reply.

    I just renamed the wp-content directory and the wp directory in general.

    The structure looks something like

    root (with index.php and .htaccess)
    – wp-content-renamed
    – wp-folder-renamed (inside are all the other folders and like wp-admin or wp-config.php)

    With the update, the plugin tries to pull the nessasary css files (frontend and backend) from a internal server path and not from the correct url.

    Hope this will help.



    Hi Dom,

    I added this back on Lance’s radar. Make sure you are keeping up with the latest versions of everything, he has been working fast and furious with updates (and hopefully not breaking too much along the way) Check the Plugin versions and Info News channel as well, that will provide you some useful information. Thanks for your input and for supporting Store locator Plus.




    Any news on this? Store locator now stopped working completely for me (Google API changes). So I HAVE to update but this will break, because of the bug above.



    Ok. I fixed it locally for me, but it seems the issue could be on the WordPress site, not the store-locator site.

    But maybe you could investigate futher.

    If you are using plugins_url(”, __FILE__); like you do, the url will break.

    You will get the correct url, till the plugins folder and then the absolut script path on the server (like /homepage/1234/html/…).

    So I’m not sure if you are not supposed to use the plugins_url funktion like this (the documentation is not super clear) or if it has something todo with this:

    Related to the above, it’s also important to note that PHP’s __FILE__ magic-constant resolves symlinks automatically, so if the wp-content or wp-content/plugins or even the individual plugin directory is symlinked, this function will not work corrrectly.

    Which could explain why it is working for you, but not for me (and potentially others).
    So the easy fix for me was to replace the line 55 in the store-locator-le.php with this:

    if ( defined( ‘SLPLUS_PLUGINURL’ ) === false ) { define( ‘SLPLUS_PLUGINURL’  , plugins_url(). ‘/store-locator-le’   ); } // Fully qualified URL to this plugin directory.

    And there you go! Everything works fine again.

    Please let me know if this line will make it into your code, so I can update again, without breaking in the future.



    • This reply was modified 12 months ago by  Dominik.


    Hi Dom, I never took it off Lances Radar. but if I think of it at our next meeting this week I will ask him. Of course I will not explain it right and then he will have to look into it again. With the new updates and the custom projects and the holidays , schedule is awfully tight right now. Sorry you have to fix things again.





    The issue still exists. I have to manually fix the URL on every update.
    I guess the plugin calls the plugins_url in the wrong location (so the function is not ready jet, to fix the paths by its own).

    Guess I’m not the only one, having the problem. It occurred for me on two completely different servers setups now.



    SLP 4.4.28 (pre-release being worked on ) has a new method for trying to set the path that is supposedly better at following symlink installs.

    According to our SaaS development team (international based WP gurus) this works in the plugins they’ve developed so it should not cause any new issues; however with 20,00 active sites it may break something for someone.
    Lance would like to invite you and Nicolas to test 4.4.28 pre-release when it is out.

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

You must be logged in to reply to this topic.