Allow apply_filters and do_action to accept a $tag array

[sc0ttkclark]

Example of use case that is growing in plugins:

$value = apply_filters( 'my_plugin_filter_' . $some_var, $value, $some_var, $another_var, $and_another );
$value = apply_filters( 'my_plugin_filter', $value, $some_var, $another_var, $and_another );

I myself am using, and I'm seeing a lot of cases where this specific method of filtering is used, providing developers with an easy way to add specificity to the filters/actions they want to hook into, instead of adding a catch-all filter and trying to add the extra code to check $some_var all over the place.

Birds do it, bees do it, even the WP core does it:

	do_action( "save_post_{$post->post_type}", $post_ID, $post, $update );
	do_action( 'save_post', $post_ID, $post, $update );
	do_action( 'wp_insert_post', $post_ID, $post, $update );

So examples here on simplified usage would be:

	do_action( array( "save_post_{$post->post_type}", 'save_post', 'wp_insert_post' ), $post_ID, $post, $update );

And from my plugin example above, simplified:

$value = apply_filters( array( 'my_plugin_filter_' . $some_var, 'my_plugin_filter' ), $value, $some_var, $another_var, $and_another );

This wouldn't require a *huge* change, in every filter/action function we add this support to for the $tag var, we simply add this to the top of the function itself.

For filters:

if ( is_array( $tag ) ) {
    $args = get_func_args();

    foreach ( $tag as $t ) {
        $args[ 0 ] = $t; // set $tag
        $args[ 1 ] = $value; // pass filtered $value

        $value = call_user_func_array( 'apply_filters', $args );
    }

    return $value;
}

For actions:

if ( is_array( $tag ) ) {
    $args = get_func_args();

    foreach ( $tag as $t ) {
        $args[ 0 ] = $t; // set $tag

        call_user_func_array( 'do_action', $args );
    }

    return;
}

If developers like this idea, I will code it up and get a patch out quickly.

[sc0ttkclark]

I'm also open to alternate functions like do_action_group / apply_filters_group (or named whatever), that would handle this logic instead.

[c3mdigital]

Related #14671

[nacin]

I think this is a duplicate of #14280.

[sc0ttkclark]

@nacin - That's for adding filters/actions. This is for applying/doing.

[nacin]

I think the question is the same: Why?

In many cases, sequential hooks won't have the same arguments passed. That's not the case for the ones you highlighted, but it is for many others.

It's also much more difficult to grok/read/understand. If you're looking for a filter, you now need to closely pay attention to make sure you're clearly noticing what the variable is being filtered (and generally, parameters being passed), as suddenly there is an array with commas for tag names.

Finally, there's no real benefit. The one benefit *could* be if the tags were not processed in order, and instead were merge and sorted by priority. So if you registered against save_post for 11 and wp_insert_post for 10, the callback attached to wp_insert_post would be fired first. Of course, this could only happen for new hooks, not old ones, because it would be a functionality change. But this too is tough to understand.

[sc0ttkclark]

I concede, if you don't see the use in it, then plugins can just do what they're doing now. There's no use in me trying to carry this ticket if you don't see the benefits for plugin developers beyond it being a change in how things can be done.