#38011 closed defect (bug) (wontfix)
WP_Hook class late assignment behavior change
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.7 |
Component: | Plugins | Keywords: | |
Focuses: | Cc: |
Description
The recent addition of the WP_Hook
class has introduced a change in behavior when a function is added to the currently executing action with an earlier priority than that which is currently being executed.
Example
The following code defines a shortcode [WP_Hook_priority_example]
<?php add_shortcode( 'WP_Hook_priority_example', 'wp_hook_priority_example' ); function wp_hook_priority_example() { add_action( 'wp_hook_priority_example', 'add_other_functions' ); do_action( 'wp_hook_priority_example' ); } // This function is called with a priority of 10 on the hook `wp_hook_priority_example`. function add_other_functions() { add_action( 'wp_hook_priority_example', 'print20', 20 ); // Assign print5() to priority 5 (even though priority 5 has passed already). add_action( 'wp_hook_priority_example', 'print5', 5 ); } function print5() { echo '<p>5</p>'; } function print20() { echo '<p>20</p>'; }
Prior to the Introduction of the WP_Hook Class
This code will output
20 5
For clarification, I don't think this is a logical behavior but it is the current behavior in WordPress 4.6 and earlier.
Even though we are executing code assigned to wp_hook_priority_example
with priority 10
, when we assign a function to the same hook using a priority that has passed (e.g. 5
) the function is still executed.
After the Introduction of the WP_Hook Class
This same shortcode executed after the introduction of the WP_Hook class displays only
20
I believe this is the more logical behavior, however in terms of backwards compatibility I believe it is worth considering making this behavior consistent with the previous versions of WordPress.
Change History (4)
#1
@
8 years ago
- Milestone changed from Awaiting Review to 4.7
- Owner set to pento
- Status changed from new to assigned
#2
@
8 years ago
- Milestone 4.7 deleted
- Resolution set to wontfix
- Status changed from assigned to closed
Thank you for the clear and in-depth report, @salcode!
This change was intentional, to match the expected behaviour - adding a function to the currently running action or filter, with a priority that has already been done, should not be run.
I'd consider reverting back to previous behaviour if there are many reports of broken plugins caused by this, but let's leave it as is for now, and re-evaluate later.
#3
@
8 years ago
For the record, I just stumbled upon this change in behavior when the PHPUnit tests for a plugin started failing against WordPress 4.7, but worked fine on older versions. The issue was just related to my tests bootstrap, not the plugin's source itself, so it didn't actually break the plugin in normal operation. Actually, I guess it's a good thing that this happened, because it brought to my attention that during the tests things weren't running in the order that they were expected to be run. The only downside is that it took a while to figure out what was going on. It would have been nice if there was a warning saying that a hook was being hooked up too late. But I guess sometimes that could be intentional, so maybe adding such a warning isn't feasible (unless it can be selectively disabled).
Marking as 4.7 and assigning to @pento (committed r38571) to ensure it gets reviewed during this cycle. Original ticket #17817