WordPress Coding Standards 3.4.0 was released on July 16, 2026. A Composer update can change WPCS, PHP_CodeSniffer, PHPCSUtils, and related behavior together, so a new CI result must be separated into new rule findings, dependency changes, configuration drift, and real regressions before mass autofixing.
Use this for WordPress plugins, themes, agency repositories, monorepos, and release pipelines that run PHPCS locally or in GitHub Actions across multiple PHP versions.
Quick answer
Create a branch, record current Composer and PHPCS versions, update WPCS with dependencies, and run the same file set before changing the ruleset. Classify new findings by sniff and path. Update intentional compatibility configuration explicitly, review PHPCBF changes separately, and require local and CI parity.
What to check first
- Record PHP, Composer, WPCS, PHP_CodeSniffer, PHPCSUtils, installed_paths, ruleset path, file includes, exclusions, severity, and current CI command.
- Save the pre-upgrade Composer lock, phpcs -i output, phpcs --config-show output, and machine-readable baseline report.
- Update wp-coding-standards/wpcs with dependencies on a dedicated branch and inspect every lockfile change before running code fixes.
- Compare findings by sniff code and file, separating newly enforced rules from files that CI previously skipped or parsed differently.
- Run PHPCBF only on a reviewable subset, inspect semantic changes, then test supported PHP versions and the packaged plugin artifact.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture the existing toolchain and report | Record PHP, Composer, WPCS, PHP_CodeSniffer, PHPCSUtils, installed_paths, ruleset path, file includes, exclusions, severity, and current CI command. | Composer lock and installed standards match the reviewed branch. |
| Update WPCS with a reviewed lockfile | Save the pre-upgrade Composer lock, phpcs -i output, phpcs --config-show output, and machine-readable baseline report. | Local and CI commands scan the same paths with the same ruleset. |
| Classify new findings by sniff | Update wp-coding-standards/wpcs with dependencies on a dedicated branch and inspect every lockfile change before running code fixes. | New errors and warnings are classified by sniff code. |
| Apply narrow manual or autofix changes | Compare findings by sniff code and file, separating newly enforced rules from files that CI previously skipped or parsed differently. | The packaged plugin passes tests after any autofix changes. |
Why this usually happens
- Composer can update transitive standards and utilities with WPCS.
- A ruleset path or installed_paths difference can make local and CI runs use different standards.
- New sniffs can expose existing debt without indicating a runtime regression.
- Automatic fixes can alter whitespace, comments, arrays, or escaping in a large diff that hides manual mistakes.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
composer show wp-coding-standards/wpcs squizlabs/php_codesniffer phpcsstandards/phpcsutils
vendor/bin/phpcs -i
vendor/bin/phpcs --config-show
vendor/bin/phpcs -ps --report=json --report-file=artifacts/phpcs-3.4.json .
# Review by sniff code before running phpcbf on selected paths.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture the existing toolchain and report
- Update WPCS with a reviewed lockfile
- Classify new findings by sniff
- Apply narrow manual or autofix changes
- Prove local, CI, PHP, and package parity
Decision rule
Merge when dependency changes are understood, every new finding is fixed or explicitly justified in the ruleset, PHPCBF changes are reviewed, and the same command passes locally and in CI on supported PHP versions.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Composer lock and installed standards match the reviewed branch.
- Local and CI commands scan the same paths with the same ruleset.
- New errors and warnings are classified by sniff code.
- The packaged plugin passes tests after any autofix changes.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Should a team exclude every new WPCS finding to keep CI green?
No. Classify them first. Use narrow, documented exclusions only when a rule does not fit the project or must be phased in.
Is PHPCBF safe to run on the entire plugin?
It can be useful, but review a small subset first and keep automated formatting separate from behavioral changes.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, audit a WordPress plugin CI upgrade.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Adopt WPCS 3.4 without hiding new failures
Use the WPCS 3.4 baseline migration to classify new findings and prevent baseline growth. The WPCS 3.4 PHP version CI matrix separates the standards toolchain from plugin runtime coverage.
Apply the WPCS 3.4.1 security correction
Update every executing environment with the WPCS 3.4.1 command execution security guide. Then use the untrusted pull request CI hardening guide to remove secrets, write permissions, persistent runners, and trusted caches from contributor scans.
Helpful references