echo $foo; Not Valid

[craigr-wlp]

The following does not validate:

$foo = 'abc';
echo $foo;

I have to use this workaround:

$foo = 'abc';
echo '' . $foo;

Is this by design?

On a side note, this also does not validate, which is the translation gettext function:

$foo = 'abc';
echo _($foo);

[henryhayes]

+1

[pcaligari]

+1

[GaryJones]

Is there any specific notice / warning being given?

[henryhayes]

I have the same problem. There is no warning as such. It considers the above code invalid as a coding standard.

Example:

<?php
$foo = 'abc';
echo _($foo);

Gives us the followinf errors:

<phpcs version="1.4.3">
 <file name="../test.php" errors="2" warnings="0">
  <error line="3" column="6" source="WordPress.Functions.FunctionCallSignature" severity="5">No space after opening parenthesis of function  prohibited</error>
  <error line="3" column="12" source="WordPress.Functions.FunctionCallSignature" severity="5">No space before closing parenthesis of function  prohibited</error>
 </file>

[pcaligari]

The echo _($foo) should generate warnings as above.. the standard states it should be echo _( $foo )

echo $foo or echo '123' are perfectly valid though and should not generate any warnings. I'll all the actual warning later today.

[pcaligari]

The sniff error message is as follows

Expected next thing to be a escaping function, not '$foo'

[Rarst]

I get this as security check, but I think this does not belong in a coding standards check. Coding standards are definitive - either code conforms or it doesn't. Security checks like this are ambiguous - code might or might not have an actual issue with it and it creates distracting false positives.

[westonruter]

The sniff in question here is XSS/EscapeOutputSniff. It is intended encourage use of the esc_* functions whenever outputting content, or to use template tags which handle escaping for you. The sniff is configured to prevent the sniff error if you explicitly add the comment // xss ok.

I agree that we should have different default rulesets provided that can be used for different classes of issues, like one for coding standards and another for security checks.

[shadyvb]

I also think that echo _( $foo ) shouldn't be encouraged as this does not enable proper string detection in gettext string extractors.

What would be the compliant way to echo such a string is:

$bar = _( 'test' );
echo esc_attr( $bar );

Which validates quite fine.

Plus that you don't know what someone would put in a translation for your string, so it must be escaped.

However, this should've raised an issue, but didn't:

echo '' . $foo;

[westonruter]

Or even:

esc_attr_e( 'test' );

[westonruter]

The last example cited (where the literal string is concatenated with a variable) should get better handling. The sniff should be walking over everything in the echo statement, not just the first element.

[shadyvb]

Closing down the issue, opened #94 to address the invalid workaround.