BuddyPress.org

If a user registers through the buddypress registration on a sub blog, which is buddypress they are registered subblog.mainblog.com, resulting in a new blog of userblog.subblog.mainblog.com. This completely defeats the purpose of buddypress as a “site-wide” application and negates the good buddypress registration form, and the login form to include “to register” The code should be grabbing site url, not the buddypress subblog url.

There are no instructions I’m afraid. You have to dive into the BuddyPress code.

Just looked at the plugin, here’s some sample code:

add_action('bp_before_registration_submit_buttons', 'display_recaptcha', 9999);

add_action('bp_signup_validate', 'check_recaptcha_bp');

You’ll have to write your own validation function for BP. I’ve called the new function check_recaptcha_bp(), but you can call it whatever.

For more info, look at buddypress/bp-core-signup.php, I’ve given you the tools needed to walk, now run with it

Should I notify the WP ReCAPTCHA author? He seems to be rewriting the plugin for WP 3.0. I’m just looking for the instructions for “hooking it in” to the registration page. I can’t seem to find them anywhere. It sounds like if I had MU and BP running together it would work fine, but I only have BP, so I need the hack…

@svenl77

There is a problem with version 1.8…it prevents blog creation.

It was fine…then I upgraded this morning and tried to create a new blog. no luck. The creation page is there, but, when you hit “create blog”, it takes you to an empty blog directory page (and the buddypress admin bar is gone). In the backend, the new blog is there. But, if I try to go to it’s dashboard, An error message comes up saying that the blog was not installed correctly, please contact administrator.

I deactivated the plugin and could then create blogs fine.

So I deleted if and loaded in a fresh copy…thinking that somehow I messed up the settings. Nope. The fresh copy kills blog creation too.

I’m not on the default theme, but not of the registration/blog creation commands are different.

Anyone else experiencing this?

What are you trying to do exactly?

Are you trying to modify the BP registration page?

captcha and math tools do not really help fighting spam.

spammer register manually and then feed your blog automatically remote via xmlrpc.

i am running a wordpress mu + buddypress site and had about 40 spammer-registrations a day with lots of spam. then i deactivated xmlrpc via renaming xmlrpc.php in wp-root, result was only user registrations (without content spam). about four days later spammer registrations were reduced from 40 to about three a day (easy to delete), seems that the spam-apps noticed that the rpc doesn´t work and deleted my site from their targetlists, entering their messages manually is to complicated for them….

On WP 3.0 MultiSite, it’s under Super Admin -> Options, scroll down to Registration Settings

Works fine.

I havent had a spammer registration since i used the “WMPU block spam by math” plug-in. i was getting 20 a day, and now absolutely zero.

https://wordpress.org/extend/plugins/wpmu-block-spam-by-math/

Well, it’s only a ten minute job if you know how to hook it into the registration page.

I changed the signup page name, stopped all new registrations across all blogs, added to the htaccess page and STILL get signups.

I asked over at wpmu and they say it is Buddypress causing this and to ask here but I see that BP blame WPMU.

Great!

This is an old thread.

Basically, the WP-reCAPTCHA plugin needs to hook into the BP registration page actions for it to work.

It’s a 10-minute job at most.

that’s weird. I have never seen gmail “eat” a registration email. AOL is really bad at this, in my experience.

does your domain include any text that might result in it being “flagged” by gmail as junk?

the api eh? (a large percentage of shared hosts are poor quality, we’ll never be able to fix that) my take is that at it’s core, it’s “the missing extended user profile framework for WordPress”. It would, in my feeble opinion act primarily as a framework api for extending those profiles. Some of the issues and limitations are really presented by wordpress and mu.. not Buddypress and in much the same way that bp extended the wordpress user profiles/functions we should tackle those head on as had been done with the improvements in the BP1.2 registration. There are infinite ways to build on those relational database fields. Focus exclusively on bp_xprofile _fields, and _data. It’s not that I’m anti-activity stream and the terms social network, life stream or whatever just seem to incorporate user profiles into some sort of relational scheme, be it friends, followers, ‘like’-ing, sharing or chronological micro blogging. Extending the stability, functionality, and interactivity of each component is the goal, but I’d prefer to see no dependency among core elements with one another. It’s fairly simple to build out a “social network” in other popular content management systems by extending the user database fields and in my day to day practice, I typically use only about 20% of the Buddypress core components for a WordPress project. Even though the hype is in the activity stream and the extensions for it (more facebook or twitter like), I side with @stwc in that “It also means that the platform has to have a robust set of tools for the administrator and moderators of the community “. A community (or ‘social network’) is just a set of users and to me, key items are a small footprint on the database and tight the integration with the existing wordpress user roles, permissions, registration and management. The api should ideally be flexible enough to accommodate any possible relational data between user profiles that a plugin author may dream of. I think the core integration between user profiles and the activity/blogs/groups/forums/friends illustrate the foundation of the api and should be as unified, consistent, and simple as possible with very little dependency or overlap in functionality. This would be impetus for creating a more standardized way to interact with the xprofile and be a good foundation for a solid api. lastly, thanks @mrmaz for starting the thread, being pro-active, getting the trac and api.buddypress and generally illustrating the potential of a solid api in regards to how well your links plugin and others can interact with the core.

ps.. death to PHP4 and fsck backwards compat

Just looking into the bp_core_signup_user() function again. Sorry for pointing this to you in the first place!

I would not recommend using this function because it sets a user’s status to “not active”, then sends an email to activate the account (which makes sense because that’s the default registration behavior in BP!).

Since we don’t want to ask a FB user to activate their account, stick with the wp_insert_user() function, then use some code to sync up the xprofile fields like:

// set xprofile field 1 (Name) with the fbuser's first name

xprofile_set_field_data(1,$user_login_id,$fbuser['first_name']);



/*

* @param $field The ID of the field, or the $name of the field.

* @param $user_id The ID of the user

* @param $value The value for the field you want to set for the user.

*/

To initialize BP, look at using the bp_init action:

https://codex.buddypress.org/how-to-guides/checking-buddypress-is-active/

[EDIT]

Just looking into the WP-FB-AutoConnect plugin, Justin (the author) has a do_action that you could hook into:

do_action('wpfb_login', array('WP_ID' => $user_login_id, 'FB_ID' => $fb_uid, 'facebook' => $facebook) );

Here you can sync up your xprofile fields, etc. Unfortunately, this action occurs every time a Facebook user logs in. You could view this as a positive or a negative!

I think it would be nice if Justin added another do_action right after the wp_insert_user() function in _process_login.php.

[EDIT #2]

Requested a new do_action on Justin’s plugin page – http://www.justin-klein.com/projects/wp-fb-autoconnect/comment-page-5#comment-11638.

@techguy

That’s correct the $usermeta variable holds the submitted xprofile fields from the BP registration page.

eg. you could do this:

$usermeta['field_1'] = $fbuser['first_name']; // field_1 = "Name" on BP registration page

You’ll have to grab the correct field_x name for each xprofile meta you want to sync up with the FB auto plugin.

—

BP_VERSION might not be working because WP-FB-AutoConnect is probably loaded before BP, so WP-FB-AutoConnect (man that’s a mouthful!) doesn’t know that BP exists.

Hmm, RSS… that is a little complicated. Also another implication I did not think of is the activity stream. If the idea is to restrict access to content, then both the RSS, the activity stream (and the activity stream RSS) have to be considered.

Before we go down the route of considering another plugin, have you already tried this one?

https://wordpress.org/extend/plugins/bp-groupblog/

BuddyPress Groupblog

Description Installation Screenshots Other Notes Changelog Stats

Author: Rodney Blevins & Marius Ooms

The BuddyPress Groupblog plugin extends the group functionality by enabling each group to have a single blog associated with it. Group members are automatically added to the blog and will have blog roles as set by the groupblog admin settings.

Features:

Full blog theme integration. The included bp-groupblog theme mimics the group pages.

WP Admin option to set default blog for groups plus bonus options.

Automated blog registration at group creation stage.

Bypass default blog validation to allow dashes, underscores, numeral only and minimum character count.

Blog privacy settings are initially inherited from group privacy settings.

Group members are automatically added to the blog.

Blog roles match group roles as set by the group admin.

Solid error checking that the blog follows validation.

Group admin tab to access the group-blog settings.

Recent posts are displayed on the group home page, much like the forum topics.

A menu tab is added to display the latest blog activity and blog page links.

Blog themes will have the ability to pull in group info and create a theme that could resemble the group exactly.

Leaving the group will downgrade the member role to ‘subscriber’.

Allow the group admin to select one of his/her existing blogs.

Known Issues: * Group blog post do currently not show up in the group activity stream. Therefore as a short term solution we are including a custom activity loop on the blog page. This should be fixed in the future.

Roadmap:

Allow the admin to let group admins choose the blog name, instead of following the group name.

Frontend posting from the blog home page.

Redirect options to integrate deeper with the blog.

Include an RSS icon for easy access to the Blog’s RSS feed.

I get the same error on multiple sites (using the same host though).

It’s fine when I have a localhost install, and it’s also fine when I’m not using buddypress.

I go to the registration page, fill out my details and then click on Complete Sign-up. It then takes me to the same page again, almost as it if just refreshes.

My registration URL is http://ferryglide.com/wordpress/register

The plugin referenced above works fine for me on a new install.

Thanks r-a-y. Lots to learn and I always forget there’s so many ‘duplicates’ between BP and WP.

How does the bp_core_redirect() differ from this code in the thread you linked to (besides where it redirects)?

function oci_login_redirect($redirect_to, $set_for, $user){

$redirect_to = bp_core_get_userurl($user->id);

return $redirect_to;

}

add_filter(‘login_redirect’, ‘oci_login_redirect’, 10, 3);

@duffcub

Read this:

https://buddypress.org/forums/topic/faq-how-to-code-snippets-and-solutions#post-37123

@techguy

Use bp_core_redirect();

From the commented code:

– Performs a status safe wp_redirect() that is compatible with bp_catch_uri();

eg. redirect to logged in user’s profile:

global $bp;

bp_core_redirect( $bp->loggedin_user->domain );

Can’t you do something like this?

<?php

function login_redirect_activity ()

{

wp_redirect (get_option(‘siteurl’) . ‘/activity/’);

}

add_action (“wp_login”, “login_redirect_activity”);

?>

The location it redirects to might be wrong. Here’s the reference for the wp_redirect if you want to redirect it somewhere else: https://codex.wordpress.org/Function_Reference/wp_redirect You might have to play with it to redirect to the right place. You also might want to hook it to a different action, but this will hopefully get you closer. I’m still learning this stuff.

In all honestly, I wouldn’t recommend disabling email verification. In fact – you actually should not only use that, but use it with Gravatar to double verify members. My BP communities are brand new, in dev stages right now. I’ve already been subjected to spammers which is why I support use of Gravatars – because not only will your users be verified in your community, but globally and this is a big step in spam prevention.

If you want to customize the registration page, many of them can be through your theme framework. However, too much code will slice your page & overall framework right down the middle and break your site.