The news is in trac. There’s one ticket left in 1.1 and then it gets released. No sense in putting out a 1.0.4 to fix one bug that 1.1 will fix. Right now we’re in the middle of a WordPress, BuddyPress, bbPress trifecta release, so there’s three times as much testing to do to make sure nothing breaks.
If you can’t wait for a public release, download the trunk and do some testing. 
The news is in trac. There’s one ticket left in 1.1 and then it gets released. No sense in putting out a 1.0.4 to fix one bug that 1.1 will fix. Right now we’re in the middle of a WordPress, BuddyPress, bbPress trifecta release, so there’s three times as much testing to do to make sure nothing breaks.
If you can’t wait for a public release, download the trunk and do some testing.
This comes from using PHP 5.3 and having E_DEPRECATED turned on. WordPress and BuddyPress are equally bad about those notices, and eventually I’m sure some effort will be put in to prevent them. Right now the number of users on 5.3 is still one of the smaller audiences, so the urgency isn’t there yet.
Note: Those notices and that particular method of coding works fine in any other version of PHP. It will also still execute in 5.3, but will trigger errors if your server is configured to do so.
Such is life on the edge. 
I’m aware of the login issue and will fix in the next day or two.
Thanks for keeping up with the development though. It’s great to have eyes on it.
It’s a little weird to see bbPress installed inside of a theme, so there could be almost an unlimited number of things wrong.
The error looks like there’s a rogue semi colon in your password-reset.php file.
It’s a little weird to see bbPress installed inside of a theme, so there could be almost an unlimited number of things wrong.
The error looks like there’s a rogue semi colon in your password-reset.php file.
@rootside – Placeholders for the login and registration pages are in the current bbp-twentyten theme, but they don’t work yet. The goal is for the bbPress plugin to include these pages as WordPress page templates and short-codes, to allow for maximum flexibility in configuring your site.
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.
@_ck_ – Will do. I have a VM I can test on when I get back from Tybee next week, and will see about getting anyone on Windows to play with it. I know when I started, I was using IIS on Windows 7 and it was working fine, but much as changed since then.
Along the lines of what CK is talking about, the issue is one of DB structure. WordPress only gives us post_parent to help with post relationships, which leaves us with postmeta for everything else. That’s forces us to rely on the object cache and to try to predictively preload data that would otherwise be queried selectively and only as needed. A fully tricked out install with widgets and sidebar can fore the query count into the hundreds on pages like the user profile, with the object cache still missing quite a few.
Compared to bbPress 0.9, the current incarnation of the plugin will be abysmal query wise. Caching helps tons with this on the reads end of things. I’ve gotten it down to 1 cache miss on most pages, with auto cache refresh on writes. But this is one area where more eyes will be helpful. Like CK said, there probably isn’t a whole lot that can be optimized but I’d love to see it.
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.
It’s active, but it’s a lot harder to calculate spam on a registered and activated user account.
It’s active, but it’s a lot harder to calculate spam on a registered and activated user account.
Regarding the migration script, it’s a super high priority item, but the plugin core needs to settle before it makes sense to start building that bridge. By the time the plugin officially launches, there will be a migration script included.
@gswaim – I can assure you bbPress as a WordPress plugin is no ground-hog day (although that is one of my favorite Bill Murray movies.) There’s more activity in the bbPress trac over the past 2 months than there has been in the previous 18.
Evidenced by: https://trac.bbpress.org/log/
Matt and I have shared a similar interest in having forum integration inside WordPress since 2008 when I first started using WordPress and bbPress regularly. The bbPress stand-alone can be deeply integrated with great success into WordPress. bbPress.org is a great example of how they can play nice together, as are WordPress.org and WordPress.com. All of the support forums use bbPress with shared user tables and dedicated themes to make them look the part.
But, I’m with you in that it just isn’t as turn-key simple as it could and should be.
Regarding Tadlock’s plugin, he volunteered an early iteration of his code to me which helped confirm I was on the right track and give some ideas on how to do a few things I hadn’t finished yet. So his forums haven’t fizzled, they’ve been merged into bbPress so he doesn’t need to bare the burden of supporting another large library of code, and instead he can contribute back to it when he has time or needs something specific.
Regarding my job with Automattic, progress slowed because every new employee does a 3 week training session with the Happiness Engineer team. It just so happened that my 3 weeks ended as the holiday season began. Not due to lack of importance, just not-so-good timing for writing code.
@tieptoep – The alpha will probably not have a migration script from stand-alone to plugin, but we’ll more than likely put it in the WP.org plugin extend to engage a larger audience.
No. The only version that is publicly available for download (using the red tab in the upper right hand corner) is a standalone version of bbPress that does not require WordPress to work.
The version that is currently in development is a plugin for WordPress, which will require WordPress first.
No. The only version that is publicly available for download (using the red tab in the upper right hand corner) is a standalone version of bbPress that does not require WordPress to work.
The version that is currently in development is a plugin for WordPress, which will require WordPress first.
@PaulMike – Not long now thanks to the efforts of GautamGupta. We’re going to be using it on a few community sites soon, so probably expect some kind of alpha in the next few weeks. There will be an official blog post to announce it when it’s time.
My rule regarding trac vs forums, is that the forums are traditionally for support and confirmation of an issue occuring, and the trac is for when bugs appear that can be duplicated and/or you have a suggested code change. You can even drop enhancement requests in the trac if you have a really neat idea, even better if you have a patch to match it.
Core developers live and breathe by the trac. If it isn’t in there, it doesn’t exist. It’s our diary of development, and without it our lives would be much more difficult. The trac is less social, and more developer speak. The forums tend to be a little more relaxed.
With WordPress 3.1 almost in its third release candidate, we can expect it to ship really, really soon. That said, it makes sense to drop 3.0 support and focus on 3.1. I’ve made sure we’ve stayed compatible with 3.0 this entire time, but it’s time to focus on the version of WP that the bbPress plugin will see the most use on.
Thanks to everyone that’s been testing on 3.0 installations. If you *really* want this to be 3.0 compatible, definitely open trac tickets and contribute patches to keep that support alive.
For bugs where you’re comfortable creatIng a trac ticket, save yourself the work and don’t worry about cross-posting it here. We get email notifications on all trac activity, so we see them there right away.
Yay! Thanks for the kind words.
Gautam has definitely been doing an awesome job, so huge props are deserved.
Yay! Thanks for the kind words.
Gautam has definitely been doing an awesome job, so huge props are deserved.
