WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#25241 closed enhancement (wontfix)

Allow apply_filters and do_action to accept a $tag array

Reported by: sc0ttkclark Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Plugins Keywords:
Focuses: Cc:

Description

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.

Change History (10)

#1 @sc0ttkclark
7 years ago

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

#2 @sc0ttkclark
7 years ago

  • Cc lol@… added
  • Summary changed from Add $tag array handling for running multiple filters/actions at once w/ same value and arguments to Allow filters and actions to accept a $tag array

#4 @nacin
7 years ago

I think this is a duplicate of #14280.

#5 @sc0ttkclark
7 years ago

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

#6 @sc0ttkclark
7 years ago

  • Summary changed from Allow filters and actions to accept a $tag array to Allow apply_filters and do_action to accept a $tag array

#7 @nacin
7 years ago

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.

#8 @sc0ttkclark
7 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

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.

#9 @sc0ttkclark
7 years ago

  • Keywords dev-feedback needs-patch removed

#10 @SergeyBiryukov
7 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.