@jivany (“I don’t understand your BP forum complaints. You don’t use forums because you have basically replicated the forum concept in blog posts/comments”)
Exactly! My point is that integrating an external forum like bbPress into Buddypress is unnecessary and only creates a lot of confusion, undermines the structure. Less is more. KISS.
I would like Buddypress to consolidate on the smallest number of parts, leverage what’s already in WordPress, instead of adding database tables and external scripts that partly overlap/clash with other parts.
But bbPress seems to be taking over Buddypress. Wrong direction imho. 
Mike Pratt said 1 day ago:
“ @peterverkooijen @hnla I take the other side of your “little diff b/t blogs and forums” opinion. To me, a blog post is a significantly more “deliberate” piece of content … For ex, we have a group called the “12th Man Training Table” which centers on athlete nutrition. Folks want to post recipes for training means. Clearly, forum topics are the wrong vehicle. On the other hand, there are raging debates in that group that definitely belong in the forum construct..not a blog post with comments … So Peter, please keep in mind that what you would do to BP would build a BP that works for Peter, but it’s not necessarily the only use case around, that’s all.”
Mike Pratt, you miss the point. I’m talking about how the script and database is structured, not what you as a user should do with it. Functionally a blog post and a forum topic are the same thing; a piece of content that others can comment on. Similarly there only needs to be one way to store (threaded) comments. There is no need to duplicate that in forum thread, wires, etc. There is no need to have variations of posts and comments in different places in the database.
I’m talking about taking redundancies out, boiling down the architecture to the lowest number of necessary parts, less is more, keep it simple stupid. That does not mean you as a user will have less options. WP blog posts already provides many ways to make very different types of posts. In my P2-based custom theme I have started making a clear distinction between ‘status updates’ and ‘blog posts’ using categories. Apparently WP 3.0 will have more sophisticated hooks to do different things with different types of content.
Same for comments. There are already lots of different things you can do with comments, from IntenseDebate and other plugins to built-in threaded options, inline Ajax commenting and styling possibilities via your theme. Buddypress should leverage basic WordPress building blocks as much as possible instead of adding new database tables and third scripts like BBpress. Ultimately a lot of this is for the theme developers to develop. They could develop out-of-the-box themes for different use cases; schools, companies, sport clubs, etc. BP should focus on a solid core and flexible API.
Also, also, thanks for the new standard most-recently-bumped view of forum threads, @apeatling.
Enhancements I’d suggest would be
1) a link to the last post in the thread (easy to do, I know)
2) pagination in the most-recently-bumped view to see older bumped threads (or maybe a dropdown to select number of threads shown, but that would break the standard navigation paradigm being used, so probably suboptimal). Things move fast, and even visiting several times a day, stuff I want to track gets bumped off the front page, and is then very hard indeed to find, because I (and I assume other people) find it hard to remember in many cases which Group a thread was posted to (and threads are often posted in the ‘wrong’ Group, which makes it even harder).
@djpaul I spoke too soon, I think.
If I’m right, I’ve finally figured out how and when things were going wrong.
If I use bp_has_forum_topics(‘per_page=30′) in groups/forum/single/topic.php in my child theme, on pages that have less than 30 posts (or possibly 15, the default in bp-forums-templatetags.php), I get duplicated thread posts — in other words all the posts in a thread show up, then all of them show up again.
If I hack the bp-forums-templatetags.php file as described above, though, it seems to work fine. No duplicates, no matter the number of posts in a thread.
Weird. Possibly a bug?
I’ve displayed members in home page.For that, passing the parameter did not work . It only works for the member directory listing.
Correct me if I’m wrong.
I apologize for not coming back sooner to say this is solved. Been having lots of computer issues. The reason the other code didn’t work was we were reading from the wrong table. Another table had the info we needed so I swapped it out and here’s what I’m using now. Hopefully this will come in handy for a lot of people.
This goes in the head
<!-- drop down search -->
<SCRIPT LANGUAGE="JavaScript">
function formHandler(form){
var URL = document.form.site.options[document.form.site.selectedIndex].value;
window.location.href = URL;
}
</SCRIPT>
<!-- end drop down search -->
And this goes in the body
<!-- drop down search -->
<form name="form">
<select name="site" size=1>
<option value="">Blah Blah</option>
<?php
$field_id = 2; // this should be the id of the
// field you want, see your wp_bp_xprofile_fields
// database table to find it
global $wpdb;
$sql = "SELECT name FROM {$wpdb->base_prefix}bp_xprofile_fields WHERE parent_id = {$field_id} ORDER BY id DESC";
$result = $wpdb->get_col($wpdb->prepare($sql));
foreach($result as $row){
if(strlen($row) > 0){
$values[$row]++;
}
}
foreach($values as $key => $value){
echo "<option value=\"members/?s=$key\">$key</option>";
}
?>
</select>
<input type=button value="Go!" onClick="javascript:formHandler(this)">
</form>
<!-- end drop down search -->
Don’t forget to change the number of the field. Thanks for all of your help 
