Could be:
* Out of Memory.
* Overloaded server.
* DNS issues.
* Something else pretty broken.
Basically, will require some troubleshooting on your end.
This won’t work out of the box, and is by design. Jetpack hooks sharing options to the end of the ‘the_content’ filter. bbPress doesn’t use this filter, because blog content doesn’t have the same rules as forum content does; they work differently. To make it work, Jetpack’s sharing options would need to hook into `bbp_get_topic_content` and `bbp_get_reply_content` instead.
Someone could write a piggyback function to do this, but it may be more difficult than this first step once you’ve gotten this far. Replies don’t use the same “premalink” logic as topics, forums, pages, and posts do, since they are technically children of topics. There could be other quirks, too.
I’ve considered this, but without term meta there’s no way to do sticky topics in groups.
There’s no easy way to password protect the entire forum; you’ll probably have to find and use a third party plugin if one is available. While you *could* password protect a page, and use a shortcode, that doesn’t actually protect the exact permalinks themselves, so they’re not at all ‘private.’
My short answer is to turn off bbPress’s built in per-topic notifications, and build your own.
Since it’s a blanket on/off for each user, save a usermeta option whether or not they’ve opted in; save this when they create their account. There are plenty of actions and filters in the default profile templates that will allow you to intercept the input/output process, so adding an additional field is not too difficult, though not exactly easy either (lots of touch points.)
In all, this could be built as a completely self-contained plugin, and released to the community. I’d be surprised if someone isn’t already trying to build the same thing.
Multiple forums per BuddyPress Group is started in bbPress, but likely won’t be finished for several months. There are a few technical challenges regarding performance that don’t make it entirely feasible. If it’s something you need, you’ll want to build it, and if you’re able, contribute back to the bbPress project.
On the whole, I agree that it would be nice to have in core.
It’s nice to see a few CSS tweaks providing deep integration into an existing WordPress site.
Thanks for sharing!
This is a bit of a brute force hack, and only fixes the problem because something else is initializing the current user before $wp->init would naturally call it.
Also, on multisite installations, this will cause other more annoying issues that are even more difficult to track down. 🙂
There must be some other plugin that’s doing something wrong in your installation(s).
I don’t know if what I wrote is anything like a best practice, but it worked for me
Anything is better than nothing. We can always iterate on anything you create later. Thanks for putting that up!
If it’s not, why not?
The honest truth is that once most people learn what they need, they never go into the bbPress codex and make a page to share their knowledge.
Fixed! This changeset specifically is likely the one causing you problems.
Happy you figured it out. s2Member and other capability manipulating plugins have a tendency to conflict with bbPress and the way it handles roles and capabilities. I think some fixes went into s2Member to improve this, but it’s possible there’s still more issues to work out.
Does the 2.3 beta fix this for you?
What plugins besides BuddyPress are you running? Is one of them conflicting?
As a logged out user (anonymous/guest/etc…) I see 4 posts there.
You’re correct, `is_bbpress()` should be what you’re looking for.
Confirmed on my local; it’s only when BuddyPress is active, and I know what’s up. @rossagent, go ahead and open a ticket, and I’ll get this fixed up asap.
To confirm:
- BuddyPress must be active
- Activity streams must be active
- User must not be an admin/super admin
Seems odd that being a participant would trigger it. @rossagrant, can you try with 2.3 beta 1, and let me know if that fixes anything? We’ve been on trunk here for months with no issues, and we’ve got over 5 million users.
Some of this is going to change again in bbPress 2.3, so you may want to check out the beta.
Pretty neat. Thanks y’all for making and sharing these.
The code above just removes the redirect to field completely, which can’t possibly work correctly.
The stack here is:
- `bbp_get_reply_url()`
- `bbp_get_topic_permalink()`
- `get_permalink( $topic_id )`
The only place this could occur is if `bbp_get_reply_url()` is passed both a `$reply_id`, and a `$redirect_to`, and the `$redirect_to` is the forum permalink, which shouldn’t happen. `bbp_get_redirect_to()` is what gets it in trunk, which is a wrapper for `$_REQUEST[‘redirect_to’]`.
Which is to say, if you have a `$_REQUEST[‘redirect_to’]` field being submitted with the forum permalink, that’s where it will go. Otherwise, I don’t see any other way this could happen in bbPress core.
Hi @looimaster. Net yet, though because it uses a custom contextual sidebar, it does take some dedicated template files and a child theme.
We’re going to open-source bbpress.org in 2013, at which time the theme will be available for people to hack around with.
Sounds pretty strange. Any other plugins active that might be interfering with bbPress’s queries?
