Exceptions to prefixing hook names about wpthemereview

[jrfnl]

The sniff covers both actions as well as filters.

Generally speaking, themes should hook into core filters and actions and shouldn't ever need to invoke the core hooks.

There are always exceptions, of course. In that case, the invocation can be whitelisted and the reason for calling the core hook documented, like so:

// phpcs:ignore WordPress.NamingConventions.PrefixAllGlobals.NonPrefixedHooknameFound -- Invoking  core hook for reasons.....
do_action( 'name_of_core_hook' );

[timelsass]

False positive in something like: I have a loop creating markup and inserting actions:

do_action( $col_data[ $type ] );

Results in:

WARNING	Hook names invoked by a theme/plugin should start with the theme/plugin prefix. Found: "$col_data[ $type ]".

They vary depending on what plugins are installed.

I think hooks consisting of variables only should be excluded.

[joyously]

I don't think that's an exception. It should still start with the theme's prefix.

[timelsass]

Oh sorry, that example was unclear - that's being called from within a class and a function, so I wouldn't have prefixed the variable. I think the global variable sniff would be enough to alert about that though, there shouldn't be a reason why the hook name as only a variable should have to be checked further in that case.

[joyously]

We're not talking about prefixing variables here. We're talking about prefixing hook names. There are very few cases where themes should be calling do_action on unprefixed hook names.

[timelsass]

I know, the title of the ticket is "Exceptions to prefixing hook names," so I thought it made sense to place it here rather than a new ticket. Currently I'm getting the warnings above saying I should prefix the hook name, but it shouldn't be giving me one as it isn't contextually aware of what is stored inside of the variable, and I think that situation should be an exception to the existing sniff.

The note about the prefixing variables is saying that even if I were using a variable in the global namespace and calling do_action( $something ) directly in a template file, I would still get this error. Even in those situations it's not needed since variables already have checks for prefixing those names, and the sniff isn't aware of the value assigned to $something.

[dingo-d]

Should we have a sniff for that, or maybe some kind of whitelist added in the ruleset.xml (if this is possible ofc) for this?

Otherwise I'd like to close this as a part of the issue grooming process 🙂