Models created with BPMN does not pass Coder PHPCS

I wonder why PHP code style should be tested on yml files? That sounds like a mis-configuration of phpcs.

I scan YAML files because there are rules intended to scan YAML files:
- https://github.com/pfrenssen/coder/tree/8.3.x/coder_sniffer/DrupalPracti...
- https://github.com/pfrenssen/coder/tree/8.3.x/coder_sniffer/DrupalPracti...
- https://github.com/pfrenssen/coder/tree/8.3.x/coder_sniffer/Drupal/Sniff...
- https://github.com/FlorentTorregrosa/phpcs-drupal/tree/1.0.x/coder_sniff...

Also in the documentation the yml extension is listed: https://www.drupal.org/node/1587138 →

phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml /path/to/drupal/example_module

I opened the issue in ECA issue queue because it was a config file from ECA, but maybe it should be moved into Coder issue queue?

This certainly sounds like a coder issue if anything. The config yaml's are certainly valid from a YAML perspective and they also pass config validation, which is pretty strong in Drupal 10.1 and beyond.

@Grimreaper it would probably help to attach a sample file which produces the above log output and then move this together over into the coder queue.

Thanks @jurgenhaas,

Yes, I have no doubt that the config is valid.

Attaching file and switching to Coder issue queue.

I have fixed the phpcs issue, attached the patch also.

Hi chetan 11,
I am not sure what you intended to change, but you have uploaded a large 1.5MB patch containing over 46,186 lines. It looks like you have run phpcbf code fixer the wrong way, and uploaded a patch which modifies 340 coder source files. Coder has some customisations for the standards it follows and contains its own phpcs.xml.dist with the defintions of these rules. This config file will be used automatically by phpcs and phpcbf if you specify a --standard parameter value. It seems that you have run it with --standard=drupal which means the customisations are ignored, and hence the patch with 46,000 lines.

Did you actually make some code changes to a sniff file in amongst the incorrect coding standards changes? Searching the patch for your actual changes is impossible, so hopefully you can re-do it?

I think first we need to add test coverage for allowing (and ignoring) the generated php tag inside a .yml file. Then when the new test passes it will demonstrate that the sniff is fixed.

@Grimreaper
Is the file you uploaded in #6 the actual one which produced the standards errors in the issue summary?

I am trying to replicate the problem, and I get just the single fault

FILE: eca.model_.process_xvysdt0.yml
------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
------------------------------------------------------------------------------------
 14 | WARNING | Possible use of short open tags detected; found: <?xml version="1.0"
    |         | encoding="UTF-8"?>
    |         |  (Generic.PHP.DisallowShortOpenTag.PossibleFound)
------------------------------------------------------------------------------------

Line 14 is
modeldata: | <?xml version="1.0" encoding="UTF-8"?>

@jonathan1055,

Yes I confirm this is this file, with Coder 8.3.21.

I got the same errors with all my eca.model.process_*.yml files.

OK. So now I need to work out why I get a different output to you. Please could you run phpcs with the -s flag so that the failing sniff names are shown, and post the output (or update the issue summary with the output). You can also add --report-width=80 to make a good readable width for pasting.

Thanks @jonathan1055 for the next step.

Issue summary updated with the results.

I have a slightly customized PHPCS: https://gitlab.com/florenttorregrosa-drupal/docker-drupal-project/-/blob...

<?xml version="1.0"?>
<ruleset name="project">
  <description>Scan custom code.</description>

  <file>../../../app/modules/custom</file>
  <file>../../../app/profiles/custom</file>
  <file>../../../app/themes/custom</file>
  <file>../../../conf/drupal</file>

  <arg name="basepath" value="."/>
  <arg name="colors"/>
  <arg name="extensions" value="inc,info,install,module,php,profile,test,theme,txt,yml"/>
<!--  Official extensions. -->
<!--  <arg name="extensions" value="inc,install,module,php,profile,test,theme,yml"/>-->
  <arg name="parallel" value="75"/>
  <arg value="p"/>

  <!-- Ignore various version control directories. -->
  <exclude-pattern>*/\.git/*</exclude-pattern>
  <exclude-pattern>*/\.svn/*</exclude-pattern>
  <exclude-pattern>*/\.hg/*</exclude-pattern>
  <exclude-pattern>*/\.bzr/*</exclude-pattern>

  <!-- Drupal coding standards. -->
  <rule ref="Drupal"/>
  <rule ref="DrupalPractice"/>
  <rule ref="FlorentTorregrosaDrupalPractice"/>

  <rule ref="Generic.PHP.RequireStrictTypes"/>
  <rule ref="Squiz.PHP.Eval"/>

</ruleset>

For "FlorentTorregrosaDrupalPractice", this comes from https://github.com/FlorentTorregrosa/phpcs-drupal (currently only a rule on block.block.*.yml files name).

  1 | ERROR | [x] Missing file doc comment
    |       |     (Drupal.Commenting.FileComment.Missing)

This is a sniff provided by Coder but it only acts on the T_OPEN_TAG token The .yml file is tokenized entirely as T_INLINE_HTML so I don't know how this sniff is being triggered for you. It's not triggered for me. If I modify the sniff to also get triggered on T_INLINE_HTML then I do get the message, but that does not explain why you get it.

 14 | ERROR | [x] Short PHP opening tag used; expected "<?php" but found
    |       |     "<?" (Generic.PHP.DisallowShortOpenTag.Found)

This is where I get a different warning from you. The sniff is provided by squizlabs/php_codesniffer not Coder. It checks $shortOpenTags = (bool) ini_get('short_open_tag'), which is false in my environment, so the sniff also reacts to T_INLINE_HTML. But the opening <?xml is just seen as <? with no php. $content = 'modeldata: <?xml etc etc ?>' and I get the different error, from the 'possibleFound' part of the sniff:

 1 | WARNING | Possible use of short open tags detected; found: <?xml etc etc ?>
   |         |  (Generic.PHP.DisallowShortOpenTag.PossibleFound)

I don't know why the T_INLINE_HTML is subsequently getting re-tokenized as PHP in your case. Or maybe it is tokenized as php right from the start. But this would also explain the rest of the messages that you get on line 14

Here's a patch for DisallowShortOpenTagSniff.php that I used to get some debug. Can you apply it, and then run phpcs with -vvvs to see the internal debug too.

Thanks.

Here is the result, I scanned only "problematic" file because the output is very big.