this sounds familiar…i think i posted about this a while back somewhere(i’ll look), that the bp loops clashed with the search results page. it’s still the case too, I’ve had to not put any bp widgets on search results page sidebars.
@nuhammadrid
Yeah, I had found both those posts during my search for a solution, but neither of them even hints at one 
Brajesh Singh’s Global search results page does not create this conflict however. I think I’ll post over at BuddyDev to see if he has any bright ideas (he often does) and post back here if I get anywhere. Thanks!
@nuhammadrid
Brajesh just posted a possible solution at BuddyDev:
http://buddydev.com/forums/topic/wp-search-results-page-kills-bp-member-widgets#post-9892
I’m going to try it tomorrow ‘cuz I’m off to bed right now, zzz……
@nuhammadrid and anyone else experiencing this odd behavior:
Brajesh’s patch works just fine, but it requires a slight modification to bp-core-templatetags.php:
Replace this (line 131):
`if ( isset( $_REQUEST ) && !empty( $_REQUEST ) )
$search_terms = $_REQUEST;`
with this:
`if ( !is_search() && isset( $_REQUEST ) && !empty( $_REQUEST ) )
$search_terms = $_REQUEST;`
Note that this patch is for BP1.2.9
I have the same bug in BP 1.5.1. To fix it I had to go to bp-members-template.php line 309 to replace the code with what @pcwriter posted. Should a ticket be made?
I’m very sorry, may be I did something wrong, could yoou help me? In this file (bp-members-template.php) I have line 309:
// Pass a filter if ?s= is set.
if ( is_null( $search_terms ) ) {
if ( !empty( $_REQUEST ) )
$search_terms = $_REQUEST;
else
$search_terms = false;
}
Fnd when I tried to change I had an error, could you please tell me exactly what lines to change with what?
Thanks for this post! I was head-banging on this very issue and, up until the time I realized that the problem was only with the member widgets on search pages last night, I didn’t even know how to begin to troubleshoot it or what to search for.
As @leemour wrote in his reply, the code on line 309 of bp-members-template.php had to be modified at line 309. To get it to work, I replaced:
// Pass a filter if ?s= is set.
if ( is_null( $search_terms ) ) {
if ( !empty( $_REQUEST['s'] ) )
$search_terms = $_REQUEST['s'];
else
$search_terms = false;
}
With:
if ( !is_search() && isset( $_REQUEST ) && !empty( $_REQUEST ) )
$search_terms = $_REQUEST;
I’m not completely comfortable altering “core code” though. Is this a Buddypress bug? Shouldn’t there be a better solution than hacking core code?
I guess I spoke to soon. That change breaks the functionality of the dropdown filter. I guess I could take the dropdown out of the theme entirely but I thought it would be useful…
I went back to the original answer found here
http://buddydev.com/support/forums/topic/wp-search-results-page-kills-bp-member-widgets/
At this time, I do have the code working so that a wordpress search doesn’t wipe out buddypress member widgets and all the other functionality works on the members directory page too.
Here was my solution:
In bp-members-template.php, I remarked out lines 305-311 and replaced them with
if ( !is_search()&&isset( $_REQUEST['s'] ) && !empty( $_REQUEST['s'] ) )
$search_terms = $_REQUEST['s'];
So I’m back to the question/concern of 4 or so hours ago. I don’t feel that modifying core code is ever a good idea. Has anyone come up with a better way to solve this that makes it more durable when plugin updates are applied?
