[wp-trac] [WordPress Trac] #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
WordPress Trac
noreply at wordpress.org
Thu Sep 8 14:37:22 UTC 2016
#17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
----------------------------------------------------+---------------------
Reporter: kernfel | Owner: pento
Type: defect (bug) | Status: closed
Priority: normal | Milestone: 4.7
Component: Plugins | Version: 2.2
Severity: normal | Resolution: fixed
Keywords: has-patch needs-testing has-unit-tests | Focuses:
----------------------------------------------------+---------------------
Comment (by flixos90):
A small improvement idea: I think it would make sense to separate the
`WP_Hook::has_filter()` and `WP_Hook::has_filters()` methods completely so
that both have a single responsibility: The `$function_to_check` parameter
would become required for `WP_Hook::has_filter()` and we would no longer
call `WP_Hook::has_filters()` from `WP_Hook::has_filter()`. The logic to
be backwards compatible could then happen in the regular `has_filter()`
function - this way at least the new class methods would only have one
specific purpose.
Another thing I observed: This might have a reason I'm overlooking right
now, but why aren't we storing the tag (hook name) in the class as
property (and pass it to the constructor)? This would allow us to get rid
of passing the `$tag` parameter on all the methods. Sorry to come up with
this now, I haven't really paid attention to this movement before :(
--
Ticket URL: <https://core.trac.wordpress.org/ticket/17817#comment:223>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list