@andrejcarter – It isn’t obvious, but as it stands right now you need to make a WordPress page with the slug ‘login’ and assign the Login Page Template to it. Janky, but still being worked on.
Right now there’s an issue with trashing/deleting replies and topics in the plugin. Basically the topic/reply/voice counts don’t have correct logic, which can result in the counts going all wacky. This wouldn’t be so bad if the recounts in the admin area worked, which they don’t because they use essentially the same logic. This is a known issue and is next on my list of things to do on this.
@chuckmac @LPH2005 – Those meta keys are relatively new, and were an addition that wasn’t backwards compatible with previous development versions. Check this topic for the exact date of the change, but exactly what you found will cause exactly what you describe.
@Rob Bunch – With any prerelease software, you need to understand the risks involved. Just like @chuckmac and @LPH2005 experienced, it’s still possible for there to be architectural changes in the software that aren’t backwards compatible. There are countless changes between the stand alone and plugin versions since the data schema is so different, so certain things needed to be worked around late in the development cycle.
That said, it’s available for download so that you may test it however you are comfortable doing so. Just be aware if something crops up on your live site, there is a limited pool of resources to help you.
Moderated.
@jwindhall – You basically want shared user tables and nothing else, so follow the typical integration methods as if BuddyPress wasn’t in the picture.
Moderated.
@jwindhall – You basically want shared user tables and nothing else, so follow the typical integration methods as if BuddyPress wasn’t in the picture.
Was in Phoenix at WordCamp, and am working on the BuddyPress side of things as well. Updates will come this week. 
@Ramiuz – That’s not true at all.
The problem is an ongoing one that even Matt has blogged about in recent past. Part of the reason they’re able to pass the human test it because they might be humans registering real accounts and making real posts. WordPress.org, bbPress.org, and BuddyPress.org all suffer from a similar problem. I’m about sick of it though.
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.
