Ian Dunn

Even if we don't use them for custom sniffs, they may be useful for other things, like detecting code that's likely to produce a run-time fatal.

Also `PHP-Parallel-Lint` and `php -l` _(although the latter is already in use by an SVN pre-commit hook, IIRC)_

WP extensions for tools: * https://github.com/humanmade/psalm-plugin-wordpress/ * https://github.com/szepeviktor/phpstan-wordpress/ * https://github.com/php-stubs/wordpress-globals * https://github.com/johnbillion/wp-hooks

https://github.com/phan/phan has similar philosophy to this project, but doesn't seem to have any security-focused stuff. https://github.com/webarx-security/wpbullet is specific for WP and security, but doesn't look active since the initial release.

I got Psalm roughly working in [the `psalm` branch](https://github.com/WordPress/wporg-code-analysis/tree/psalm), and it catches some things, but not as many as I expected. Unless I've got it setup wrong, it's not catching...

https://github.com/exakat/php-static-analysis-tools lists a ton of tools

I played around w/ sonarqube in [the `sonarqube` branch](https://github.com/WordPress/wporg-code-analysis/tree/sonarqube). it feels more promising than Psalm, but I also wasn't able to get it to detect a lot of things it...

That's a really good question 🤔 `wp_kses( $before_widget, 'widgetarea' )` is a good idea, but I wonder what specifically it would allow/restrict? Are there things we can justifiably say should...

🤔 Yeah, I like that better than `phpcs:ignore` comments. It's cleaner, and easier to use. It's a bit awkward since it doesn't transform the input at all, but still better...

> the docs rarely say what kind of escaping is needed for core functions Agreed. One helpful thing is that WPCS has done a lot of work to identify functions...