Avoid throwing a notice about strpos(): Empty needle when going through include paths

[dac514]

Kept getting this warning when doing --include="*.blade.php", among other things.

Related to #125 and #129

[schlessera]

@swissspidy This now saves against the thrown notice, but I'm wondering whether it doesn't now exclude valid matches.

If $base is empty, should a match be possible here?

[dac514]

The old code, without my change, in context, was:

	if (
		( '' !== $root_relative_path && 0 === strpos( $base, $root_relative_path ) ) ||
		0 === strpos( $root_relative_path, $base )
	) {
		return true;
	}
}
return false;

Written another way:

	if (
		$CONDITION_1 ||
		$CONDITION_2
	) {
		return true;
	}
}
return false;

My change only suppresses the warning:

$CONDITION_2 = strpos( 'node_modules', '' );
var_dump($CONDITION_2);
// false, aka:
$CONDITION_2 = 0 === strpos( 'node_modules', '' );
var_dump($CONDITION_2);
// false

$CONDITION_2 = '' !== '' ;
var_dump($CONDITION_2);
// false

whether it doesn't now exclude valid matches. If $base is empty, should a match be possible here?

My change doesn't change how the code works, it only suppresses the PHP Warning.

If a match is possible, and the testing suite doesn't catch it, then that's beyond the scope of my PR IMHO.

Hope this helps.

[schlessera]

Yes, it was clear how the logic works. However, the PR should ideally be about eliminating the root cause of a bug, not just obfuscating it.

In this case, the root cause is that one possible scenario was apparently not being considered by the current logic. The notice as such is valuable as it shows us we apparently forgot something. If we now just hide the notice, the possible bug might still be in there and forgotten because the symptom is being hidden.

This is why I'd like some feedback by @swissspidy, who built the original code, as I'm unsure what an empty base in this case would signify.

[swissspidy]

Hmm I think my initial work was pretty much rewritten in #104. So maybe @herregroen knows more?

The warning implies that $path_or_file is an empty string and I wonder why this happens. If it's because of some edge case thing I don't think just breaking early would cause any troubles.

[dac514]

Maybe this helps? I can reproduce every time by running:

wp i18n make-pot . languages/plugin.pot --include="*.blade.php" --exclude="vendor,symbionts" --headers='{"Report-Msgid-Bugs-To":"https://github.com/namespace/plugin/"}

[schlessera]

@swissspidy I think you misread the code. The issue is not that $path_or_file is empty, but that current( explode( '*', $path_or_file ) ) returns an empty string. This happens for a simple example like *.php, as it will explode to [ '', '.php' ].

[swissspidy]

Ah, indeed! My bad.

[schlessera]

I'm not so sure that the logic is actually sound, as we seem to just be hiding the problem with this PR. Nevertheless, it gets rid of the notice, and it doesn't actually break anything that wouldn't already be broken in that case anyway.

So I'll go ahead and merge this for now.

[markhowellsmead]

I'm still getting a warning about "empty needles" when running wp i18n make-pot . languages/sht.pot --include="*.php,*.jsx,*.js" --exclude="assets/gutenberg,assets/plugins,vendor,node_modules"with 2.2.0 in my Theme root folder. The file is generated, but it doesn't contain any of the strings from the JSX files.

[swissspidy]

@markhowellsmead Could you please create a new issue for that so we can track this? Thanks!