WPCS 3.4.1 fixes command execution when affected rulesets scan untrusted PHP. A project can lock the corrected package while a global Composer home, PHPCS installed path, editor, pre-commit hook, container, or shell alias still loads an older WordPress standards directory.
Use this for WordPress agencies, plugin vendors, marketplaces, CI owners, and developer fleets that have ever installed PHPCS or WPCS globally or configured `installed_paths` manually.
Quick answer
On every host and execution context, resolve the actual PHPCS binary, print its version, list registered standards, inspect global Composer home and `installed_paths`, and run a known fixture. Compare terminal, editor, hook, container, and CI. Remove stale paths, pin the project vendor binary, restart cached integrations, and block untrusted scans until the corrected runtime is proven.
What to check first
- Inventory macOS, Linux, Windows, WSL, remote SSH, dev containers, CI images, shared runners, editor extensions, hooks, shell aliases, global Composer bins, and project vendor directories.
- Capture user, host, workspace, executable path, symlink target, PHP runtime, PHPCS version, Composer home, WPCS package version, registered standards path, active ruleset, and process command line.
- Check PHPCS configuration at system, user, project, editor, remote, and container scope for manual `installed_paths` entries that can shadow or combine standards.
- Run one harmless known fixture through terminal, editor, pre-commit, and CI, then compare runtime path, WPCS version, finding IDs, exit code, and file path.
- Remove or quarantine stale global copies, pin `vendor/bin/phpcs`, rebuild images and caches, restart editor hosts, and add a fleet assertion for WPCS 3.4.1 or later.
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 |
|---|
| Inventory every execution context | Inventory macOS, Linux, Windows, WSL, remote SSH, dev containers, CI images, shared runners, editor extensions, hooks, shell aliases, global Composer bins, and project vendor directories. | Terminal, editor, hook, container, and CI report the approved runtime path and WPCS version. |
| Resolve binary and standards paths | Capture user, host, workspace, executable path, symlink target, PHP runtime, PHPCS version, Composer home, WPCS package version, registered standards path, active ruleset, and process command line. | PHPCS registered standards include only intended locations with no stale global directory. |
| Compare a known fixture | Check PHPCS configuration at system, user, project, editor, remote, and container scope for manual `installed_paths` entries that can shadow or combine standards. | The known fixture returns the same finding set and exit code everywhere. |
| Remove stale global registrations | Run one harmless known fixture through terminal, editor, pre-commit, and CI, then compare runtime path, WPCS version, finding IDs, exit code, and file path. | Untrusted PHP cannot reach a scanner with secrets, persistent write access, or an affected WPCS runtime. |
Why this usually happens
- Global Composer home is independent from each project lock file.
- PHPCS can register additional standards paths that remain after package updates.
- Editors and hooks can launch a different binary from the interactive shell.
- Containers, remote workspaces, and CI caches can preserve old vendor trees and configuration.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
command -v phpcs
readlink -f "$(command -v phpcs)"
phpcs --version
phpcs -i
phpcs --config-show installed_paths
composer global config home
composer global show wp-coding-standards/wpcs
vendor/bin/phpcs --version
vendor/bin/phpcs -i
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.
- Inventory every execution context
- Resolve binary and standards paths
- Compare a known fixture
- Remove stale global registrations
- Enforce the project runtime
Decision rule
Close only when every active scanner invokes the approved binary, reports WPCS 3.4.1 or later, loads the intended standards path and ruleset, and cannot silently fall back to a stale global copy.
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
- Terminal, editor, hook, container, and CI report the approved runtime path and WPCS version.
- PHPCS registered standards include only intended locations with no stale global directory.
- The known fixture returns the same finding set and exit code everywhere.
- Untrusted PHP cannot reach a scanner with secrets, persistent write access, or an affected WPCS runtime.
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, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Does updating composer.lock fix global WPCS?
No. Global Composer packages and PHPCS configuration must be audited separately.
Can global PHPCS use project standards safely?
It can, but a project-local binary and locked dependencies make the execution path easier to prove and maintain.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, audit WordPress code-scanning runtimes.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references