BuddyPress.org

If BuddyPress is activated sitewide, I guess BuddyPress should prevent access to any non-root site’s registration page. If it doesn’t, please would you make a ticket on http://buddypress.trac.wordpress.org so we can get it looked at in a future release. Thanks

@christophg Sorry for the delay in getting the registration/profile idea to you. Here is what I do:

I use S2member to keep my customers and brands separate. I then created a new profile group called “Company Profile”. I made this the last profile group. I then added the following code to the file:
members/single/profile/edit.php

`
<?php if (S2MEMBER_CURRENT_USER_ACCESS_LEVEL

ul.menu li:last-child{display:none;}
.company-profile{display:none;}

`

The above code hides the profile group on the edit menu from users below level 2, my brand level. And it also hides the profile group edit fields from anyone below level two. In case the menu item shows for some reason. And, unfortunately, this will not hide the menu item from users in IE 8 and below. But it WILL hide the profile group from them.

I tried using jquery to affect last-child in IE. Although I can get the jq to work on a test page on IE, it won’t work on the menu item… not sure why.

Next, my brands all belong to a private group, and I use a group conditional script to show the brands profile info front and center on their profile page with custom styling. This allows the brand members only to have a slick looking page that is different from regular consumer pages.

`

`

Let me know if you need anything else. Or if something doesn’t make sense.

Read here:
https://buddypress.org/community/groups/miscellaneous/forum/topic/buddypress-registration-as-homepage/

Hi Andrea_r: Can you kindly share the fix you did? I’m encountering the same error. Much appreciated!

hi,

i want to do the same.
also it would be very nice to know, how to deactivate all the menu for visitors who are not members.
i don´t want non members to be able to see who is member or what is going on in my social network.

greetings from germany
paul

Still pondering with this. Would you have a little plugin, or a simpler solution for this please? I do not seem to fully understand and adopt the above solution

Thank you so much;

Tried some more tests. The pattern I seem to be seeing for repeated uploads during the registration process is that when a user replaces their avatar, the change is displayed a few times. After 2 or 3 it stops displaying new ones added. Not sure if this is a feature or bug or has to do with the order in which the avatars are listed in the registrations temporary avatar directory.

Me again.

I would like to edit the above posts, but this forum is not allowing me to do so. Clicking “Edit” gets me to “page not found.”

Anyway. I take back that it’s necessary to add a hidden field.

I think the change that is needed is
the last line in the function
bp_get_signup_avatar_dir_value()
in bp-core-templatetags.php

change
return apply_filters( ‘bp_get_signup_avatar_dir_value’, $bp->signup->avatar_dir );
to
return apply_filters( ‘bp_get_signup_avatar_dir_value’, $signup_avatar_dir );

However, I note that if the registrant uploads more than one avatar (i.e. replaces their avatar) during the registration process the avatar displayed will be the first one uploaded.

Look at the function bp_core_fetch_avatar() in bp-core-avatars.php

This is called in the function bp_get_signup_avatar in bp-core-templatetags.php.

The problem is that if the user uploads more than one avatar the old ones are not deleted.

bp_core_fetch_avatar() seems to get the first on uploaded and this is the one that is displayed when the register.php template runs even if newer avatars have been uploaded during the registration process.

Another relevant files is

bp-core/bp-core-signup.php

Looking at it, I am not sure my solution would be the final correct one. So far it’s working, but some of the functions in bp-core-signup seem like they would have an impact.

Hi folks

I think I may have found a solution, at least to how I was experiencing it.

I am using wp 3.2.1. and BP 1.2.9 with a bp-default child theme

FIRST the default gravatar image was not showing at all in firefox. I don’t use gravatars on my site and filter them out all together. I applied a filter to
bp_get_signup_avatar
to replace the gravatar.com image with a link to mysteryman directly on my site.

SECOND

I think the function

bp_get_signup_avatar_dir_value() in bp-core-templatetags.php

has a bug.

The last line applies the filter.

However, when the user signups up or uploads an avatar $bp->signup->avatar_dir seems to be empty.

There are a few if then else statements that work with $signup_avatar_dir so this seems to be the relevant value to pass along. I changed the last line in the function code to

THIRD

I found that register.php in the theme is lacking a hidden field for the signup avatar directory

The relevant section is: (REF section A)

You’ll notice that the section just below this that handles what the user sees when cropping has an additional hidden field.

I inserted this in the (Section A) that the user sees before and after cropping

@n_sane I had the same issue. A quick check of the wp database showed new users were being created with user level 2, which, in this case, means that they have not confirmed their registration. Also I realized i had not received any of my dummy account registration conf. emails.

I found a workaround for this by changing the user status to 0 in the wp_core_startup file, but that was an inadvisable way of fixing the issue since it totally deactivated the email registration system, which i really don’t didn’t want to bypass, and that file will get overwritten in any bp update.

The fix was to install the ‘Mail From’ plugin by andrew hamilton. this apparently allows the registration emails to go out, and then user_status and registration can be handled the way it was designed to. I’m hosted with bluehost and have a hunch their mail system isn’t playing nice with bp and this plugin seems to allow it to do that.

hello after registration you must active your account
to active you will get an email with active link

Best regards
dajin

“well, I think I will really back to my phobia of plugins! this plugin just ripped me of 20 $ of google adwords advertising my website, and it caused any user who tried to sign up with creating blog in registration to tell them please check your activation e-mail! (theopposite of what it should do!) and this time it’s not sending e-mails at all even after long time because the plugin did it’s job at this side only!”

I actually tested this plugin last week – it worked for me and did none of the things you mentioned.

if you go to yoursite.com/register/ you should see it. if not, your registrations are OFF.

Did you turn on registrations? Under Settings in the admin area.

As I wrote, I found several bugs running wp 3.2.1 & BP 1.2.8, so before keep it on BP1.2.8, check your WP system.

In my installation a lot of ajax was broken (ie: new post->Publish->change publishing date descending effect) so I’ve re-installed BP1.2.9 and I’m searching for a solution.

Ok. It’s definitely BP 1.2.9 causing the avatar upload at registration.

I downgraded to 1.2.8 and it works. Not sure what I will be missing, not upgrading to 1.2.9. But for now, keeping 1.2.8!

You may need to copy over some files from bp-default theme to your theme to make things fully work properly. From trunk you probably want to copy over:

buddypress/bp-themes/bp-default/activity
buddypress/bp-themes/bp-default/blogs
buddypress/bp-themes/bp-default/forums
buddypress/bp-themes/bp-default/groups
buddypress/bp-themes/bp-default/members
buddypress/bp-themes/bp-default/registration

all to your theme folder

Thank you so much guys for solutions.

1) How can I downgrade to BP 1.2.8?

2) And would that be OK? Won’t we miss on some other improvements in BP 1.2.9?

Thank you so much for your response.

Vida

well…but I’ve found several bugs using wp 3.2.1 & BP 1.2.8, so I’ve upgraded to 1.2.9 and the problem (no avatar upload in registration) still here.

So, a quick overview:

wp 3.2.1 + BP 1.2.8 = it works
wp 3.2.1 + BP 1.2.9 = not working

so…not a problem about folder permission…

wow, just tested: downgrading from bp 1.2.9 to bp 1.2.8…. it works!