Search Results for 'disable registration'
-
Search Results
-
Many people have been inquiring about privacy options in BuddyPress. Some of you are aware that I am currently coding a Privacy Component for BuddyPress. I decided that it is time to fill the community in on my component, providing more details and a timeline.
My Privacy Component will be entering a private alpha early next week. After the alpha phase is complete, it will then be available as a public Beta. If it goes well, and Andy likes it, it may be included in the BP core for version 1.2. If you look at the BP roadmap, you will see that that is when privacy filtering is scheduled to be included in core.
In this screen capture of one of the privacy setting screens, you can see that there are actually six user classification filters that can be chosen for each BP object. The sixth option, “Relationship Mapped”, is made available by a separate plugin which I’ll be releasing later. The default Privacy Component will offer five levels.
My current estimated release date for the first public beta is the week of October 5. This date may change depending on the feedback from the alpha phase.
More Details
This is taken from the Privacy Component’s current readme.txt file:
BPAz is a privacy control component for BuddyPress that provides a site’s users a mechanism with which to control who has access to which pieces of their personal data.
== Description ==
The BuddyPress Authorization component (also referred to as BPAz, BP-Authz, or BuddyPress Privacy Component) is a BuddyPress component that allows users fine, granular control over who has access to which pieces of their personal data. It provides this service by hooking into BuddyPress’ core functionality, thereby giving users the ability to control (grant or deny) access to each piece, or grouping of, their personal data.
The term “auth” is often used interchangeably for authentication or authorization. There is significant difference in meaning between them. Authentication is not authorization. Authorization is not authentication. Authentication must come before authorization. Authentication is handled by WPMU, initially by the registration process and subsequently by the login script. Authorization deals with verifying and managing the access rights a given authenticated user has to certain objects.
Because of this confusion, the process of authentication is now often referred to as A1, or AuthN, or simply Au. The process of authorization is now often referred to as A2, or AuthZ, or simply Az. Since authentication must come before authorization, the A1-A2 ordinality of the terms is evident. This also explains the alternate names BPAz and BP-Authz.
BPAz deals with authorization by verifying and managing access rights an authenticated user has to other’s objects–although a user may choose to expose their data to non-logged in users as well.
The core BuddyPress objects on which rights can be set:
- xprofile fields
- activity stream actions
- friends list
- groups list
- messaging
- blogs
- wire
- status updates
The basic access levels configurable per object (some objects offer only a subset of these rights):
- allow/deny anyone (globally public or globally private). This is accomplished by setting an object’s viewing rights to either “All Users” or “Only Me”
- allow only “Logged in Users” to view a given object
- allow only friends to view a given object
- allow only a specific list of users to view a given object. This is also called per user access control. This is accomplished by setting an object’s viewing rights to “These Users Only” and then entering a comma-separated list of usernames (a member’s login name) in a textbox that becomes visible.
NOTE: Per relationship-type access control is possible if you use my BuddyPress Relationship Mapping plugin. For instance, allow by friend, colleague, partner, client, customer, fan, etcetera.
Site Administration of BuddyPress User Privacy Tools
Site administrators have ultimate control and oversight over the configuration of BPAz’s features and functionality via an additional administration panel under the BuddyPress menu hierarchy. The BuddyPress Privacy Component is enabled by default for all object groupings. However, Site Administrators can disable user-configurable sitewide privacy, or even individual privacy control objects, by using the Privacy Settings administration panel. As the Site Administrator, you will always be able to see each user’s complete content. Users do not have any options to hide content from Site Administrators.
Since I am going to disable user registrations, I would also like to remove any related link from my page, which would be on top next to the login button, on the Buddybar and wherever else it might appear. What lines in which files do I have to remove to do that?
pxlgirl.
I’ve done a fair bit of searching without finding an answer, so please excuse me if this is asked and done with.
I wish for our members to be able to participate in blogs that only the site admins have created. Thusly, the option for users to create blogs is turned off in the WP admin.
However, the “create a blog” option still exists in 3 places in Buddy Press:
My Account > Blogs > Create a Blog
My Blogs > Create a Blog!
(member page) > Blogs > Create a Blog
Clicking any of these takes the user to a “Blog registration is currently disabled” message… I feel this makes us look as if we forgot something or made an error.
I’d LIKE to be able to remove these “create a blog” references, at the very least, if not limiting users altogether. I’ve tried following Burt’s advice in “Limit Blog Creation to Admins,” but must confess that that level of php work is as yet beyond me. (http://buddypress.org/forums/topic/limit-blog-creation-to-admins)
Has anyone thought of a solution for this or can think of a way to accomplish it without needing to manually edit a lot of php?
Thank you guys, any answer would be appreciated.
Topic: Very weird spam incident…
Hi everyone
Ok, here we go again. I have WPMU v2.8.2 and BP 1.0.3 installed. Also, the latest version of BBPress, FB-Connect, reCaptcha and Askimet.
About a week ago, despite having ALL registrations/posts/comments completely disabled, a person/bot was able to sneak through and register for an account.
I posted back here and asked what I should do about this and was advised to install reCaptcha (which I did).
Now this morning I went to my BP site and see that once again someone has registered for an account and not only that but they have also used my FaceBook name as their sign-up name but when I click on their icon, instead of taking me to their BP profile, it just refreshes the page. A further look shows that they used a FaceBook URL but used several trailing slashes in the address and no email address was provided.
At first I thought that perhaps this account had been automatically created when I logged into FaceBook under my FB developer account so I tried to recreate this but no dice.
It looks like once again, someone has gotten through. I have no idea what their game/gig/motive was in creating an FB account using my name or how they even got in. I know it wasn’t a family member or friend playing a joke on me either (as has been suggested).
Any ideas?.
Thanks, Steve
Hi everyone
I’ve had WordPressMU/BuddyPress installed for several months now. Recently I upgraded to WordPressMU v2.8.2 and BuddyPress v1.0.3. I’ve always had registrations disabled and recently I installed the latest version of Askimet.
Everything has been installed by-the-book and everything has worked perfectly until this morning when I awoke to see that someone had registered with the user name “LnddMiles” – despite registrations being disabled and having Askimet installed.
A Google search quickly showed that this same user has registered on thousands of other BuddyPress sites.
Additionally, I am now getting the following error each time I access my admin center…
Warning: Missing argument 5 for fbc_get_avatar() in /home/azonez/public_html/wp-content/plugins/bp-fbconnect/includes/wp-facebookconnect/fbconnect.php on line 529
What does this mean and what can I do about this?.
Thanks for any help and have a great day!.
– Steve
What file/template do I need to modify to remove the Avatar upload in the registration process? I don’t want to disable avatars, just disallow them at signup.
The cleanest way to get separate firstname and lastname into the database seems to be to
1. make a two or more part name in fullname on the registration form required
2. consistently split the input from Buddypress’ fullname field and synchronize with usermeta using xprofile_sync_wp_profile()
How would I do that? I assume this could be turned into a plugin?:
function xprofile_sync_wp_profile() {
global $bp, $wpdb;
if ( (int)get_site_option( 'bp-disable-profile-sync' ) )
return true;
$fullname = xprofile_get_field_data( BP_XPROFILE_FULLNAME_FIELD_NAME, $bp->loggedin_user->id );
$space = strpos( $fullname, ' ' );
if ( false === $space ) {
$firstname = $fullname;
$lastname = '';
} else {
$firstname = substr( $fullname, 0, $space );
$lastname = trim( substr( $fullname, $space, strlen($fullname) ) );
}
update_usermeta( $bp->loggedin_user->id, 'nickname', $fullname );
update_usermeta( $bp->loggedin_user->id, 'first_name', $firstname );
update_usermeta( $bp->loggedin_user->id, 'last_name', $lastname );
$wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d", $fullname, $bp->loggedin_user->id ) );
$wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET user_url = %s WHERE ID = %d", bp_core_get_user_domain( $bp->loggedin_user->id ), $bp->loggedin_user->id ) );
}
add_action( 'xprofile_updated_profile', 'xprofile_sync_wp_profile' );Hook it to register_post? Does this code already check if there’s a two part name? I suspect that happens at ‘if ( false === $space)…etc.’, but I don’t see an error message + redirect or something like that.
Or is it impossible to use this code during register_post because of this line:
$bp->loggedin_user->idHow can I modify the code to make it work during registration? Can I just remove that line? Or run this function the first time the new user logs in? Is there a hook on_activation or something like that?
Has anyone used xprofile_sync_wp_profile()? Can anyone share code examples? This would solve a major structural problem in Buddypress imho.
I need to come up with a solution, because integration with most mailing lists depends on having firstname and lastname stored somewhere.
Alternatively I can use fullname for firstname and create a second custom xprofile field for lastname, but I suspect that solution could cause lots of problems further down the line.


