On the command line phpcs:ignore is bypassed by your rules.
The rule affecting it is <arg name="ignore-annotations" />.
1 Like
I don’t know my own added rules lol fffffff*****
Thanks for the correction, I looked at the completely wrong rule 
Confirmed it works as intended and indeed is now ignored if I were to remove that rule.
If I understand this correctly (and yes you actually mentioned that earlier already), it does not allow to execute code unless you as dev add a filter allowing it.
So that means we do not allow this “in a plugin”, like by default, but we allow it (well, can’t be avoided, really) thru a filter. Makes sense!
1 Like
<exclude name="WordPress.Security.ValidatedSanitizedInput.InputNotValidated"/>
This rule does not check something that is strictly speaking security related.
It checks upon validation, which is not sanitization or security, it rather avoids errors.
Yet, it is in a group called Security… confusing.
What is the “liberal” wing’s opinion on this?
In my very conservative opinion, it should be in the rules used for evaluation and not be ignored.
Yet, if we do enforce that, there is quite a number of errors more a dev needs to “fix”.
As it is not a strict security issue and the dev is free to let his/her plugin fail with errors, I would not object to the freedom of producing errors. It does not put others security at risk. It will only upset them 
Right now, in the XML that rule is passed to the “ignore” group, thus no code is flagged when not validated.
However as I just noticed it is part of security group, thus now I am not sure anymore if we really should ignore it.
Improper input validation definitely has the potential to be a security issue: for example, if it is then saved to the database.
The only warning I’ve ever seen from that sniff is “accessing XY which maybe is undefined”
I am happy to add it back as sniff, however… I am not sure this is going to affect a database if some things are not validated (definitely sanitize is a problem, but the validation sniff seems merely a “is it defined” sniff)
The problem I see if I add it back is, since I see that error like too many times, folks will consider it “overkill”
And since we aren’t asked to check if their plugin actually works… I don’t see why a review would spend time convincing the dev that it’s safer to check if a $_POST variable is set or not (which is what that sniff more or less does)
Again, I’m definitely in the wing of those who would want it but I’m just trying to see from the point of view I’d those who do not like standards (or these standards)