has_filter() can return 0, and remove_filter() doesn't use $accepted_args

[nacin]

has_filter() returns priority, which means it can return 0. But core doesn't check for it being identical to false. We should audit all has_filter() calls and make sure 'false !==' or 'false ===' depending on what we want.

Additionally remove_filter() has an $accepted_args argument, but doesn't use it. We should eliminate it from the function definition and docs.

[nacin]

We do currently check false === has_filter() in wp-login.php.

[ryan]

Oh, okay.

[georgestephanis]

I'm refreshing the ticket now, it didn't apply cleanly -- we really should do this for has_action as well. Adding that in.

[nacin]

So, has_filter() and has_action() only returns the priority when $function_to_check is also passed. Otherwise, if you're just checking the hook, it returns a boolean.

In core, we never use the second argument. So, there's no need for us to be careful about its use. This is nothing more than a documentation issue.

[georgestephanis]

In which case can we just include a doing_it_wrong() call or the like when some third-party code tries to pass something as priority zero? We're leaving a (small, but existant) hole open for people to do things that could lead to our checks in core returning an untrue result.

EDIT: Ignore the above, I just reread the code and found the short-circuit for false.

[nacin]

In [21288]:

Clarify the return value of has_filter() and has_action(). It returns a boolean if only the first argument is specified. If the second argument is specified, it returns false or an integer, which means it may return a non-boolean value that evaluates to false (so, 0), so you should take care to use the === operator.

Correct the function definition of remove_filter() and remove_action(), which 'accepted' an $accepted_args argument, but did not require or use it.

fixes #19417.