- Is wp-coding-standards/wpcs a Laravel package?
- No. It is a PHP_CodeSniffer ruleset that enforces WordPress coding conventions, with no service provider, config publish, or runtime code. It belongs in require-dev only, and only for repositories that contain WordPress-context PHP such as plugins, themes, or mu-plugins.
- Can I use WPCS to lint a standard Laravel application?
- It is not recommended. WPCS encodes WordPress conventions like tabs for indentation, Yoda conditions, snake_case function names, and WordPress-specific security sniffs, which produce large volumes of false positives on idiomatic Laravel code. Use Laravel Pint or PHP-CS-Fixer for Laravel code and scope WPCS to WordPress paths only.
- How do I install WPCS in a Composer project?
- Allow the dealerdirect/phpcodesniffer-composer-installer plugin in your composer.json allow-plugins config, then run composer require --dev wp-coding-standards/wpcs:^3.0. After installation, reference the WordPress standard in phpcs.xml.dist or pass --standard=WordPress to PHP_CodeSniffer.
- What PHP and PHP_CodeSniffer versions does WPCS require?
- WPCS requires PHP 7.2 or newer and depends on PHP_CodeSniffer 3.x or 4.x plus PHPCSExtra. Because WPCS tracks PHPCS major versions, pin both wp-coding-standards/wpcs and the PHPCS version explicitly in CI to avoid breaking changes in ruleset semantics or exit codes.
- Does WPCS support Laravel version 10 or 11?
- Laravel version support is not applicable because WPCS is not a Laravel package and has no framework coupling. The relevant compatibility target is your PHP version and PHP_CodeSniffer version. It can coexist in the same project as Laravel tooling, but it should lint only WordPress-context files.
- How do I avoid WPCS false positives in a mixed Laravel and WordPress repository?
- Use a path-targeted phpcs.xml.dist that includes only your WordPress plugin, theme, mu-plugin, or WooCommerce extension directories. Do not apply --standard=WordPress org-wide or to app/, routes/, or other Laravel directories. A scoped ruleset keeps the gate meaningful and avoids baseline noise.
- How do I integrate WPCS into CI?
- Add a PHP_CodeSniffer job that runs phpcs with your scoped ruleset and fails on violations above an agreed severity or error count. The main friction point is the Composer allow-plugins requirement, which may need governance approval in locked-down CI or mirrored-registry environments. Budget roughly one engineer-day for a pilot repo including baseline triage.
- What security issues does WPCS catch?
- WPCS includes WordPress-specific security sniffs for nonce verification, output escaping with esc_* functions, and input sanitization such as wp_unslash. These are valuable for WordPress plugins and themes but are not substitutes for Laravel security patterns. Add PHPCompatibilityWP if you also need PHP version correctness checks.
- Is WPCS a good template for an internal coding standard?
- Yes. WPCS is a mature reference for shipping a Composer-installed ruleset with a phpcs.xml.dist, configurable sniff properties, and documented CI recipes. However, it is not an engine you can reuse for Laravel because Laravel Pint is PHP-CS-Fixer-based while WPCS is PHPCS-based. Plan to maintain two standards rather than one.
- Who maintains WPCS, and should I worry about sustainability?
- WPCS is maintained by the WordPress project and has a large download base and roughly 2.8k GitHub stars. The README includes an explicit funding appeal, so maintainer bus factor is a real continuity risk for a blocking CI gate. Mitigate with version pinning and a documented fallback such as freezing the ruleset while keeping the pipeline green.