A repository can lock WPCS 3.4.1 while VS Code, PhpStorm, a language server, remote container, or preconfigured formatter invokes a global PHPCS binary with an older WordPress standards path. The editor then remains vulnerable or reports different results from CI.
Use this for WordPress development teams that run PHPCS in editors, dev containers, remote workspaces, language servers, save hooks, or shared workstation images.
Quick answer
For every editor and workspace, capture the configured PHPCS executable, the process command line, PATH resolution, registered standards paths, WPCS version, active ruleset, and project root. Point the integration to the project vendor binary, reopen the workspace, run one known fixture, and prove the editor plus terminal plus CI report the same corrected runtime.
What to check first
- Inventory VS Code extensions, PhpStorm quality tools, language servers, Neovim integrations, remote SSH sessions, dev containers, WSL, global Composer bins, and workspace-specific settings.
- Capture editor settings at user, remote, workspace, and folder scope because a lower-level override can shadow the corrected project configuration.
- Inspect the launched process or extension log for executable path, working directory, standard argument, config file, installed_paths, PHP runtime, and environment PATH.
- Run a harmless known fixture in editor, terminal, pre-commit, and CI, then compare WPCS version, ruleset, exit code, finding IDs, and file paths.
- Remove stale global standards paths where practical, pin the project binary, restart the editor host, and document an automated fleet check for future security updates.
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 editor integrations | Inventory VS Code extensions, PhpStorm quality tools, language servers, Neovim integrations, remote SSH sessions, dev containers, WSL, global Composer bins, and workspace-specific settings. | Editor logs show the repository vendor/bin/phpcs path from the correct workspace. |
| Capture resolved process paths | Capture editor settings at user, remote, workspace, and folder scope because a lower-level override can shadow the corrected project configuration. | Editor, terminal, hook, and CI report the same WPCS version and finding set for the fixture. |
| Compare one known fixture | Inspect the launched process or extension log for executable path, working directory, standard argument, config file, installed_paths, PHP runtime, and environment PATH. | Global or cached older standards paths cannot be selected silently. |
| Pin the project vendor binary | Run a harmless known fixture in editor, terminal, pre-commit, and CI, then compare WPCS version, ruleset, exit code, finding IDs, and file paths. | A documented machine-readable check detects future path drift across the developer fleet. |
Why this usually happens
- Editor settings can override repository configuration at user or remote scope.
- A global Composer bin directory may appear before vendor/bin in the editor process PATH.
- Remote containers and WSL can have a different filesystem and package set from the host terminal.
- An extension can cache an executable path until its language server or editor host restarts.
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)"
vendor/bin/phpcs --version
vendor/bin/phpcs -i
composer show wp-coding-standards/wpcs
composer config --global home
# Compare these paths with the editor extension output log and workspace settings.
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 editor integrations
- Capture resolved process paths
- Compare one known fixture
- Pin the project vendor binary
- Restart and enforce fleet checks
Decision rule
Pass when every supported editor, remote workspace, terminal, hook, and CI job invokes the approved project runtime, reports WPCS 3.4.1 or later, loads the intended ruleset, and has no stale executable fallback.
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
- Editor logs show the repository vendor/bin/phpcs path from the correct workspace.
- Editor, terminal, hook, and CI report the same WPCS version and finding set for the fixture.
- Global or cached older standards paths cannot be selected silently.
- A documented machine-readable check detects future path drift across the developer fleet.
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
Can the editor use a global PHPCS with project WPCS?
It can, but resolution is easier to misconfigure. A project-local binary and locked dependencies provide clearer evidence.
Why did changing settings not work?
Restart the extension host or language server and check user, remote, workspace, and folder overrides.
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 developer security tooling.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references