[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