[wp-trac] [WordPress Trac] #36097: wp_filter reset after sub-queries

[WordPress Trac]

#36097: wp_filter reset after sub-queries
-------------------------------+------------------------
 Reporter:  cartpauj           |       Owner:
     Type:  defect (bug)       |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Query              |     Version:  4.4.2
 Severity:  normal             |  Resolution:  duplicate
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------
Changes (by boonebgorges):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Replying to [comment:5 cartpauj]:
 > @boonebgorges - If you set the priority of the_content filter to 12 or
 greater, you'll see this happen. My fault for forgetting that part in the
 initial post.

 Ah, thanks. With this, I'm able to reproduce.

 To spell it out a bit more: `apply_filters( 'the_content' )`, when run on
 the post in the main loop, triggers `do_shortcode()` at priority 11,
 inside the `foreach` loop here
 https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-
 includes/plugin.php?marks=235#L226. Thus, at this point, the array pointer
 of `$wp_filter['the_content']` is at 11. When `apply_filters(
 'the_content' )` is run inside the shortcode handler, the pointer is
 `reset`, and runs all the way through the end of the
 `$wp_filter['the_content']` array - at least until 12, where
 `append_to_content()` has been hooked. When `do_shortcodes()` is finished,
 and we return to the `foreach` loop, the pointer is now at the end of
 `$wp_filter['the_content']`. Thus, `next( $wp_filter[ $tag ] ) === false`,
 and we never end up processing anything at priority 12+.

 The obvious way around this is to make a separate copy of `$wp_filter[
 $tag ]` each time `apply_filters( $tag )` is run, so that array pointers
 are not shared in cases like this. But I think there are performance
 concerns to this.

 This is all getting a bit above my pay grade, so on a whim, I checked
 against #17817. The `WP_Hook` implementation fixes the currently reported
 issue. Because of this, and because I think that what's being reported
 here is a close cousin of what's being reported in #17817, I'm going to
 mark this one as a duplicate.

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