How to Add WordPress Coding Standards: Setup Guide (Mac, Linux, Windows)

Every serious WordPress plugin or theme should pass WordPress Coding Standards (WPCS). The standards enforce consistent formatting, secure escaping, proper internationalization, sane prefixing, and dozens of other patterns that prevent common WordPress bugs. WPCS is what WordPress.org’s plugin review team checks against; it’s what every reputable agency runs in CI. Learning how to add WordPress coding standards to your local dev environment is a one-time setup that pays back across every project you ship.

WPCS runs on top of PHP_CodeSniffer (PHPCS) — the underlying linter — and ships as a Composer package. Once installed, two commands carry you through 90% of daily use: phpcs to find violations, phpcbf to auto-fix the ones that can be repaired automatically. The 10% that needs manual fixes is exactly the kind of thing WordPress reviewers (and serious code reviews) flag.

Quick verdict: install once globally via Composer, configure a phpcs.xml.dist per project, run phpcs before every commit. This guide walks through the install on macOS, Linux, and Windows step by step — plus WooCommerce Coding Standards on top, IDE integration for VS Code and PHPStorm, the most-used PHPCS commands, and a GitHub Actions workflow that fails PRs when the standards drift.

add WordPress coding standards: quick reference

If you are evaluating add WordPress coding standards for your next project, you are weighing real trade-offs between cost, complexity, ownership, and time-to-launch. The right add WordPress coding standards decision depends on a handful of variables — team capacity, scope clarity, and how much ongoing maintenance you can absorb. The summary below is the 60-second version; the rest of this guide unpacks the nuance.

• add WordPress coding standards pricing typically ranges based on scope clarity, integration count, and ongoing support requirements.
• add WordPress coding standards timelines vary from days (small scope) to months (enterprise scope) depending on complexity.
• The biggest variable in add WordPress coding standards is requirements clarity at the brief stage — vague briefs produce vague quotes.
• Vendor selection for add WordPress coding standards matters more than tool selection — the right team beats the right stack.
• add WordPress coding standards ROI is positive when scope is bounded, deliverables are specified, and success criteria are measurable.

For complementary perspectives on add WordPress coding standards, the WordPress Coding Standards on GitHub and PHP_CodeSniffer documentation resources cover adjacent angles worth reviewing alongside this guide. They focus on the underlying technology and standards — this post focuses on the add WordPress coding standards decision specifically.

When you revisit your add WordPress coding standards approach in 12 to 24 months, three signals usually indicate a refresh is justified. First, the original brief no longer matches business reality — product, audience, or operational scope has shifted. Second, the underlying technology has moved forward enough that the add WordPress coding standards decision made under previous constraints would be different today. Third, ongoing maintenance overhead has crept up beyond what was forecast at launch. None of these are emergencies on their own; together they signal it is time to revisit fundamentals rather than patch around them.

Why add WordPress Coding Standards to your dev environment?

WordPress Coding Standards are not just style preferences. The ruleset enforces real correctness patterns that prevent classes of bugs across every WordPress codebase.

• Security checks — flags unescaped output, unsanitized input, missing nonces, direct SQL without prepare. Catches roughly 70% of the issues that hit plugin-review rejections
• i18n correctness — verifies every user-facing string is wrapped in a translation function with a consistent text domain
• Naming conventions — enforces snake_case for functions, PascalCase for classes, namespacing prefixes for everything global
• WordPress version awareness — warns when code uses functions newer than your declared minimum WP version
• Code style — Yoda conditions, spacing, brace placement (the stylistic part — opinionated but consistent)
• Auto-fix support — about 30-40% of violations can be auto-repaired by PHPCBF without manual editing

The four WordPress coding standard rulesets

WPCS ships with four progressively stricter rulesets. Pick one per project based on what you actually need to enforce.

For new plugins, WordPress-Extra + WordPress-Docs is the right default. For plugins targeting the WordPress.org directory, use the full WordPress ruleset — the review team runs it against your submission.

Prerequisites for adding WordPress Coding Standards

WPCS needs three things on your machine. The platform-specific install sections below handle each in the right order.

• PHP 7.4 or newer on your PATH (PHP 8.2+ recommended for current WordPress)
• Composer — the PHP package manager
• Composer global bin directory on your PATH — so the phpcs command works from any terminal directory

Global vs per-project install: You can install WPCS globally (one install, works for all projects) or per-project (committed to each project’s composer.json). Global is simpler for daily dev work. Per-project is the right call for CI environments and team consistency. The install sections below cover global; the CI section later covers per-project.

Install WordPress Coding Standards on macOS

On macOS, the cleanest install path uses Homebrew for PHP + Composer, then Composer to fetch WPCS. The entire setup takes 5-10 minutes on a fresh machine.

# 1. Install Homebrew (skip if you already have it)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 2. Install PHP + Composer via Homebrew
brew install php composer

# 3. Install WordPress Coding Standards globally via Composer
composer global require --dev \
    wp-coding-standards/wpcs:"^3.1" \
    dealerdirect/phpcodesniffer-composer-installer:"^1.0"

# 4. Add Composer's global bin to your PATH (zsh — default on modern macOS)
echo 'export PATH="$HOME/.composer/vendor/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

# 5. Verify
phpcs -i
# Expected output includes: WordPress, WordPress-Core, WordPress-Extra, WordPress-Docs

PATH note for macOS: Modern macOS uses zsh as the default shell, so ~/.zshrc is correct. Older macOS (10.14 and earlier) or users on Oh My Bash use ~/.bash_profile instead. If phpcs -i shows “command not found” after install, double-check the PATH export went into the right shell config.

Install WordPress Coding Standards on Linux

Linux instructions below target Ubuntu and Debian. For Fedora / RHEL, swap apt for dnf and adjust package names slightly. The pattern is identical: install PHP CLI, install Composer, use Composer to fetch WPCS.

# 1. Install PHP CLI + Composer (Ubuntu / Debian)
sudo apt update
sudo apt install -y php-cli php-mbstring php-xml unzip curl

# 2. Install Composer
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer

# 3. Install WordPress Coding Standards globally
composer global require --dev \
    wp-coding-standards/wpcs:"^3.1" \
    dealerdirect/phpcodesniffer-composer-installer:"^1.0"

# 4. Add Composer's global bin to PATH (bash — default on Ubuntu)
echo 'export PATH="$HOME/.config/composer/vendor/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

# 5. Verify
phpcs -i

Composer bin path on Linux: On Linux, the Composer global bin directory lives at ~/.config/composer/vendor/bin — different from macOS’s ~/.composer/vendor/bin. If you copy commands between machines, this is the most common path mismatch.

Install WordPress Coding Standards on Windows

Windows requires either WSL (Windows Subsystem for Linux — use the Linux instructions inside WSL) or native PowerShell with Chocolatey for PHP/Composer. The native PowerShell path:

# Run all commands in PowerShell. Some steps need Administrator privileges.

# 1. Install Chocolatey (skip if already installed) — run as Administrator
Set-ExecutionPolicy Bypass -Scope Process -Force
[System.Net.ServicePointManager]::SecurityProtocol = `
    [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

# 2. Install PHP and Composer
choco install php composer -y

# 3. Refresh environment variables in the current PowerShell session
refreshenv

# 4. Install WordPress Coding Standards globally
composer global require --dev `
    "wp-coding-standards/wpcs:^3.1" `
    "dealerdirect/phpcodesniffer-composer-installer:^1.0"

# 5. Add Composer's global bin to your user PATH
# Composer global bin is at: %APPDATA%\Composer\vendor\bin
[System.Environment]::SetEnvironmentVariable(
    "PATH",
    "$env:APPDATA\Composer\vendor\bin;" + [System.Environment]::GetEnvironmentVariable("PATH","User"),
    "User"
)
# Open a NEW PowerShell window so the PATH change takes effect, then verify:
phpcs -i

Recommended: use WSL on Windows: For most WordPress dev work, WSL2 + Ubuntu gives a smoother experience than native Windows PHP — most WordPress tooling assumes Unix-like paths and shell. Install WSL via wsl --install in an Administrator PowerShell, then follow the Linux instructions inside the WSL shell. Native PowerShell works fine but requires more PATH wrangling.

Verify the WordPress Coding Standards install

After installing on any platform, confirm phpcs sees the WordPress rulesets:

# Confirm phpcs is on your PATH
which phpcs            # macOS / Linux
where phpcs            # Windows (PowerShell)

# List installed rulesets
phpcs -i
# Expected: The installed coding standards are MySource, PEAR, PSR1, PSR2,
# PSR12, Squiz, Zend, WordPress, WordPress-Core, WordPress-Extra,
# WordPress-Docs and ...

# Show phpcs version
phpcs --version

If phpcs -i does not list “WordPress” among the installed standards, the most likely cause is that the Composer installer did not link WPCS into PHPCS. Run composer global update and re-check.

Add WooCommerce Coding Standards (WCS)

WooCommerce Coding Standards (WCS) is a separate Composer package that extends WPCS with WooCommerce-specific rules — proper prefixing, WC function deprecation checks, HPOS-aware patterns, and WooCommerce-specific i18n text domains. If you build WooCommerce plugins, install WCS on top of WPCS:

# Install WooCommerce Coding Standards on top of WPCS
composer global require --dev "woocommerce/woocommerce-sniffs:^1.0"

# Verify — phpcs -i should now also list WooCommerce + WooCommerce-Core
phpcs -i

# Use the WooCommerce ruleset when scanning a WooCommerce plugin
phpcs --standard=WooCommerce path/to/your-woo-plugin/

WPCS is a prerequisite for WCS: WooCommerce Coding Standards extends WordPress Coding Standards — it does not replace them. Install WPCS first, then install WCS on top. Running phpcs --standard=WooCommerce automatically pulls in the WordPress rules as well.

Configure your code editor

Running PHPCS from the terminal is fine, but seeing violations inline as you type is dramatically better. Both VS Code and PHPStorm have first-class WPCS integration.

VS Code setup

Install the “phpcs” extension (publisher: shevaua), then add to your project’s .vscode/settings.json:

// VS Code — install the "phpcs" extension (shevaua.phpcs), then in
// .vscode/settings.json:
{
    "phpcs.enable": true,
    "phpcs.executablePath": "/Users/you/.composer/vendor/bin/phpcs",
    "phpcs.standard": "WordPress",
    "phpcs.lintOnType": false,
    "phpcs.lintOnOpen": true,
    "phpcs.lintOnSave": true
}

Replace the phpcs.executablePath with your actual path (use which phpcs on macOS/Linux or where phpcs on Windows to find it). Violations now appear as inline warnings and in the Problems panel.

PHPStorm setup

PHPStorm has native PHPCS support — no extension required. Go to Preferences → PHP → Quality Tools → PHP_CodeSniffer, click the gear icon, point to your phpcs binary. Then under Preferences → Editor → Inspections → PHP → Quality Tools → PHP_CodeSniffer validation, enable it and pick “WordPress” (or your project’s phpcs.xml.dist) as the coding standard. Violations appear inline immediately.

Run PHPCS and PHPCBF on your code

The two commands you’ll use daily. phpcs finds violations; phpcbf auto-fixes the subset that PHPCS can repair automatically.

# Run PHPCS against a single file
phpcs path/to/file.php

# Run against an entire plugin / theme directory
phpcs path/to/your-plugin/

# Use a specific ruleset (overrides phpcs.xml.dist if present)
phpcs --standard=WordPress-Extra path/to/your-plugin/

# Summary report only (no per-line output) — useful for high-level overview
phpcs --report=summary path/to/your-plugin/

# Auto-fix violations PHPCBF can repair (formatting, escaping, etc.)
phpcbf path/to/your-plugin/

# Limit to one file to test changes safely
phpcbf path/to/file.php

Workflow: run phpcbf first to auto-fix everything that’s mechanical (spacing, escaping patterns, Yoda conditions). Then run phpcs to see what’s left — those need manual fixes. Commit each step separately so the diff is clean.

Set up a phpcs.xml.dist for your project

A project-level config file lets you commit your WPCS configuration alongside your code, so every contributor uses the same rules and excluded paths. Save this as phpcs.xml.dist at the root of your plugin/theme:

<?xml version="1.0"?>
<ruleset name="My WordPress Project">
    <description>WordPress Coding Standards for this plugin.</description>

    <!-- What to scan -->
    <file>.</file>
    <exclude-pattern>*/vendor/*</exclude-pattern>
    <exclude-pattern>*/node_modules/*</exclude-pattern>
    <exclude-pattern>*/build/*</exclude-pattern>
    <exclude-pattern>*/tests/data/*</exclude-pattern>

    <!-- Pick the WordPress rulesets you want to enforce -->
    <rule ref="WordPress-Extra"/>
    <rule ref="WordPress-Docs"/>

    <!-- Target PHP + WordPress versions -->
    <config name="minimum_supported_wp_version" value="6.0"/>
    <config name="testVersion" value="7.4-"/>

    <!-- Restrict to PHP files -->
    <arg name="extensions" value="php"/>

    <!-- Display progress + show source codes in output -->
    <arg value="ps"/>

    <!-- Tell the i18n sniff which text domains are valid for this project -->
    <rule ref="WordPress.WP.I18n">
        <properties>
            <property name="text_domain" type="array">
                <element value="my-text-domain"/>
            </property>
        </properties>
    </rule>
</ruleset>

With this file in place, running phpcs from the project root uses your config automatically — no --standard flag needed. The .dist suffix is convention for “default config” that’s committed to git; individual developers can override locally with phpcs.xml (which should be in .gitignore).

Automate WordPress Coding Standards with GitHub Actions

Once PHPCS runs cleanly locally, run it in CI so failing PRs are caught before merge. The simplest GitHub Actions workflow:

name: PHP_CodeSniffer

on:
  pull_request:
  push:
    branches: [main]

jobs:
  phpcs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          tools: composer:v2, cs2pr

      - name: Install Composer dependencies
        run: composer install --prefer-dist --no-progress

      - name: Run PHP_CodeSniffer
        run: ./vendor/bin/phpcs --report=checkstyle | cs2pr

Save as .github/workflows/phpcs.yml. The cs2pr tool turns PHPCS output into GitHub PR annotations so violations show up as inline comments on the PR diff. Add WPCS + the Composer installer to your project’s composer.json dev dependencies so the CI install pulls them in.

Troubleshooting common WPCS install errors

Five recurring errors and their fixes:

• “command not found: phpcs” — Composer’s global bin directory is not on your PATH. Re-check the platform-specific PATH export in the install steps above. Confirm with echo $PATH (macOS/Linux) or $env:PATH (Windows PowerShell)
• “phpcs -i” shows PSR1/PSR2 but no WordPress — the dealerdirect/phpcodesniffer-composer-installer package isn’t installed or didn’t link WPCS into PHPCS. Run composer global update and re-check
• “Class not found” PHP errors — your PHP version is too old (PHPCS 3.x requires PHP 5.4+; WPCS 3.x prefers PHP 7.4+). Upgrade PHP or use a Composer-pinned older WPCS version
• WPCS 2.x vs 3.x conflicts — older tutorials reference WPCS 2.x. The install commands here use the 3.x branch which dropped support for older PHP versions but added significant rule improvements. If you must use WPCS 2.x, pin via composer global require wp-coding-standards/wpcs:"^2.3"
• “sniff X is deprecated” warnings — your WPCS version is older than the ruleset you’re using. Run composer global update wp-coding-standards/wpcs to update

Keeping WordPress Coding Standards up to date

WPCS releases minor versions roughly quarterly and major versions every 1-2 years. Updates add new rules, refine existing ones, and bump minimum PHP versions. Update strategy:

• Run composer global update wp-coding-standards/wpcs when you start a new project — pull the latest rules
• Per-project: pin the WPCS version in composer.json so CI runs the same rules locally — predictable builds
• Review the WPCS changelog when bumping major versions — new rules may flag existing code that was previously passing
• Update WooCommerce Coding Standards alongside WPCS — composer global update woocommerce/woocommerce-sniffs

Installation — FAQs

How do I add WordPress Coding Standards on macOS?

Install Homebrew, then run brew install php composer, then composer global require --dev wp-coding-standards/wpcs:"^3.1" dealerdirect/phpcodesniffer-composer-installer:"^1.0". Add $HOME/.composer/vendor/bin to your PATH in ~/.zshrc. Verify with phpcs -i — it should list WordPress, WordPress-Core, WordPress-Extra, WordPress-Docs.

How do I add WordPress Coding Standards on Windows?

Two paths. Recommended: use WSL2 + Ubuntu, then follow the Linux install steps inside the WSL shell. Native PowerShell path: install Chocolatey, then choco install php composer, then composer global require --dev "wp-coding-standards/wpcs:^3.1" "dealerdirect/phpcodesniffer-composer-installer:^1.0". Add %APPDATA%\Composer\vendor\bin to your user PATH via System Properties or PowerShell’s SetEnvironmentVariable.

Can I install WordPress Coding Standards per-project instead of globally?

Yes — add wp-coding-standards/wpcs + dealerdirect/phpcodesniffer-composer-installer to your project’s composer.json as require-dev entries. After composer install, run via ./vendor/bin/phpcs. Per-project is the right pattern for team consistency and CI. Global is fine for daily dev work on personal machines.

Configuration — FAQs

Which WordPress coding standard ruleset should I use?

For new plugins: WordPress-Extra + WordPress-Docs — covers security, correctness, naming, and docblocks without overwhelming you with style nits. For WordPress.org plugin directory submissions: use the full WordPress ruleset (Core + Extra + Docs) — that’s what the review team runs. For pre-existing legacy codebases: start with WordPress-Core only (style-only) and graduate to Extra once the codebase is closer to compliance.

What's the difference between WordPress Coding Standards (WPCS) and WooCommerce Coding Standards (WCS)?

WPCS covers WordPress core patterns — security, i18n, naming, escaping. WCS is a smaller ruleset that extends WPCS with WooCommerce-specific rules: WC function deprecation checks, HPOS-aware patterns, WooCommerce-specific text domains, proper prefixing for WC extensions. If you build WooCommerce plugins, install both. Running phpcs --standard=WooCommerce automatically includes the WordPress rules.

How do I exclude generated files from PHPCS?

Use <exclude-pattern> in your phpcs.xml.dist. Common exclusions: */vendor/*, */node_modules/*, */build/*, */tests/fixtures/*. You can also exclude specific rules via <rule ref="..." /><exclude name="rule.name"/></rule> when you need to skip individual checks.

Editor + CI — FAQs

Does PHPStorm support WordPress Coding Standards out of the box?

PHPStorm has built-in PHP_CodeSniffer support. Point it at your phpcs binary under Preferences → PHP → Quality Tools → PHP_CodeSniffer, then enable PHPCS inspection under Inspections → PHP → Quality Tools → PHP_CodeSniffer validation, and pick “WordPress” (or your project’s phpcs.xml.dist) as the standard. Violations appear inline immediately, with quick-fix actions for the auto-fixable ones.

How do I integrate PHPCS with GitHub Actions CI?

Create .github/workflows/phpcs.yml with the workflow shown in this guide. It installs PHP, installs Composer dependencies (including WPCS via your project’s composer.json), then runs ./vendor/bin/phpcs --report=checkstyle | cs2pr. The cs2pr tool turns PHPCS output into inline PR annotations so violations show up as comments on the diff. Failing checks block merging when branch protection is enabled.

How often should I update WordPress Coding Standards?

For active projects, update when you start a new feature branch — composer global update wp-coding-standards/wpcs on personal install, or bump the version in composer.json for per-project installs. For long-running stable projects, pin the WPCS version so CI doesn’t drift; bump intentionally during sprint planning when reviewing changelog. WPCS major versions occasionally add aggressive new rules — always test before bumping in production CI.