Conversation
The skill covered conventions — the bootstrap pattern, file naming, type hints — but not what to do when PHPCS reports a failure. This adds the sniffs that fire most often on HM WordPress projects and the fix each one wants, the phpcs:ignore placement gotcha that makes a docblock look missing, and the snake_case rename cascade. Exclusions are framed as a discipline rather than a template: every exclude carries a reason, anything security-related takes a per-line phpcs:ignore instead of a project-wide exclude, and only the WPCS I18n crash and the PSR-4 filename conflict are presented as unavoidable. Co-Authored-By: Claude <noreply@anthropic.com>
svandragt
force-pushed
the
php-standards-fixing-violations
branch
from
September 21, 2026 14:56
1f3ed43 to
cdf1155
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The skill covers conventions — the bootstrap pattern, file naming, type hints, the HM-Minimum ruleset — but stops at the point where they are most useful: the moment PHPCS reports a failure and you have two hundred of them to work through.
This adds the sniffs that fire most on HM WordPress projects and the fix each one wants, drawn from putting a plugin through the standards from scratch.
What is in it
MissingShort,FunctionComment.Missing,MissingParamTag,LongNotCapital,MissingUnslash,InputNotSanitized,MissingNamespace.phpcs:ignoreplacement trap. An ignore between the docblock and the declaration breaks the association, so the sniff reports the docblock as missing and the obvious fix — adding a docblock that is already there — does nothing. Costs an hour the first time.Exclusions: discipline, not a template
The obvious thing to contribute here is a ready-made
phpcs.xml. I have deliberately not done that.A shared ruleset of exclusions turns one team's judgement into everyone's default, minus the reasoning that justified it.
So this frames exclusions as a practice — every
<exclude>carries a comment saying why, security sniffs take a per-linephpcs:ignorewith a reason instead — and presents only two as genuinely unavoidable:WordPress.WP.I18n, which crashes on PHP 8.x with WPCS 2.x from atrim(null)deprecation inside the sniff.What is not in it
No linting pipeline.
run-lintersalready covers discovering and running the tools, and duplicating it here would give two places to update. This assumes you have a failing run and need to fix it.How we checked
Documentation only — no code, nothing to execute. Every example is generic: no project names, file paths or client integrations. The sniff names were taken from real runs against the HM ruleset rather than from memory.