Introduce simple "Private Site" toggle

[dcavins]

Explore adding a very simple "private site" feature like
[] Require user to be logged in to visit BuddyPress components
that would easily create a private site where content is only available to logged-in users.

These items would need to be considered:
Page viewing
REST access
RSS Feeds/other programmatic access?

[shawfactor]

There are several reasons why this should not be added

Firstly there plugins that do this already, so I don’t think it is necessary.

Secondly privacy is not binary, there are various levels of privacy that may be appropriate (all of which can be achieved by plugins

Thirdly I don’t think we need more options, remover decisions not options

[imath]

Thanks a lot for opening this ticket. Building a private community is a request users are often making about BuddyPress. Here are some examples:

• ​https://wordpress.org/support/topic/best-free-plugin-for-social-media-2/
• ​https://wordpress.org/support/topic/confusing-and-incohesive/

I believe including a very straightforward way to use BuddyPress to add to his WordPress site a private community is something we should consider.

@shawfactor your first and second points are somehow the same "plugins can do that". Sure they can and it's fine if they can offer the various levels of privacy to extend a very basic level one provided by BuddyPress.

Problem is, a new user don't know about these plugins (me neither by the way!). He tries to see how it can be done from settings, don't find, uninstall BuddyPress and then share a bad review looking like "how come such a basic feature is not included into BuddyPress???"

The goal here is to include this very basic way of making a small private community as a start, if people need more granular control over privacy, then yes I trust you that there are specific plugins to help them satisfy it.

Let's talk about it during 11.0.0 development cycle. I'd really love to have more feedbacks about it and not only from developers like us but from users.

[shawfactor]

i reiterate that this is a terrible idea

You are right that buddypress is not useful by most people without additional plugins .

This is how it exactly should be. Social networking means many different things and it is highly unlikely that basic buddypress will match the goal you have when you first start. This is no different to WordPress itself, no one uses WordPress without plugins.

Indeed considering how complex social networking is trying to cater to the needs of even the majority of users in core is impossible. Arguable you’d need to add forums, attachments, anti spam, tagging, a buddypress theme, and privacy. That is just off the top of my head,

It gets ugly fast and sets a bad precedent both in terms of bloat (this is already a problem, abd I’ve raised two trac items about two legacy features that are a pain point) and it undermines the vital plugin developer ecosystem that exists around buddypress (I’m one).

Instead we should keep building the apis that are needed. The two urgent ones are the attachments api and integrating with full site editing.

The lesson we should take from the two reviews you linked too is the need for better documentation, help forums, and onboarding. I understand this is already happening

[imath]

Thanks for your 2nd comments about this, I understood your points. Are we all ok with:

« BuddyPress is not useful by most people without additional plugins » and that’s the way it should stay?

I’m not. We should at least provide all the basics plugins can extend.

Why having private or hidden groups but no native way to build a private community?

Again, I’d really like to read some other feedbacks and user ones if possible 🙂

[shawfactor]

You’ve mischaracterised my point

Buddypress is not particularly useful without additional plugins and that will remain the case even if a privacy option is added.

Sure we could add the various features over many years but it would be a massive amount of work and a huge backwards step as

1. It would create a huge technical debt
2. It would come at a huge opportunity cost to the real work that should be done
3. It would be a massive pain to people who want to do those features differently (eg privacy is a spectrum that a simple option cannot capture
4. It will alienate the small group of plugin developers who would be cannibalised

Like it or not buddypress like woocommerce is a platform and we should concentrate on the apis that others can build on top of.

[imath]

After your 3 comments I confirm I understood you don’t want us to include such a basic feature. Thanks a lot for your interest in the project directions. I want to read other people points of view, you clearly made your point but I don’t understand why a basic private community feature would do so much arm to the plugins ecosystem or would transform BuddyPress all of a sudden to something completely different than it is today.

I’d like to stress the fact that without users, there’s no BuddyPress or BuddyPress plugins. That’s more concerning imho than an option into the dashboard. BuddyPress plugin authors should be more involved into contributing to BuddyPress, I’m glad you often share your opinion, but I’m concerned not many others are at least beta testing the BuddyPress beta release. You’re talking about API’s but I never saw a patch from you to improve existing ones. Show the way! Build patches & contribute to code/tests and documentation, we’ll be very happy to be able to benefit from your work.

There would be things to think about on the BuddyPress plugins topic : how come each time I read from a user about it, it’s negative like « broke » or « no more maintained », etc.

We are clearly observing a huge decrease on active installs stats. This basic feature might not be the thing to inverse the trend, but it would at least show a basic private community can be easily built for users who only need a logged in user only community area. It doesn’t prevent plugins to build something more granular. So to me we can still consider it for 11.0.0.

Instead of saying « no » with the plugins perspective only in mind, let’s open our eyes on users who won’t search for plugins once they figured out there’s not even a basic switch to private pages like it exists in WordPress.

[shawfactor]

A basic privacy option won’t change much at all in itself but it sets a precedent.

Re patches from me, basically the main barrier is GitHub. I need to familiarise myself with it. I’m a self taught programmer I know it is hard to believe but I and have barely used it and would have no idea how to patch things (although I will learn). I’d also say that in terms of contributing buddypress will be better served by me publishing the rest of my plugins (I’ve about 50 I’ve been meaning to put in the repository)

Re installations falling. How dramatic? The statistics in the repository show a decline over 2-3 years. I’d speculate that is inevitable for several reasons. The first is the main competitor is Facebook so the overall market is declining but conversely I’d say the sites that do remain are higher value (more users and more complex). Secondly I’d say that buddyboss cannibalise buddypress so overall installs of both may be growing. Anyway I’d be interested in more data

Finally I’d suggest we’d be better served documenting, shepherding, and assisting new users of buddypress. Making it easier to add plugins, maybe having canonical plugins etc (see Matt Mullenwegs recent comments).

I realise this has all got a bit meta so if there is a different place to continue this thread let me know.

[imath]

Ok, thanks for this new comment, in short : I’m ready to take the responsibility of setting this precedent. If we need to talk more about competitors and project management improvements (energy/time to put on documentation, support etc..). I’m totally open to this and I’ll add a specific point about it to the agenda of our next dev-chat (next Wednesday at 19:30 UTC).

So let’s move on to the « how ».

The more I think of it the more I believe as we use regular WordPress pages to set components root pages that we should use the corresponding page status to decide about the privacy of component’s content. This means we don’t need an option and can use the pages post statuses instead.

This means we’d need to take in account the protected by a password status and decide how we should handle it.

[shawfactor]

That makes perfect sense.

Using the post status makes perfect sense and is a low bloat logical approach, that actually allows a high level of flexibility.

My only concern thoughts are

1. Is this future proof, ie is the plan to keep using pages to proxy buddypress components? I don’t have an opinion but I always believed that eventually buddypress would move away from doing that

2. Would it work with custom post statuses? The would be a great approach btw. I’ve used your wp statuses library and the two could play nicely together, especially if the buddypress components moved to custom post types.

[epgb101]

Hi all..
I will add my 2-cents and probably be shot down :) I managed to make a private community using a plugin but it was a bit of a nightmare to get it right and I had t try a dozen plugins and it took me ages to get it working right with tones of testing and retesting - several plugins did not work properly or partially. While I was doing this I was really wishing it was built in and to my mind is a no-brainer - but then again I am not the one having to code it and I REALLY appreciate what you people do. So perhaps it should be built in - or not - but that's what happened to me.

E.

[imath]

Hi @epgb101

Thanks a lot for sharing these inputs with us. You're very welcome to help us identify the potential blocks we'll find on our road, feel safe & free to contribute: we might woof hard but we don't bite 😅

[dcavins]

Enable simple site privacy. Prevent access to BP pages, RSS feeds, REST API. Allow access to Registration and Activation screeens.

[dcavins]

Location of option input in BP settings.

[dcavins]

I've added a first patch that adds simple privacy with filters so that plugin authors can include their screens in the scheme or so that users can allow specific items to be visited.

The REST API disabling seems pretty sad; it's an all-or-nothing routine. Hopefully someone who is more familiar with the REST API can suggest a better approach that would generally disable the content but allow for customization of what is available.

[johnjamesjacoby]

A few thoughts:

• Try not to think about a future setting as "making a site private" but rather a "default community visibility"
• Use bp_current_user_can() with some unique and new capability key
• "Enable Private Site" should be something like "Community Access"
• Checkbox on/off setting should be a filterable list (either a Select or Radios):
  • Public - Anyone: maps to exist cap: current_user_can( 'exist' )
  • Private - Registered Members - maps to is_user_logged_in() callback
  • (Custom) - added by plugins
• New member registration setting should be nearby in the GUI to help users imagine what that flow is

Now is a good time to (re)consider the default value of this setting:

• Public by default for upgrades
• Private by default for new installations
• Relative to if the community has open sign-ups, is invite-only, etc...

[imath]

Hi @dcavins

Thanks a lot for your work and for the patch. I've tested the patch, it behaves as you described. Although efficient, I believe redirecting the user to the login screen when they have no access to the community area is not very user friendly or not very welcoming.

Many thanks for your feedbacks @johnjamesjacoby I'll share a PR just after I've posted this comment that is following most of your suggestions (except: I've left new installs as "open" communities, but I agree we can consider it).

You'll see in the PR that we can use a different approach, leaving users to use the WordPress Block Editor to set the content of the page displayed to the not logged in member. In short if the current user does not have the mapped WP cap to a new bp_read cap, BuddyPress globals are not set and no community content or RSS feeds are generated. We stay in a regular WP Post.

If this post has no content, we can display a default one inviting the user to log in or register/request a membership.

NB: the private post status was a bad idea (I can say it was bad as I was the first one to have it!) as you need to be at least an Editor to view pages having this post status. I wonder why WordPress made this choice in the first place...

The main idea is to unset the buddypress()->pages when the user hasn't the WP Cap mapped to a new bp_read one. As a result BP Globals like current_component, current_action and action_variables are not set and we end up into a ! is_buddypress() area for not logged in members when the community visibility option is set to members. Activity RSS feed are then not set. I believe if we use this scenario, we'll need to edit the BP Rest API endpoints to use the bp_current_user_can( 'bp_read' ) into the permissions_check methods.

A benefit of this is the site admin can easily customize the default content displayed to not logged in members using the Block Editor for the corresponding BP Pages.

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/8734

[johnjamesjacoby]

NB: the private post status was a bad idea (I can say it was bad as I was the first one to have it!) as you need to be at least an Editor to view pages having this post status. I wonder why WordPress made this choice in the first place...

Oh. Yeah. Duh. Of course! LOL 🤣 And, I think even if we tried to be clever and use them, it may unintentionally be a confusing kind of override.

[sbrajesh]

Great job on this @imath .
I had a look at your patch and it seems the idea of unsetting the $bp->pages is not a good idea.

A private community does not mean it is not a BuddyPress community/page. It means that it is a BuddyPress page but inaccessible to the current user. In other words, we need an extra flag there.

So, all the things like current_action, current_component and pages should be set but the code that replaces the post content should know that the current page is private and either not replace the content with BP one or should provide a way to load a privacy template.

Another minor enhancement would be to either have dynamic visibility options( filterable array as suggested by JJJ above or have an action on the settings page where options are rendered in bp_admin_setting_callback_community_visibility to allow extending it.

I believe this is a great start for having a privacy for community feature. Keep it up.

[imath]

Thanks for your feedback @sbrajesh 😍. We can probably leave the $bp->pages set, I agree. For the other globals I would agree too if we were sure that all BP plugin developers would update their plugins to respect this new community settings. I’m afraid considering their participation to beta testing this is something we can’t be sure of. The other option is the one suggested by @dcavins. If you have another idea that makes sure à not logged in member won’t be able to access any plugin generated BP page, I’m totally open to it.

[shawfactor]

Whatever way you go on this is it must be possible to disable this functionality entirely (so that users like me can apply their own logic)

I run a Multisite with some components shared and others not. Sone components are private but some are not e.g. groups. I handle this via code atm and I’d like to continue doing so.

[sbrajesh]

Hi @imath
Thank you :)
I agree that plugin authors haven't been(I am guilty too) doing much.
Still, BuddyPress is the upstream and does not need to worry about downstream plugins. the onus should be on plugin authors to make sure the follow the updates of BuddyPress.

I like the approach by @dcavins. It allows to disable the privacy partially(exclude some section/pages) or disable it completely(@shawfactor has requested it). It can be updated to use the capability suggestion by jjj(your implementation in the last patch).

In other words, we can mix your addition of the 'bp_read' capability and use it on the hook 'bp_private_site_user_has_access' in @dcavins patch.

That will be very flexible at the same time will work for most of the setup without any issue. What do you think?

[imath]

David’s patch is very efficient I agree. My problem with it is, it’s throwing the user to the login page without more explanation and I believe (I can be wrong, of course), as Admin users often request more & easy customization, we should enjoy the post content of the corresponding page to let them use block widgets (BP Login form for instance) and any other block to attract users to engage into their private community. So it seems to satisfy both potential needs.

Disabling the community restriction can still be done easily in my patch filtering into the mapping caps function, remapping bp_read to exist

Another option, can be to leave the legacy parser do the parsing job to set constants then add a hook to let plugin shortcircuit a potential reset of this constant if the user is not loggedin. I believe it could satisfy Admin users need for « a better UI than the login form to welcome new members » and plugin authors ones 😅

Another option could be to use a specific directory to welcome these users using templates from template packs…

@sbrajesh we need to care a lot about plugins & themes, we think about them almost each time we’re adding a new feature, end users don’t see a difference between BuddyPress and BuddyPress plugins/themes, it just doesn’t work for them and they don’t have time to find what is wrong, they move to another community software. That’s why we always put complicated backcompat code and why we are now using the feature as a plugin model to try to prevent potential issues with plugins (unfortunately not many plugin authors are testing them, but that’s another story 😇)

That being said, many thanks to you and @shawfactor for contributing to this ticket 😍

[johnjamesjacoby]

Perhaps we scope-creep this to include a redirection destination, with accompanying filter and/or Page setting, and/or dynamic block template or part(s) pattern to add to the locator?

In other words, an officially documented and preferred approach to split which template parts get located based on the logged in users’ ability to view them?

[dcavins]

I like the idea of the bp_read capability. To make it easier to tune the behevior of (in plugins or other code), what if we add a context parameter to it so that you know which capability is being tested. Like current_user_can( 'bp_read', array( 'context' => 'bp_rest_members_get_items_permissions_check' ) )
or maybe

current_user_can( 'bp_read', array( 
	'context' => array( 
		'primary' => 'bp_rest',
		'secondary' => 'members_get_items_permissions_check' 
	)
)

so that you could easily generally allow or deny bp_rest for instance. or maybe the component is the key.

current_user_can( 'bp_read', array( 
	'context' => array(
		'component' => 'members',
		'interface' => 'bp_rest',
		'capability' => 'members_get_items_permissions_check' 
	)
)

I'm not sure what properties to send, but having a central, easy-to-control logic for this would be useful.

[sbrajesh]

Thank you @imath
@johnjamesjacoby has a an excellent suggestion which will help site admins use any of the approach(even if that happens via plugins/code). They can go for redirect to login or show the page with login/register message(which is fine if you prefer it that way for default).

My issue with current patch is while bp_read is a good addition, It does not say anything about the current context. If the page/component/actions are not available, there is no way to modify it for a certain directory page(Say, we try to open member directory but keep everything else private).

It will be nice to have a solution that provides context. bp_read is good and it might have it benefits on the REST API as suggested above as all the routes are managed by BuddyPress(core) and any routes added by external plugin will have their own way of dealing with it(BuddyPress won't be affecting them).

[imath]

Hi @dcavins @sbrajesh & @johnjamesjacoby

Sorry for this late reply! I was pretty busy this week.

I've improved the initial PR trying to take in account as much feedbacks as possible.

1. Being able to "bypass" the capability check. Context information are now sent and plugin authors can use it to decide whether they should bypass it or not. Here's a ​code example to allow the members directory to be viewable by any user.
2. I've used @dcavins first idea about redirecting the user to the login page when the BP Theme or BP Template pack does not include the members/gate.php template. For this case, I've improved the bp_core_no_access... function so that it's possible to add an error message more suitable for the context. You can test this fallback activating BP Default or the BP Legacy template pack.

@dcavins about your suggestion, I believe these caps should be dealt within the components classes, we could add a filter into the BP_Component class they are extending, this way, they'll be able to manage their specific contexts.

[johnjamesjacoby]

what if we add a context parameter to it so that you know which capability is being tested

I think, the conventional way to do this, would be to invent a naming pattern for unique capability names, and map all of them down to bp_read via map_meta_cap: I.E. “prefix_verb_component_action_subaction(plurality)” = bp_get_group_members_invites

In this way, the cap keys are registered, buildable, and predictable?

Then, I think, anything that is considered “contextual” for the can either pass in a single ID or nothing, to continue to mimic WordPress and just about every other plugin, and would be accessible via some bp() value?

(I’m guess, I am reluctant to introduce a totally new usage pattern into cap parameters, from a healthy fear of them being implemented in a way that allows members to access things they shouldn’t be able to.)

Very open to feedback on these ideas. Never intending to halt progress. Only thinking out loud. 💕

[sbrajesh]

Hi @imath
Thank you for the work on it. It is going in the right direction. I have a few suggestions and will love to hear your feedback.

1. As @johnjamesjacoby points, the context parameter(non id) seems a bit out of the place there. We should avoid it.
2. It would be nice to have a function similar to the function bp_user_has_access() which provides a simple filter, context and uses bp_read cap.

3. Also, I am not sure if introducing additional complexity is required. We can let the original parsing work as it did earlier. Then, we simply hook to 'bp_replace_the_content' and if the community is not visible, we just discard any other hooked content and load the community gate template.

Just some thoughts to keep it simple. It is alright if you decide to go with the current implementation.

[imath]

Let's take some more time to think about it, for now I'll move this ticket to next release.

[dcavins]

With new rewrite code, refer to ​https://github.com/buddypress/bp-rewrites/blob/trunk/inc/functions.php#L369%7CL438 for example of "no access" step.

A new & improved way of dealing with this visibility feature will be soon worked on.