Opened 3 years ago
Last modified 9 months ago
#14994 new enhancement
Introduce a way to identify a hook in progress
| Reported by: |
|
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)
Change History (11)
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?
- Keywords needs-patch added
- Type changed from defect (bug) to enhancement
- Milestone changed from 3.1 to Future Release
Punting as no patch and entering beta.
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).
- 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.
comment:9
greenshady — 9 months ago
- Cc justin@… added

+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!