boils down to PHPCS

[szepeviktor]

@swissspidy Could it be that

• this action runs a plugin
• that plugin run PHPCS
• So I just need a ruleset??

[swissspidy]

Hehe almost! :)

There are two types of checks:

• Static checks
  • Contains both PHPCS checks and other types of manual checks (e.g. for checking the readme)
• Runtime checks
  • Actually activates the plugin and does some more tests

Plugin developers are of course encouraged to use PHPCS/WPCS in their development workflow, as usual. Plugin Check is then a small addition to that.

Hope that explains it.

FWIW the current setup isn't ideal, for example the core functionality should be extracted into a WP-CLI command or so (see WordPress/plugin-check#153). And there are still many more runtime checks that have yet to be added. I recommend filing any suggestions on the main Plugin Check repo.

[szepeviktor]

• and other types of manual checks
• and does some more tests

Thank you for your answer!
Could you give me two examples?

[swissspidy]

and other types of manual checks

• Detect and warn about existence of hidden files or application files in the plugin folder
• Prevent the use of localhost or 127.0.0.1 in the code
• Disallow usage of the Update URI header or similar to download stuff from other places
• Disallow usage of reserved words and trademarks
• Disallow obfuscated code

and does some more tests

• Detect if a stylesheet is enqueued on all pages, which is usually a mistake
• Detect whether the combined size of all JS on a page exceeds a certain threshold
• More performance-related checks are in discussion (Add more performance-related checks plugin-check#443)

[szepeviktor]

Thank you.