Opened 3 years ago

Last modified 9 months ago

#14994 new enhancement

Introduce a way to identify a hook in progress

Reported by: nacin Owned by:
Priority: normal Milestone: Future Release
Component: Plugins Version:
Severity: normal Keywords: has-patch
Cc: justin@…

Description

We have did_action() and current_filter() but I've come across a use case for a hybrid of sorts, doing_action().

Problem is, did_action() returns true the moment the hook is fired. Thus if you need to wait until after the hook is done executing, you need to also check current_filter(). The problem arises when there was another hook called since thne, because current_filter() does not traverse back up the stack.

I considered adding an argument to either of the two other functions mentioned, but I think a new function makes the most sense. did_action() only works for actions. While current_filter() works for all hooks, it does one thing and that is to return the current hook. A new function makes the most sense here.

doing_action() might not be the best name because did_action() only works for actions, but this would work for filters as well. At that point, I might recommend doing_hook().

function doing_action( $action ) {
   global $wp_current_filter;
   return in_array( $action, $'wp_current_filter );
}

The use case was that a plugin was applying the_content on wp_head. That was messing with my footnotes plugin. So I needed to make sure I had completely processed wp_head first, but there was no way to do that. Now I would be able to check if ( did_action('wp_head') && ! doing_action('wp_head') ).

Attachments (2)

14994.diff (1.6 KB) - added by Nacin 2 years ago.
Adds current_action() as a wrapper for current_filter(). Adds doing_action() and doing_filter(). Ignores the call for a counterpart to did_action() for filters (should be a new ticket).
14994.2.diff (1.8 KB) - added by nacin 21 months ago.

Download all attachments as: .zip

Change History (11)

+1 on using doing_hook() as the generic name.

When I first read the title of this ticket, I was very skeptical that this function would have a practical use. After reading your description, though, I can think of at least 3 times I've had to work around the lack of this function to do the same or very similar things. Fantastic idea!

It would be nice if we had consistent names and behaviour:

  • current_hook()
  • doing_hook()
  • did_hook()

On did_hook(): Both do_action() and apply_filters() can be called multiple times, so there's no reason to artificially limit ourselves to did_action().

Isn't there an in_filter() function?

comment:4   jane3 years ago

  • Keywords needs-patch added
  • Type changed from defect (bug) to enhancement

comment:5   jane2 years ago

  • Milestone changed from 3.1 to Future Release

Punting as no patch and entering beta.

  • Keywords 3.2-early added

Nacin2 years ago

Adds current_action() as a wrapper for current_filter(). Adds doing_action() and doing_filter(). Ignores the call for a counterpart to did_action() for filters (should be a new ticket).

nacin21 months ago

  • Keywords has-patch added; needs-patch 3.2-early removed
  • Milestone changed from Future Release to 3.3

14994.2.diff also adds support for doing_action( $action = null ), where the default would mean it'd let you know whether any action is currently in the stack.

  • Milestone changed from 3.3 to Future Release

Too late for this, obviously. I had only brought it into 3.3 for #18548, which was punted.

  • Cc justin@… added
Note: See TracTickets for help on using tickets.