Conflict between wp-members and bbpress

Normally, WP-Members wouldn’t necessarily affect the bbPress display. When set up in the default, bbPress is a custom post type that would be ignored by WP-Members. From there, there are two possible options – either add the bbPress CPT to WP-Members or set the forum as private (or a combination of both). Generally, setting the forum as private is the easier (and better) option.

If you choose (or chose already) the CPT option to add the forum custom post types to WP-Members, then it is going to handle them the same way it does posts and pages. Because bbPress contains and displays a lot of information in post meta, that is usually handled outside of the main $content variable and so is not directly handled by WP-Members. So this is only a good option when it’s an experienced user doing a setup directly in the template.

So… it sounds like what you want is for the forum to be viewable but it’s not (or at least the initial post is not)? That shouldn’t be a problem as long as the forum CPT is not being added to WP-Members in the options tab.

Yes. I want the initial post for each forum topic to be visible to logged-out users. All the boxes for custom post types in the WP-Members settings are unticked. Yet the initial topic post is not shown when logged out (shown fine when logged in).

I have tracked through to bbp_replies(). bbpress()->reply_query->have_posts() seems to give different results when logged in and logged out.
When logged in, if a topic has 1 original post and 1 reply, this returns 1 first time, then 1 second time (for the reply) then “” (for no more). When logged out it only returns 1 (for the reply to the original post) then “”.

At some point in the past I did try setting the CPT options. I subsequently switched them off (when it didn’t seem to help anything). Does this leave anything lurking in the database that might cause an issue?

There is the possibility of leaving an issue behind (although I’d have to test it to be certain). If you added the CPT for the forum, then set the block setting to “block” by default for that CPT, but then deactivated the CPT without unsetting that default value, I think there’s a possibility that the setting may remain in the plugin’s object class (since the setting for the block status is technically still there).

Not sure if that’s related to the issue you have/had, but it’s possible. It’s also a place for possible improvement in the plugin as a whole if necessary so I’ll note it for review.

I doubt that I’d have done that as I didn’t want the forums private. However, presumably if I set CPT on and unset BLOCK then it would clear the problem (which it doesn’t). Is this something that you can/would be prepared to test on your test site (add bbpress, add a forum and a couple of topics/replies and see if the topics are visible when logged out)? I have spent a lot of time trying to track this down or find a workaround but I can’t think of any way I can fix this myself. I have asked bbpress if they have any ideas that I can pass on to you to help find the problem (no reply yet).

Thanks so much for any help you can provide.

I did look into this (as far as what I mentioned above about the possibility of the setting for a CPT remaining in the specific setting if the CPT is removed from being actively managed by WP-Members), and I found that was *not* the case. If a CPT is “unset”, then all settings related to the custom post type are removed from the settings array in the object.

I set up a site with just bbpress and WP-Members on a clean database – and the problem does not occur. On my main site, it is still the case that the problem with bbpress occurs only when WP-Members is activated. I’ll try and dig deeper.

Interesting… so it may be something hidden related to the settings.

Let me know if something turns up that yields additional clues that would give a trail to follow.

Here’s where i’ve got to…
Your function do_hide_posts is what is stopping bbpress posts being displayed.
If I comment out the call $query->set then everything (seems to) work. If logged in the get_hidden_posts returns an empty array. If logged out then get_hidden_posts returns a list of 15 posts that look as if they are elementor page titles (at least some – I haven’t checked them all). The odd thing is that this list of posts doesn’t include the bbpress topics that are excluded if set is called.

Not sure why these elementor? posts have _wmmem_block=2. I suspected get_transients at first but get_hidden_posts returns the same if hidden_posts is altered to always call update_hidden_posts. Maybe that’s almost irrelevant as the list of hidden posts doesn’t appear to include the posts being excluded (though the set() call is what is excluding them!

Any ideas? I can keep the set() call commented out but maybe this will cause an issue elsewhere?

Any more ideas?

As leaving set() commented out wasn’t a long term solution (it would get overwritten if I update your plugin) I have now added the following to my functions.php in my child theme…

add_action( ‘wpmem_after_init’ , ‘kmc_wpmem_after_init’);
function kmc_wpmem_after_init() {
global $
remove_action( ‘pre_get_posts’, array( $wpmem, ‘do_hide_posts’ ) );
add_action( ‘pre_get_posts’, ‘kmc_hide_posts’ );
}
function kmc_hide_posts( $query ) {
global $wpmem;
$index = 0;
$hidden = array();
$hidden_posts = $wpmem->get_hidden_posts();
// Remove hidden pages from the list of posts to be ignored
foreach($hidden_posts as $post_id){
$post = get_post($post_id);
$postType = get_post_type_object(get_post_type($post));
if ($postType->labels->singular_name != “Page”) {
$hidden[$index] = $post_id;
$index++;
}
}
if ( ! empty( $hidden ) ) {
$query->set( ‘post__not_in’, $hidden );
}
return $query;
}

I still don’t understand why $query->set( ‘post__not_in’, **an array of 15 hidden page ids**) causes all topics and replies to be stripped from the output, but the above change solves my problem for now.

As this was a conflict between WP Members and BBpress, I reported the issue in a parallel post in the BBpress forum. Robin (author of BBpress) has just replied to that topic (where I had also posted my current solution, as per the previous reply in this topic). He said…

I suspect that this function is ‘overwriting’ a ‘post__in’ function. WP_query can have a post__in OR a post__not_in, not both, so setting post__not_in may take out a post__in set within bbpress.

Just a guess, but would make sense.