Warning: strpos() [function.strpos]: Empty delimiter

Sorry for the trouble rdmgrl. Is it possible that you have a custom-defined ABSPATH on the site? If so, do you have the value set to a blank string by any chance?

I have the same error.

I’ve looked into the code of your plugin and I see that in file lib/icon-fonts/init.php you’re getting the ABSPATH and then you’re trimming it by removing the “/” characters. However, because I have the website in the main directory, I have the ABSPATH = “/”. So, when you remove this character and then you make a “strpos()” with this as the second parameter, the “strpos()” function will show these errors.

I can see that happening with an ABSPATH of just a ‘/’, but I wonder why it would be done that way. As given by the name, ABSPATH is meant to be an absolute path and not a relative one.

The specific section of code that is having problems is there to generate a URL to plugin resources. While I can add a check for an empty ABSPATH after stripping the “/”, the code would fail to function correctly as it needs an actual absolute path in order to properly generate the URL.

In hosting, where I have all my websites, files and directories in each domain and subdomain are treated like in the root (“/”) path. So, the ABSPATH = “/” is correct.

For example, in this hosting if I have a directory:
“/mywebsite”
and domain
“https://mywebsite.com”
which is set to this directory, then all directories and files in “/mywebsite” will be treated as if they are in the root directory, for example, URL
“https://mywebsite.com/something.php”
will execute script at
“/mywebsite/something.php”.
Furthermore, from script point of view the “/mywebsite” directory does not exists – all inside is treated like in root path (“/”).

So if you need this to generate some URL, I think it should be ok in this case. For example, URL:
“https://somedomain.com”.$abspath.”/something.php”
where $abspath is ABSPATH after trimming in your plugin (by eliminating “/”), will be ok in my case, because it will be:
“https://somedomain.com/something.php”
and it is correct URL.

This is how it works in my case.

It occurred to me after posting that different setups, such as chroot, may end up with a true ABSPATH of “/”. I’m currently working on an update that will account for such setups. I’ll also have to run a number of tests to ensure that the change won’t cause any unexpected behavior.

Thank you.

I have a modification that should fix the issue. Given that I don’t have a reliable system that replicates these conditions, would one of you be willing to try out the modification and confirm or deny that it fixes the issue?

If so, you can download the modified file
here. It will need to be unzipped first. Then the init.php file from the zip will need to replace the better-wp-security/lib/icon-fonts/init.php file.

I’ve checked it and it works. All warnings are gone.

Excellent. I’ll work with Chris, the main developer behind iThemes Security, and get an updated release out shortly.

Thanks for the great feedback.

It looks like an updated version will be released tomorrow. This new version will include the fix talked about here.