Problem/Motivation

I successfully installed code sniffer in Eclipse, but it only works on .php files. I right clicked on preferences->php tools ->php CodeSniffer and I set file extensions to be php,module,inc,install,test,profile,theme and still the code sniffer only flags files with the php extension.

In the console I see the extensions parameter did not get set, here is what I see:

/usr/bin/php -c /var/folders/q6/44cl7bwn1blfrxchzns459rh0000gp/T/zend_debug/session3952346344543095394.tmp -d asp_tags=off /Applications/eclipse/plugins/org.phpsrc.eclipse.pti.tools.codesniffer_1.3.0.R20111119000000/php/tools/phpcs.php --report=xml --standard=/Users/barnettech/drush/drupalcs/DrupalCodingStandard /Users/barnettech/Sites/belldev/git/dev/babsoncomm/docroot/sites/all/modules/custom/folder_timerelease/folder_timerelease.module
<?xml version="1.0" encoding="UTF-8"?>
<phpcs version="1.3.2">
</phpcs>

Proposed resolution

Remaining tasks

The problem needs to be identified as to why extensions aren't being set, as well the default extensions aren't being picked up if I leave extensions blank in the code sniffer settings

Original report by barnettech

If this is a training issue (I don't think it is) please let me know, but I spent the greater part of my day today trying to figure this out and I think it's a bug.

Comments

barnettech’s picture

Issue summary: View changes

logging where in the code I think the problem may be.

das-peter’s picture

Hi barnettech,

Thanks for the report.
Am I right that you use the sniffer in Eclipse via PTI (PHP Tools Integration)?
However, generally drupalcs can't do a thing before it actually runs, this means we can't fix (here) a bug that happens outside of our code. And the initial call of PHP_CodeSniffer is quite far away from our code :)
The other thing is that it looks like PTI invokes a sniff for each single file, even if you validate a directory. And the PHP_CodeSniffer Documentation says:

If you have asked PHP_CodeSniffer to check a specific file rather than an entire directory, the extension of the specified file will be ignored. The file will be checked even if it has an invalid extension or no extension at all.

This leads me to the conclusion that PTI uses the extension list do determine which files of a directory shall be passed to the PHP_CodeSniffer and not to pass the whole list to PHP_CodeSniffer. But I could be wrong on that - maybe we should ask Sven Kiera, the author of PTI.

But wait, the long story above was just the first part :)
I actually can reproduce this issue, but I've no clue why it happens. :|
If a module file is passed it looks like PHP_CodeSniffer simply skips the validation and returns an "empty" result. This behaviour would absolutely contradict the documentation.
Maybe we found a bug in PHP_CodeSniffer itself - but I've to dig deeper first to confirm this.

barnettech’s picture

So I did some digging. If I insert these lines on lines 424 and 425 of /Users/barnettech/pear/share/pear/PHP/CodeSniffer/CLI.php

$the_extensions = 'php,module';
$values['extensions'] = explode(',', $the_extensions);

Then it will start examining files with both php and module as an extension.

I just confirmed that the only thing in variable $arg when public function processLongArgument($arg, $pos, $values) gets called is:
"standard=/Users/barnettech/drush/drupalcs/DrupalCodingStandard" (that function is in the CLI.php file mentioned above). So the extensions parameter is never getting set.

Is this a bug in PHP_CodeSniffer I assume ?

barnettech’s picture

I just submitted this as a bug to CodeSniffer: https://pear.php.net/bugs/bug.php?id=19246&thanks=4

Do we keep this open as a bug in this forum? Feel free to close it, if it is enough to have it open in the above link.

das-peter’s picture

I've just posted a pull request for PHP_CodeSniffer with a patch that solves this issues:
https://github.com/pear/PHP_CodeSniffer/pull/3

And the bug-report is updated as well.

das-peter’s picture

Status: Active » Fixed

The latest version of CodeSniffer contains a fix for this.
Please see the pear bug tracker for further information: https://pear.php.net/bugs/bug.php?id=19246#1328660164

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

after some digging I'm still not sure which file is involved.