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.
@premitheme – I’ve used and tested with PHP 5.2/5.3/5.4 without incident.
The “Are you sure you wanted to do that?” errors come from nonce requests failing inside of the `bbp_verify_nonce_request()` function. My guess is the `$requested_url`, `$matched_url`, and `$home_url` are coming up with some kind of mismatch, causing `$result` to return `false` and the nonce check to fail.
It’s also possible that the parsing and comparisons in `bbp_verify_nonce_request()` could use improvement. This function was modified in 2.3 to allow for reverse-proxying, which may have broken some other type of URL. If so, would love your help there.
i seem to be a newbie at this, can you please walk me through the steps?
You’ll want to search bbPress’s files for the above function, and test to make sure it’s working correctly. If you’re operating a site as the main developer, you’ll want to know how to touch files on the server (with an code editor, FTP program, etc…)
Then, you’ll want to search the web for common PHP debugging techniques (var_dump(), echo(), die(), debug_backtrace(), etc…) so you can gain a better understanding of how the code you’re trusting to make your site function works.
This is one of those times where, hopefully, a little tough love will pay in dividends for you later.
@clickmac – You can check the results of `bbp_user_has_profile()` to make sure they are returning `true`. This is the only place in bbPress where it would specifically prevent a user’s profile from being visible (and instead invoke a 404 response) though it seems unlikely to be the cause.
I don’t quite understand exactly what you’re describing. Can you be a bit more specific? Feel free to link to a screenshot if you think it will be helpful.
What happens if you try a normal WordPress theme (twentyten, twentyeleven, twentytwelve?)
Something tells me a plugin or your theme is filtering the topics query, resulting in it returning 0 results.
The reason users aren’t allowed to delete their own posts, is because in the traditional forum sense, allowing users to modify or delete their content far after the fact can actually have negative consequences for the entire site, manipulating search results, causing 404 issues, and other URL hacks.
If this is a feature that you need as part of your community, you’ll need to invest in having this custom feature built, or read through the code and learn how to do it yourself like the rest of us.
Anyone having issues with MAMP, I run MAMP Pro locally, and have used it to develop bbPress since years back. MAMP isn’t the issue, something else is, and it should not have changed between bbPress 2.2 and 2.3.
For people having issues accessing the administration area, your account needs the “Key Master” role to access the “Forums” menu, and at least “Moderator” to access “Topics and “Replies.”
- In the past, these checks were using the `is_super_admin()` function, which would default to users with the “Administrator” role on single-site installations.
- Those that have fixed it using the auto-role setting, bbPress is automatically granting Administrators the Key Master role.
- Auto-role should most likely be turned on anyways; it’s only a setting to allow site-owners the option to let other role plugins handle that instead.
People wanting to go back to using an old version of bbPress, I’d highly advise that you troubleshoot your installations and stick with 2.3. Rolling back is a temporary fix that doesn’t help track down what’s going on; when we’re willing and available to help you figure out what is going on, it’s best to take advantage of the free support instead.
Posts aren’t “moved” between installations or versions. In fact, from any 2.2 to 2.3, there are no changes to the database at all.
There is no easy on/off switch to enable/disable this, unfortunately. It would take a bit of code to make it work (a custom plugin, etc…)
Hi Patti,
Sounds like you may be a bit confused. bbPress.org is the support forums specifically for bbPress, which is a sister project to WordPress.
Unless your sites are hosted on WordPress.com, any issues you’re having logging in are specific to your installations, and not to any central server anywhere.
i have to pay for this?
Hopefully not. A quick Google search found this plugin, though I’m not sure how well it works.
bbPress disables shortcode execution within it’s output, so that non-privileged users can’t gain access to all of the shortcodes available within WordPress. The problem is that shortcodes don’t come packaged with role/capability restrictions on their usage, allowing anyone that can create topics or replies to use any available shortcode. This is risky, so we globally disallow them.
`bbp_author_ip` accepts an array of arguments that allow you to change the before and after.
Use it like:
`bbp_author_ip( array(
‘post_id’ => bbp_get_reply_id(),
‘before’ => ”,
‘after’ => ”
) );`
There were a few issues related to this that are fixed for bbPress 2.3. You may want to look into the release candidate, and see if it’s fixed these issues for you.
