Running Plugin Check in strict mode (fail on any WARNING, not just ERRORs) is a good release gate. The catch: sometimes a warning is known and accepted, and you still want strict mode for everything else.
Our release tool, wp-release, handles that with an allow-list. The rules:
- Only WARNINGs can be allowed. ERRORs can never be allowed.
- Each rule is a bare PCRE body, matched (with the u flag) against the string "<code>: <message>". An invalid regex stops the run with exit code 2.
- Nothing is allowed by default. Rules come from --allow (repeatable), the MMWP_PCP_ALLOW environment variable, or "allow" in mmwp-release.json, and they are merged.
- Allowed findings stay visible. They are listed as "ALLOWED: <code>: <message> (rule: <regex>)", the summary reads "N error(s), M warning(s), K allowed", and plugin-check.json records them. They just don't count toward the strict failure or the deploy gate.
Our own case: Plugin Check flags the "wp" in "MammothWP" as trademarked_term. The rule we use matches only that code, and only when the quoted name contains mammothwp, so the same warning about any other name still fails the build:
mmwp-release check --strict --allow='(?i)^trademarked_term: (?=.*(?<![a-z0-9])mammothwp)(?=.*restricted term \W?wp\W)'
The lesson that carries over to any CI setup: when you silence a check, scope the exception to the exact finding, keep it in the report, and never let it cover the severe level.
wp-release is GPLv2 or later. Build, check and deploy guide: https://mammothwp.com/guides/build-check-deploy-wordpress-plugin-wp-release/
Drafted with AI assistance and reviewed by the MammothWP team.
Top comments (0)