[ckriegel]

Hi, i met this issue, and for future ppl who would face the same problem, here is a simple fix that worked for me : http://zzlatev.com/bbpress-404-header-in-users-profiles/

it’s an issue with 404 being catched and not letting bbpress show the profile page, evenif it exists. You can add this in the theme function file :

function bbp_fix_users_404_headers() {
    if ( ! function_exists( 'bbpress' ) ) return;       
    $bbp = bbpress();

    if ( !empty( $bbp->displayed_user ) && is_404() ) {
        global $wp_query;
        $wp_query->is_404 = false;
        status_header( 200 );
    }
}
add_action( 'wp', 'bbp_fix_users_404_headers' );

[ckriegel]

Hi, for future people who may meet this issue, i used this fix but it worked only on one of my 2 websites. However, i could solve it on my website, and i believe that the origin of the problem has been found :

This solution may work for those who have installed a membership plugin (s2member, wishlistmember, optimizepress). The issue seems to be with the way these plugins manage the searches. They seem to catch on the fly the searches to hide content, and can create a conflict of compatibility with some other plugins like bbpress which need to display content based on roles. Plugins like Wishlistmember and S2member (or optimizepress, based on s2member,) allow deactivating of this without creating any major issue for the membership site. For those using optimizepress, it can be done thanks to the alternative view protection feature in OP. I only unchecked “Searches”, and the problem disapeared, which would confirm this idea that the issue comes from the way that searches are handled by the membership plugin.

For those using WLM, here is someone who found where to made a similar configuration (although it may have a bigger impact) :
“The issue on my site had to do with a setting in WishList Member. For me I had to go to WishList Member >> Settings >> Protection Defaults and then set the “Only show content for each membership level:” and set to “No”. After I did that it worked.”

[ckriegel]

Hi, for future people who may meet this issue, i could solve it on my website :

This solution may work for those who have installed a membership plugin (s2member, wishlistmember, optimizepress). The issue seems to be with the way these plugins manage the searches. They seem to catch on the fly the searches to hide content, and can create a conflict of compatibility with some other plugins like bbpress which need to display content based on roles. Plugins like Wishlistmember and S2member (or optimizepress, based on s2member,) allow deactivating of this without creating any major issue for the membership site. For those using optimizepress, it can be done thanks to the alternative view protection feature in OP. I only unchecked “Searches”, and the problem disapeared, which would confirm this idea that the issue comes from the way that searches are handled by the membership plugin.

For those using WLM, here is someone who found where to made a similar configuration (although it may have a bigger impact) :
“The issue on my site had to do with a setting in WishList Member. For me I had to go to WishList Member >> Settings >> Protection Defaults and then set the “Only show content for each membership level:” and set to “No”. After I did that it worked.”

[ckriegel]

Hi, i confirm that the solution offered by catalyna may work for those who have installed a membership plugin (s2member, wishlistmember, optimizepress). The issue seems to be with the way these plugins manage the searches. They seem to catch on the fly the searches to hide content, and can create a conflict of compatibility with some other plugins like bbpress which need to display content based on roles. Plugins like S2member (or optimizepress, based on s2member) allow deactivating of this without creating any major issue for the membership site. For those using optimizepress, it can be done thanks to the alternative view protection feature in OP. I only unchecked “Searches”, and the problem disapeared, which would confirm this idea that the issue comes from the way that searches are handled by the membership plugin.