[buddypress-trac] [BuddyPress] #5170: bp_has_members() in widgets stomps $members_template global

[buddypress-trac]

#5170: bp_has_members() in widgets stomps $members_template global
-----------------------------+----------------------------------
 Reporter:  johnjamesjacoby  |      Owner:  johnjamesjacoby
     Type:  defect (bug)     |     Status:  new
 Priority:  high             |  Milestone:  Awaiting Review
Component:  Members          |    Version:  1.0
 Severity:  major            |   Keywords:  dev-feedback, commit
-----------------------------+----------------------------------
 `bp_has_members()` uses the `$members_template`, similar to the way
 `query_posts()` uses `$wp_query`. As such, subsequent calls to
 `bp_has_members()` leave the `$members_template` global in a polluted
 state that does not reflect the actual main query loop.

 This results in some craziness, again, similar to WordPress core. Template
 functions tied to the `$members_template` global
 (`bp_get_member_user_id()`, `bp_get_member_user_nicename()`, et all) may
 return unexpected results when more than one call to `bp_has_members()`
 occurs on the same page output, and also leaves no way to get back the
 main query loop data.

 To dance around this issue, WordPress uses the `$wp_the_query` variable,
 and uses `wp_reset_query()` to swap `$wp_query` back to it's natural
 state. My proposed patch does something similar, introducing a few static
 methods to the `BP_Core_Members_Template` class, and a
 `bp_reset_members_query()` helper function, which is patched to be used in
 our core widgets.

 Worth noting, all of our `_Template` classes and helper function sets
 exhibit this same problem. Groups, Activity, Blogs, Messages, Settings,
 and XProfile, will all need similar attention. As the members component is
 always on, and the widget is frequently used, I'm using it as my first
 example.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5170>
BuddyPress <http://buddypress.org/>
BuddyPress