[New Sniff] Make sure widget_title filter has all parameters about wpthemereview

[jrfnl]

This issue raises a number of questions:

• Is this the only filter where a check like this would need to take place or are there / will there be more actions/filters where the parameters will need to be checked ?
• Does the check need to be for the amount of parameters passed or also need to go into the content ? (If the answer would be 'content', that would be neigh impossible as variables can be named differently across themes.)

Questions from an implementation perspective:

• Do we need to create a re-usable abstract class which handles a large part of the logic and can be extended for individual actions/filters or small groups thereof ?
• If this will be the only one, we can just use a hard-coded check, if not, we may need to have an extensible array property listing the hooks or in the case of the abstract, possibly a function instead.

Also: is there a rule in the handbook covering this or should it be added ?

[justintadlock]

Is this the only filter where a check like this would need to take place or are there / will there be more actions/filters where the parameters will need to be checked ?

Not sure if there are others at the moment.

Does the check need to be for the amount of parameters passed or also need to go into the content ? (If the answer would be 'content', that would be neigh impossible as variables can be named differently across themes.)

Amount is doable and would make theme devs aware of the issue.

Do we need to create a re-usable abstract class which handles a large part of the logic and can be extended for individual actions/filters or small groups thereof ?
If this will be the only one, we can just use a hard-coded check, if not, we may need to have an extensible array property listing the hooks or in the case of the abstract, possibly a function instead.

There's few cases of themes needing to call core WP hooks like this. It's really a poor implementation on core's part to be honest.

I really can't think of another example off the top of my head, but I'll leave it open to others.

Also: is there a rule in the handbook covering this or should it be added ?

We don't currently have a specific rule to this specific case. It falls under the more general "Use template tags and action/filter hooks properly" guideline. See: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

[carolinan]

If custom widgets are no longer allowed this would be a non issue?

[joyously]

Perhaps, but we haven't gotten rid of custom widgets yet. My theme in particular relies on my custom widgets for its flexibility.

[dingo-d]

We could maybe add a warning sniff about possible depreciation of custom widgets, but I guess this depends on how the gutenberg widget thing will progress...

[dingo-d]

We need to see how relevant this issue is in the context of widgets being moved to core blocks.

Also, we got the info about unused parameters in actions and hooks in general, but that sounds more like a WPCS issue to me.

Thoughts @jrfnl?

[jrfnl]

Also, we got the info about unused parameters in actions and hooks in general, but that sounds more like a WPCS issue to me.

I agree. I think someone should probably check if there is a WPCS issue open for this, and if not, open one.

I imagine it would be good to have one generic sniff which checks that if any of the WP core hooks are invoked in a plugin/theme (or in core itself) that the amount of parameters passed is the same as in the original hook definition used in Core.

This would be a horrific sniff to maintain though unless we also create a second (non-public) sniff to scan core on each release which would update the (public) sniff, see WordPress/WordPress-Coding-Standards#1803 for more information about that principle.

[dingo-d]

I like that idea, especially if we would have the extra utility sniff in the linked issue 🙂 That would help with the maintenance. I'll open up an issue upstream, and close this one 👍