[wp-trac] [WordPress Trac] #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call

WordPress Trac noreply at wordpress.org
Tue Apr 16 17:01:50 UTC 2013


#17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
----------------------------------------+-----------------------
 Reporter:  kernfel                     |       Owner:
     Type:  defect (bug)                |      Status:  reopened
 Priority:  normal                      |   Milestone:  3.6
Component:  Plugins                     |     Version:  3.4.1
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |
----------------------------------------+-----------------------

Comment (by cheeserolls):

 Well, again, some good points. A backwards-incompatible change which
 breaks plugins isn't very nice.  But I find the idea of waiting a few
 versions to fix something which must surely be considered a bug is
 unappealing too.

 I've just had a really good look at the plugin.php code, and have come up
 with the following alternative approach:

 Still use current() and next() to loop through the actions/filters, thus
 keeping the efficiency of not copying the array, and the ability to add
 actions to a hook from inside the execution of that same hook.  But, give
 the do_acttion() / apply_filter() functions responsibility for keeping
 track of nestings.

 There is already a global var called $wp_current_filter which maintains a
 stack of currently executing filters.  At the start of execution, the name
 of the filter is pushed onto it, and then popped off at the end.  This
 variable is only used by the current_filter() function, which just returns
 the name of the currently executing filter.

 That stack could also be used to store the POSITION of the array pointer
 at the currently executing filter.  Then, if the same filter is nested,
 when we return to the outer filter, the saved position could be used to
 continue executing the other filters from the point that it left off.

 I think this approach would not change any previous behaviour, and
 therefore not break existing plugins, but it would stop an inner action
 from breaking the outer one.  And so would probably fix a lot of plugins
 which didn't even know they were broken.

 Any thoughts?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17817#comment:21>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list