BuddyPress.org

There was some talk in the recent buddypress-dev meeting about creating a poll for future feature requests. When such a poll appears on the site, be sure to vote for privacy in the core if you think it’s important for it not to be located in a plugin.

Didn’t we do the exact same thing six months ago?

Privacy is crucial imho. If access management is not core, what is? Social networks can’t function without privacy controls. Members won’t use it for anything serious if they can’t control whether their posts goes to their friends or out to the world.

I hadn’t paid much attention to this issue because I assumed it was coming. With all due respect, the developers seem more interested in “new features” and cool coding challenges than straightforward usability and making sure the core is rock solid.

If you need privacy then use Jeff’s plugin. It has great potential, but it’s not ready for 1.2 core.

With all due respect, the developers seem more interested in “new features” and cool coding challenges than straightforward usability and making sure the core is rock solid.

Adding “with all due respect” at the beginning of a sentence doesn’t stop you sounding like a troll. A considerable amount of time has been spent improving the core code and the usability of the default theme. If you’re following the trunk and the dev process (which I assume you aren’t based on your own assumptions) you’d already know this.

There’s no need to worry about privacy features in BuddyPress. As I have stated previously on these forums and on my blog, I am committed to bringing my current Privacy Component up to code to work with BP 1.2. With the 1.2-beta coming out very soon, I plan to use that to finalize the new privacy codebase.

As it has been discussed before, it will be up to the community to decide the fate of my BP privacy solution. If it is deemed sufficiently useful, valuable, and robust, it will be considered for eventual inclusion into the core.

But, I’ll stress once more, that this is not my decision. Going forward, I fully expect some form of privacy to make it into core down the road—whether it is my code, part of my code, or new code.

@Peterverkooijen

If you are comparing an open source project to a car manufacturer then you don’t get it. Did you pay for BuddyPress? Andy is right, you sound like a troll. You should word your posts to sound more constructive and stop taking shots at the developers.

There are many ways to contribute besides writing code. You can write documentation, help organize developers, write specs for plugins/features and put together a team of people to make it happen.

@Brajesh, thank you for reminding people to behave in a civil manner. If people want to debate (in a civil fashion), it is best done by starting another thread.

Also, as Erich73 states above, let’s keep this thread on topic. Although many of the off-topic posts in this thread are perfectly civil, debate-style discussion, they do not help further the OT (original topic).

OK, to bring the thread back to the original subject, in the current version of my site I use Burt Adsit’s solution for the most immediate privacy problem, making members sections members-only:

function js_restrict_access(){

global $bp, $bp_unfiltered_uri;



if (!is_user_logged_in() &&

(BP_MEMBERS_SLUG == $bp_unfiltered_uri[0] ||

BP_GROUPS_SLUG == $bp->current_component ||

BP_BLOGS_SLUG == $bp->current_component)){



bp_core_redirect( get_option('home') . "/register" );



}

}

add_action( 'wp', 'js_restrict_access', 3 );

Put that in bp-custom.php and it works pretty painlessly. It doesn’t have a built-in message to let the user know why he’s being redirected though.

Haven’t tried Jeff Sayre solution yet, but apparently it has some problems. I’ll try that one in my next upgrade to BP 1.2 and WP 3.0.

Also commercial membership plugins apparently have built-in privacy features, so that could be a solution. Haven’t gotten that far yet…