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?
I just upgraded a BuddyPress site to v1.8.1 and did a cursory check to see if this search issue had been resolved yet. It has not, which sort of mystifies me because the problem is more than two years old and requires a modification to BuddyPress core code.
Here is the segment of code that I’ve changed (again) in the bp-members-template.php script found in the plugin’s “core” folder:
// Pass a filter if ?s= is set.
// ref link: https://buddypress.org/support/topic/wp-search-results-page-kills-bp-member-widgets/
// ref link: http://buddydev.com/support/forums/topic/wp-search-results-page-kills-bp-member-widgets/
// Original code on lines 313-318 remarked out in favor of Modified code on lines 320-322
//if ( is_null( $search_terms ) ) {
// if ( !empty( $_REQUEST['s'] ) )
// $search_terms = $_REQUEST['s'];
// else
// $search_terms = false;
//}
/******* Modified search code *******/
if ( !is_search()&&isset( $_REQUEST['s'] ) && !empty( $_REQUEST['s'] ) )
$search_terms = $_REQUEST['s'];
/******* End Modified Search Code *******/
Has anyone on the core development team considered making this into a “hook” that we can remove and rewrite for our child themes?
Clarification:
This template file is found in the base BuddyPress plugin folder under the bp-members folder.
Thanks for sharing your fix.
To suggest a change to core code, please use
https://buddypress.trac.wordpress.org/
to submit a ticket re a bug or enhancement.
The core devs will definitely see it there.
I keep thinking about this issue, mostly because it “bugs me” to change core files in a major plugin like BuddyPress. I opened a ticket at the recommended location and I can find no record of it so it has most likely been closed.
My question for the group here is this. Would the above modification applied to bp-custom.php overried the core template? If so, can someone tell me what to unhook and re-hook to make that work?
Thanks, in advance, for any replies that are helpful.
