Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#38011 closed defect (bug) (wontfix)

WP_Hook class late assignment behavior change

Reported by: salcode's profile salcode Owned by: pento's profile pento
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: Plugins Keywords:
Focuses: Cc:


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.


The following code defines a shortcode [WP_Hook_priority_example]


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


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


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 @kraftbj
8 years ago

  • Milestone changed from Awaiting Review to 4.7
  • Owner set to pento
  • Status changed from new to assigned

Marking as 4.7 and assigning to @pento (committed r38571) to ensure it gets reviewed during this cycle. Original ticket #17817

Last edited 8 years ago by kraftbj (previous) (diff)

#2 @pento
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 @jdgrimes
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).

#4 @desrosj
5 years ago

#39225 was marked as a duplicate.

Note: See TracTickets for help on using tickets.