I’d love to use a standalone bbPress, but that option was long since abandoned 
I stand by the reasoning behind the plugin route though, I still think it’ll make our lives a whole lot easier.
Thanks for the pointers John. It’s also comforting to know that BuddyPress forums will be seeing some speed improvements in 1.3.
I have been testing the bbPress Plugin on Windows, well I was up until about a month ago when I hit a few PC problems, but like JJJ said … much has changed since then! 
Each topic already carries the name of the person that started it, so this is very easy to do without a plugin.
Simply edit your front-page.php and forums.php templates and put
<?php echo $topic->topic_poster_name; ?>
where you’d like it.
also see this tag
https://bbpress.org/forums/tags/topic-author
Each topic already carries the name of the person that started it, so this is very easy to do without a plugin.
Simply edit your front-page.php and forums.php templates and put
<?php echo $topic->topic_poster_name; ?>
where you’d like it.
also see this tag
https://bbpress.org/forums/tags/topic-author
Forum performance inside of BuddyPress is improved in 1.2.7 and will be further improved in 1.3 (which still includes the bbPress stand-alone version.)
Having BuddyPress load all of its code and process everything that it does is the bottleneck in your circumstance. You’d be better off loading bbPress standalone properly themed, then the bbPress plugin, and lastly inside of BuddyPress groups (regardless of standalone/plugin.)
But, I think it’s a horse a piece.
The more you need to load is the slower it’s going to be, and the more important caching becomes. The bbPress plugin will respond to W3TC much better than bbPress standalone and BuddyPress will, since it uses the existing WordPress object cache.
Forum performance inside of BuddyPress is improved in 1.2.7 and will be further improved in 1.3 (which still includes the bbPress stand-alone version.)
Having BuddyPress load all of its code and process everything that it does is the bottleneck in your circumstance. You’d be better off loading bbPress standalone properly themed, then the bbPress plugin, and lastly inside of BuddyPress groups (regardless of standalone/plugin.)
But, I think it’s a horse a piece.
The more you need to load is the slower it’s going to be, and the more important caching becomes. The bbPress plugin will respond to W3TC much better than bbPress standalone and BuddyPress will, since it uses the existing WordPress object cache.
mobious74: Try going to Settings -> Permalinks and press save changes.
There is no need to minify PHP comments, they are dropped by opcode caches.
However reducing query count is not going to be easy.
I’ll do a 3rd party analysis on the queries (and file count) next week or so, I suspect there is going to be little that can be done to reduce the load because of how this is now being done. It is likely any bbPress plugin install is going to have to be heavily cached on any reasonably active site, just like WordPress now absolutely requires a complicated cache like W3 Total Cache.
But what people don’t realize is you cannot cache an active forum like a blog, they work very differently. Blogs are write-once, read many times and then the comments can be isolated with periodic updates. But on a forum it’s write-many-times and constantly changing. So there will always be many cache misses and the mysql engine will get a huge workout.
Try using WP3 these days on an active site where there are cache misses, the server will fall apart. You cannot rely on the miracle of caching and ultra-fast hardware to get around fundamental design problems.
The size of the codebase is largely due to the amount of phpDoc and inline documentation. I expected there to be a lot of eyes on this code from both bbPress and WordPress audiences, so almost everything is described in detail.
And I certainly appreciate it, but is there an easy way to minify it then?
lz,thank you very much!!!
lz,thank you very much!!!
The query count is high and needs and audit. We’re using internal WP functions for 99% of queries, so we thoroughly reap the benefit of the WP object cache.
The size of the codebase is largely due to the amount of phpDoc and inline documentation. I expected there to be a lot of eyes on this code from both bbPress and WordPress audiences, so almost everything is described in detail.
@Gautam 15? Simply brilliant! If only I could breath code like you do.
Unfortunately, I just break, test and report things and that’s all.
is there any RC’s or some other code snippets? it’s really necessary feature.
@Chip Bennett
Thank you! One major thing that has changed is the prefix of the functions. Instead of bb_, it is bbp_. The functions names are easy to guess like bbp_forum_title, bbp_topic_title, bbp_topic_reply_count etc. We don’t have post – that has been split into topic and reply. Though post is used to refer to topic and reply both in some functions like bbp_fix_post_author(), but that’s a couple of functions only. Like the standalone, WP, BP, etc there are 2 versions of the same function – one that echoes and one that returns so you’d have bbp_topic_content, bbp_get_topic_content etc.
Right, there is a great need for the documentation. We’ve tried our best to have upto date inline documentation (phpDocs) in place.
@Chip Bennett
Thank you! One major thing that has changed is the prefix of the functions. Instead of bb_, it is bbp_. The functions names are easy to guess like bbp_forum_title, bbp_topic_title, bbp_topic_reply_count etc. We don’t have post – that has been split into topic and reply. Though post is used to refer to topic and reply both in some functions like bbp_fix_post_author(), but that’s a couple of functions only. Like the standalone, WP, BP, etc there are 2 versions of the same function – one that echoes and one that returns so you’d have bbp_topic_content, bbp_get_topic_content etc.
Right, there is a great need for the documentation. We’ve tried our best to have upto date inline documentation (phpDocs) in place.
And these popped up in mine – http://gaut.am/2011-a-new-kind-of-forum-software-is-born/comment-page-1/#comment-2667
[2791] [2792]
Edit: Oh.. I read the rest of your comment later..
Well, yes the query count has gone up, there would have to be an optimization round.
Thanks for the age comment, though!
these popped up in my alerts:
bbPress plugin project saw serious progress during Google Code-in
2011: A New Kind of Forum Software is Born
It’s a shame that topic split/merge had to wait until the plugin version to be done in the API and not in the previous few years for the standalone.
Neither of the writeups mention the impact of database queries and the size of the codebase so I will have to explore that next week. I suspect they are high. It’s easy to pile on features but hard to make them efficient.
ps. Gautam is only 15 ?! Wow, amazing work for such a young age.
As a sidenote to the original topic! …
Rich Pedley: @Mark – test again
Thanks for that Rich, you can see I’m having a little nose around, and thanks for the offer Gautam — Even started talking to myself, and trying out other stuff too! 
As a sidenote to the original topic! …
Rich Pedley: @Mark – test again
Thanks for that Rich, you can see I’m having a little nose around, and thanks for the offer Gautam — Even started talking to myself, and trying out other stuff too!
I can’t seem to get users to login to both at all. I have tried several solutions on here and no matter what users will not login to both wordpress and bbpress.
I set all the cookie fields, and user database fields. Users are getting shared between the both just have to login twice.
I added the following to code to both wp-config and bb-config:
define( ‘COOKIE_DOMAIN’, ‘.domainname.com’ );
define( ‘COOKIEPATH’, ‘/’ );
I am not using wordpress MU, so none of those options are checked. I am running bbpress 1.02 and wordpress 3.0.4
