-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Audit Public Sniff Properties #234
Comments
One approach here would be to initially make all of the |
Here are all of the public properties. Some of them will be false poitives (i.e. should be left as
|
Working list (will be edited) for properties not yet checked or excluded:
|
At this point, I don't think we've seen a sufficient number of users trying to amend public property values to the point where the expected default content is not present. While it would be nice to be confident that some minimum default values are present, that users can supplement, I don't think that adding this in, in a more formalised way, is the best use of time right now. Can be re-opened again if the issue is deemed worthy, or individual properties can be dealt with on a case-by-case basis. |
Proposal: for those properties for which the visibility ought to be changes, add the new That way customers, who would be (ab)using the fact that these properties are currently |
What problem would the enhancement address for VIP?
There are 47 instances of public properties within sniff classes. Public properties allow changing sniff behaviour by customising a ruleset by passing different types of values via the ruleset. VIP uses itself to adjust how a WPCS sniff runs.
However, I suspect that some of the instances are NOT meant to be changed - whitelisted Batcache params, restricted constant names and declarations, etc.
Describe the solution you'd like
Audit the uses and convert to
private
where suitable. Document the rest on a wiki page.I'll create a linked list of the 47 instances, possibly along with who added them, to check if they are meant to be public or not.
For those that are meant to be changeable, then a better approach for some cases is to have a private default list of values, and then a public custom list, and the two lists merged together - that way, the custom rulesets don't need to also add in the default values as well.
Additional context
Note that this would technically be a breaking change, since it is possible that someone was already making use of these unintentional public properties in their own rulesets. As such, this would require a bump from
0.y.z
to0.y+1.0
, or a normal major release if1.0.0
has been released in the meantime.The text was updated successfully, but these errors were encountered: