It will be fine, but you’ll likely want to avoid having private or hidden forums. bbPress performs a postmeta query to exclude topics and replies from private and hidden forums, which will be a pretty bad bottleneck.
Hopefully in bbPress 2.4 or 2.5, I’d like to move the last-active-time meta queries to use post_modified in the posts table. That will remove some of our dependency on JOINing tables, and speed things up for you pretty significantly (at the cost of bastardizing the core post schema and its intentions a bit.)
If you have other specific questions as you go, happy to help and be a resource.
We turned off the visual editor in 2.3.1 because of issues users were having losing formatting when switching between visual and HTML modes.
We put up a snippet with the 2.3.1 release to re-enable it.
Enable Visual Editor
Try hitting Tools > Forums > Repair Forums
…and run the “Remap existing users to default forum roles” fixer.
Basically, blog admins aren’t always forum admins, they need to also be Key Masters. Sounds like you lost (or never had) the Key Master role.
It may be worth approaching this differently in a future version, and trusting administrators implicitly.
There is no changelog. What’s changed?
There is a changelog, you just need to read the blog post this topic is connected to. 🙂
Or, even better, keep an eye on Trac if you’re concerned about the exact changes.
You are correct. I’m also improving this in 2.3.1, which should fix any issues you’ve had with it currently.
Enable the Fancy Editor in your forum settings.
Unfortunately, this won’t scale very well. Notifications and Favorites are stored in a serialized array is usermeta, and keeping track of every topic will eventually slow things down significantly.
Instead, I’d filter `bbp_is_user_subscribed` and invert the results. That way you’re subscribed to all topics, and bbPress only stores the topics your users are not subscribed to.
Make this into a plugin:
`function invert_subscribe( $is_subscribed ) {
return ! $is_subscribed;
}
add_filter( ‘bbp_is_user_subscribed’, ‘invert_subscribe’ );`
Sounds like a conflict somewhere. bbPress should be redirecting back to the exact same topic/reply that each user creates, similar to how it does here.
Check Settings > Forums, and make sure there’s no trailing slashes on any of your settings. We can trim off the trailing slash when you save your settings, though it may have negative consequences if anyone actually relies on that.
@kannued – Also, please include links to your site.
Depends what the boolean function is comparing. Can you open a new topic in the forums here, and be more specific?
Sigh. No; first I’ve heard of it, and totally lame that’s happening.
Do you mind opening a ticket over at http://bbpress.trac.wordpress.org?
Looks like it did change, but only for the positive in this regard:
https://bbpress.trac.wordpress.org/changeset/4336
My guess is no; or that the default option value changed in 2.3 (I don’t recall) and there is no option in the DB.
Did you modify files in the bbPress plugin folder? If so, they get wiped out on every update, which is why the theme compatibility feature exists. (Do a search for it in the codex to learn more.)
This CSS rule is getting in the way:
`#content .post ul li,
#content .page ul li,
#content article ul li,
.catalyst-widget-area ul li {
margin: 0 0 0 20px;
list-style-type: square;
}`
You`ll probably want to make these rules more specific to your needs, or write a bit of CSS to reset these in your forums.
Calling is_user_logged_in() in a plugin’s init file causes bbPress to error
Plugins shouldn’t be calling any user related functions until after the user is actually loaded. The soonest place you can do this is on the ‘init’ action; doing it sooner is `_doing_it_wrong()` and will cause other hidden issues in your installation later. bbPress provides that debug notice to let you know your approach was incorrect.
Categories don’t lump all child topics together into one view. Rather, they are a container for other subforums. It’s more odd that the forums aren’t appearing. Maybe that part was removed in one of your custom templates?
Fixed in 2.3 branch and trunk. Thanks for the report.
Huh. This looks like a bug to me. Moderators should still have access to view a trashed topic, just like they can see trashed replies in the topic itself.
I’ll have this fixed in 2.3.1.
This appears to be working for me, too.
When you visit domain.com/topics, what happens?
Not entirely sure how you arrived at that solution, but I can’t imagine any of it ever working correctly. 🙂
The wp action happens before WP_Roles is called, so it’s too soon in the stack. You’re also missing a bunch of sanity checks that bbp_set_current_user_default_role already does for you; no sense in duplicating only some of that work.
You could try hooking into init but, again, I suspect something in the iMember360 plugin is interfering and won’t allow that to work correctly either.
You *should* actually be debugging the setup_current_user action, to see if bbp_set_current_user_default_role is even firing, and if it is, where it’s failing.
If you’re looking for a brute-force kludge, something like this is probably closer to what you need:
function earthman_force_current_user_caps() {
global $current_user;
// Only for logged in users
if ( ! is_user_logged_in() )
return;
// Reload the current user with correct capabilities
$current_user = bbpress()->current_user = get_user_by( 'id', bbp_get_current_user_id() );
// Try to give them a role on the site, if they need one
bbp_set_current_user_default_role();
}
add_action( 'bbp_template_redirect', 'earthman_force_current_user_caps', -99 );
/wp-content/plugins/bbpress/includes/users/capabilities.php
Thanks for the kind words. WordPress core doesn’t need a ton of work in this regard; a few small fixes would go a long way.
@earthman100 – Search for `bbp_set_current_user_default_role` – it’s hooked to `bbp_setup_current_user`, which is hooked to `setup_current_user`, which seems odd that any plugin would bypass completely, since pretty much everything a user does is linked to it.
Which is to say, I don’t think manually handling the login or user-creation process is the problem; I think this plugin is `_doing_it_wrong()` by invoking the current user far too early, before bbPress ever has a chance to hook in.
Try updating to bbPress 2.3. I’m not able to duplicate this using the latest version, using either the wp-signup.php way, or via the Network admin area.
