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

[WordPress Trac]

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

 * keywords:  has-patch needs-unit-tests => has-patch needs-testing


Comment:

 I think the correct answer to this and related tickets (#9968, #21169, and
 other duplicates) is to create a iterator that more accurately
 encapsulates the array iteration while tracking newly added/removed
 callbacks. The patch I'm submitting
 (https://gist.github.com/jbrinley/7024059, I'll attach in just a moment)
 should do so in a backwards-compatible way. I had three key objectives
 with this:

 1. Maintain backwards compatibility
 2. Support recursive calls to functions that trigger hooks
 3. Support manipulation of hook callbacks while the hook is running

 In this patch you'll find:

 * A new class, WP_Hook_Iterator, that can be used in place of a foreach
 loop to get each callback for an action/filter hook
 * Updates to apply_filters, apply_filters_ref_array, do_action,
 do_action_ref_array, and _wp_call_all_hook to use the new iterator
 * Unit tests asserting that you can call a hook recursively
 * Unit tests asserting that you can manipulate the callbacks of a hook
 while that hook is running

 This also passes all current unit tests, including the test added for
 #21169 (in tests/phpunit/tests/filters.php).

 Obviously, this is a key area in WordPress, so this patch deserves careful
 scrutiny. Are there any edge cases we're missing in the tests? How does
 this affect performance? Can we accomplish the same goals more
 efficiently?

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