[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
Component:  Plugins                              |  Release
 Severity:  normal                               |     Version:  3.4.1
 Keywords:  has-patch needs-testing dev-         |  Resolution:
  feedback                                       |
-------------------------------------------------+-------------------------

Comment (by Denis-de-Bernardy):

 Replying to [comment:40 jbrinley]:
 > Just like all the other solutions that make a copy of the array,
 http://core.trac.wordpress.org/attachment/ticket/26239/26239.patch is not
 backwards compatible. You can't modify callbacks for a filter while it is
 running.

 Expanding on my earlier point in this regard, maintaining this backward
 compatible behavior is of dubious merit at the very best. Particularly if
 maintaining it involves a plugin API that is an order of magnitude slower.

 Look… Whoever writes the following code expecting 'bar' to come out
 deserves to see their code blow up in their face:

 {{{
 add_action('foo', function() {
   add_action('foo', function() {
     echo 'bar';
   }
 });
 do_action('foo');
 }}}

 Yes, it currently works in WP. But it shouldn't: you don't catch a plane
 that is already departed.

 On the contrary, the following *should* output 'bar' and doesn't work:

 {{{
 function foo() {
   remove_action('foo', 'foo');
 }
 add_action('foo', 'foo');

 function bar() {
   echo('bar');
 }
 add_action('foo', 'bar');

 do_action('foo');
 }}}

 Our current approach is to crash the entire plane if anyone wants to get
 off.

 Trying the same examples in a framework with a sane observer pattern
 implementation will yield the expected results. Whereas here we are
 haggling over keeping some manifestly broken behavior around for the sake
 of maintaining backwards compatibility that nobody cares about.

 Can we please stop this madness?

 /rant

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