Short open tag in html was not detected.

[shoyan]

Short open tag is detected in the PSR-2. However, short open tag in html was not detected.

$ phpcs --standard=PSR2 hoge.php

FILE: /Users/shoyan/app/hoge.php
----------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
 1 | WARNING | No PHP code was found in this file and short open tags
   |         | are not allowed by this install of PHP. This file may
   |         | be using short open tags but PHP does not allow them.
----------------------------------------------------------------------

Time: 68ms; Memory: 4Mb

hoge.php

<?
    echo 'start';
?>

<div>
  <p><? echo "hoge"; ?></p>
</div>

[gsherwood]

I'm not actually sure what you are asking, so I'll just give some background.

That warning has nothing to do with the PSR-2 standard, or any other standard you might be using, It is a core warning that comes from PHPCS itself.

The warning is saying that the PHP CLI version you are using does not allow short open tags in its config. So when PHPCS tokenizes your file, PHP itself doesn't see any PHP code in there at all. So to PHPCS, that file only contains HTML and so there is nothing to actually check. But it has the extension of a PHP file, so you get that warning message.

If you ran the file with php hoge.php the content would just be printed to screen:

$ php hoge.php
<?
    echo 'start';
?>

<div>
  <p><? echo "hoge"; ?></p>
</div>

If you changed those PHP tags to <?php, you'd get this:

$ php hoge.php
start
<div>
  <p>hoge</p>
</div>

[gsherwood]

Forgot to mention that PHPCS adds the error on line 1 so you see it. It's not actually telling you that the short open tag is banned there, or even used there. It's just telling you that the file has an error and all PHPCS errors need to have a line number.

So maybe that is why you report this?

PSR-2 is not checking for and banning short open tags. That is just a PHPCS warning to let you know that PHP can't actually see any PHP code in this file.

[shoyan]

Oh...I'm sorry. My recognition was incorrect. Thank you for the quick response.

[gsherwood]

No problem. Thanks for getting back to me.

[mityukov]

But it has the extension of a PHP file, so you get that warning message.

I get this error for .twig and .less files, for example…

[aik099]

@mityukov, I recommend restricting scope of checked files to *.php for example. This way not only you won't have described problem but also you'll get result back faster because analyzed file count will be reduced.

[mityukov]

Is there a way to check HTML/Twig/CSS syntax as well?

[aik099]

CSS/JavaScript - already supported. As for HTML/Twig there are no built-in way, but you can create your own tokenizers in PHPCS 3.x.

[mityukov]

Ok. Concerning the scope restricting. I'm adding some directives like <exclude-pattern>*.twig</exclude-pattern> to my XML, still it displays No PHP code … errors for all of these files. Probably, because I list these files in the arguments explicitly. But… It's just the list of files in specific commit. I want to send this list as it is and then have codesniffer to skip "excluded" ones in according to XML config. Is it possible?

#!/bin/zsh
COMMIT=${1-HEAD}
echo CommitID: $COMMIT
echo
echo Files list:
git diff-tree --name-only --no-commit-id -r $COMMIT
echo
echo "Code style report (a subset of PSR-2):"
echo
git diff-tree --name-only --no-commit-id -r $COMMIT | xargs phpcs --no-colors --standard=~/Work/testing/codesniffer/my_conf.xml
echo
echo "DocBlocks report"
echo
git diff-tree --name-only --no-commit-id -r $COMMIT | xargs phpcs --no-colors --standard=Generic --sniffs=Generic.Commenting.DocComment

[gsherwood]

@mityukov You are correct that PHPCS is not ignoring your files because you've specified them on the command line.

In the 3.x version, I've changed the way exclude patterns work so they are applied to all files being checked (including STDIN and piped files). You'd have to try the latest RC version if you want to have CLI-specified files being excluded.