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

WordPress Trac noreply at wordpress.org
Sat Mar 22 15:56:26 UTC 2014


#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:  trunk
 Keywords:  has-patch needs-testing dev-         |  Resolution:
  feedback has-unit-tests                        |     Focuses:
-------------------------------------------------+-------------------------

Comment (by Denis-de-Bernardy):

 Replying to [comment:53 jbrinley]:
 > Replying to [comment:52 Denis-de-Bernardy]:
 > > Likely -1 here. Won't 17814.4 break plugins that look into the
 $wp_filter global in an effort to remove observers added by plugins that
 are anonymous? Plugins and such that change $wp_filter directly, such as
 what occurs in some of the unit tests?
 >
 > @Denis-de-Bernardy, would your concerns be assuaged if `WP_Hook`
 implemented `ArrayAccess`, `IteratorAggregate`, and `Countable` (basically
 extending `ArrayObject`)?

 Yeah. Look at doctrine/common, or is that collection... At any rate,
 there's a collection class in there that implements all three, complete
 with unit tests.


 > In my opinion, it's unnecessary bloat for the benefit of a few edge
 cases

 It's not a few edge cases. See toscho's reply: he links to one of the
 highest voted questions in WP Answers.

 Nor is it plugins taking advantage of undocumented internals: people make
 do with what they have -- including, for that matter, WP itself when it
 messes around with wp_filters in its own test suite.

 My own use, or the WP unit test suite itself, is to pre-load wp filters
 prior to loading WP. So it should ideally convert any pre-existing
 wp_filter global as appropriate at the top of the file if any are present.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/17817#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list