WordPressCS requires Composer since 3.0, and its global path is a placeholder

The install is two commands, and the first one is easy to skip

A project-local installation is documented as a pair of commands, and the first one is not optional even though it looks like boilerplate:

composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev wp-coding-standards/wpcs:"^3.0"

The reason is the Composer PHPCS plugin, which is what registers the rulesets with PHP_CodeSniffer once the package lands. Modern Composer blocks plugins that have not been explicitly allowed, so if you run only the require line the package installs and the ruleset names never appear. There is no error, just a standard that PHP_CodeSniffer cannot find.

The global route is the same shape with the global prefix on both lines, allow-plugins first, then composer global require --dev wp-coding-standards/wpcs:"^3.0". Upgrading is also two variants, composer update wp-coding-standards/wpcs --with-dependencies for a project install and the same command under composer global for a global one, where the with-dependencies flag is what lets the shared sniffer move in step.

The global run command still contains an unresolved placeholder

Here is what the two install methods produce. The project-local install gives you a binary inside the project, and the command is concrete:

vendor/bin/phpcs -ps . --standard=WordPress

The global install is given as %USER_DIRECTORY%/Composer/vendor/bin/phpcs -ps . --standard=WordPress. That %USER_DIRECTORY% is not defined anywhere in the instructions, and it is not shell syntax that expands on its own.

The pro-tip repeats the same placeholder. It recommends using the global install method for the convenience of phpcs as a plain command, and then says to add %USER_DIRECTORY%/Composer/vendor/bin to the PATH environment variable for your operating system. So both the command and the advice that would make it convenient are templates waiting on a substitution the reader has to work out.

The arguments themselves are worth keeping. -p shows progress, -s shows sniff codes rather than descriptions, the dot is the target, and --standard=WordPress selects the super-set.

WordPress-Extra includes Core, and WordPress-Docs does not say it does

The project describes itself as a super-set of the sniffs the WordPress community may need, and using the WordPress standard gives you all of the checks. Narrowing from there is where the structure gets uneven.

There are three named subsets under WordPress. WordPress-Core is the main ruleset for the core coding standards. WordPress-Docs is an additional ruleset for inline documentation standards. WordPress-Extra is an extended ruleset holding recommended best practices that the core standards do not sufficiently cover, and it is the only one whose inheritance is stated: it includes WordPress-Core.

So the naming implies more symmetry than the definitions deliver. Selecting WordPress-Extra gives you core rules plus the extras but not the documentation rules, and selecting WordPress-Docs gives you documentation rules with no statement about whether core comes along. Anyone who reads the list as three equivalent slices of the whole will end up with a different set of checks than they expected, and the missing line is the inclusion note that WordPress-Extra spells out.

The repository lints itself with WordPressCS and ships a sample for you

Configuration discovery is handled by filename. Name your file .phpcs.xml, phpcs.xml, .phpcs.xml.dist or phpcs.xml.dist, place it in the directory you run CodeSniffer from or in a directory above it, and PHP_CodeSniffer finds it on its own, which means you do not have to pass --standard at all.

The repository carries two files of that kind for two different audiences. There is a .phpcs.xml.dist at the root, which is WordPressCS linting itself with its own rules, and there is a phpcs.xml.dist.sample, which is the sample handed to people starting their own configuration. The README also points at a fully annotated example ruleset hosted elsewhere.

That split explains the directory listing as well. The four PascalCase directories at the root, WordPress/, WordPress-Core/, WordPress-Docs/ and WordPress-Extra/, are the rulesets themselves, one directory per standard name you can pass to --standard, which is why the standard names in the documentation and the directories in the tree line up one for one.

Four extensions are mandatory and two are merely recommended

The stated floor is PHP 7.2 or higher, plus Composer, with four extensions required to be enabled: Filter, libxml, Tokenizer and XMLReader. Two more are recommended for the best results rather than required, iconv and the Multibyte String extension.

The split is sensible for what the package does. Tokenizer is how the sniffs read PHP source, XMLReader is what lets ruleset files and documentation be parsed, libxml sits underneath that, and Filter is part of the same extension family. The recommended pair, iconv and mbstring, affects how text with different encodings is handled, which matters for a ruleset whose job includes inspecting inline documentation and comments.

One migration note is attached to the requirements rather than buried. If you are coming from a WordPressCS version before 3.0.0, the README asks you to read an upgrade guide for ruleset maintainers and end users first, because the installation model changed underneath you.

Three analysis tools and a spell checker run over one PHP repository

The root of the repository holds configuration for four separate checks, which is more than most projects bother with. PHP_CodeSniffer is configured by .phpcs.xml.dist, which is how the standards check their own sniffs. PHPStan has phpstan.neon.dist for static analysis. PHPUnit has phpunit.xml.dist for the test run. And _typos.toml configures a spell checker, which is an unusual file to find in a PHP project and explains a category of failure you would not otherwise expect from a coding standards repository.

The tests live in a capitalised Tests/ directory, which sits oddly next to the lowercase PascalCase ruleset directories, and the CI side is visible in the badge row: a basic QA workflow and a unit tests workflow, with coverage reported through Codecov against the develop branch.

That branch choice is consistent throughout. The default branch is develop rather than main or master, and the badge set includes a development version marker pointing at the dev-develop channel on Packagist, so the branch you clone is the development line rather than a release branch.

Composer is the only supported install since 3.0.0

The installation section opens with a dated policy statement rather than a convenience note: as of WordPressCS 3.0.0, installation via Composer using the documented instructions is the only supported type of installation. Everything else people used to do is now outside what the project will help with.

That policy is why the Composer plugin matters so much. Composer will automatically install the project dependencies and register the rulesets from WordPressCS and other external standards with PHP_CodeSniffer, using the Composer PHPCS installer plugin. Without that registration step, a manual install leaves you with sniff files on disk that nothing knows how to load by name.

The project also states plainly that it needs funding, with a pointer to a funding section, and it carries a CHANGELOG.md and an MIT licence. The current release line is 3.4.x, with 3.4.1 published on 2026-07-27, 3.4.0 on 2026-07-16 and 3.3.0 on 2025-11-25, so the minor line sat for roughly eight months before the patch releases started.

The README promises fixers and CI integration further down

The table of contents at the top of the README lists sections that the visible text does not reach, and those headings are the most useful signpost in the document. One is about fixing errors or ignoring them, with a subsection on the tools shipped with WordPressCS. Another is about running your code through WordPressCS automatically using continuous integration tools.

The first of those matters for how you adopt the tool. A ruleset that can only report problems is a gate you have to clear by hand; one that ships fixers can rewrite formatting for you. The contents section confirms that both exist, and the CHANGELOG.md at the root is where the per-version detail lives.

Contributing and funding sections are listed as well, along with the licence. For anyone evaluating the package, the practical sequence is the one the introduction gives: PHP 7.2 with the four required extensions, Composer, the two-command project install, then phpcs against your codebase with the standard you want.

Editorial conclusion

WordPressCS suits a PHP project that wants WordPress conventions enforced in CI without hand-picking sniffs, and the WordPress standard gives you the whole set while the subsets let you narrow it. Install it per project rather than globally, because the global instructions are the part of the documentation that still contains a placeholder you have to resolve yourself, and because a project-local install puts phpcs in vendor/bin where your build already knows how to find it. Remember the first command is not optional: without the allow-plugins configuration the Composer installer plugin is blocked and the rulesets never register. The floor is PHP 7.2 with four extensions enabled. The last push was on 2026-09-21 and the newest release is 3.4.1 from 2026-07-27.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. WordPress/WordPress-Coding-Standards on GitHub