BuddyPress.org

It becomes just string manipulation. Create a new function (my_funky_function) and do something like this:

function my_funky_function() {

echo str_replace( "username","", bp_get_the_profile_group_field_ids() );

}

Then replace the bp_the_profile_group_field_ids() call in edit.php (in your child theme of course) with my_funky_function().

I think that will work but it’s not tested.

Edit:

Oh, sorry, I’m sort of wrong. This is what I get in my edit.php form in the HTML:

<input type="hidden" name="field_ids" id="field_ids" value="1,3" />

Field_id 1 is the Username for me. You just need to filter that out so the str_replace call should be “1,” instead of “username”.

<input type="hidden" name="field_ids" id="field_ids" value="<?php bp_the_profile_group_field_ids() ?>" />

That line is your problem. Well, more specifically, the call to bp_the_profile_group_field_ids() which creates a list of the expected field names.

Unfortunately it doesn’t have a filter so you’d have to clone and own the function into your functions.php file and manually filter out the “username” field from the string that gets generated.

Make sense?

Oh, nope, it probably means that the code is actually checking that the field ‘username’ should be getting updated. I was sort of wondering if that would happen.

So I tried to explain this to my father…who can barely use email.

Pretend you’re in a room with 1,000 people that you don’t know. Now, you might end up making friends with 10 of them, and doing business with 2. The problem is that it would take you a week of shaking hands and starting conversations to find those connections.

Social Networks/Communities…like Buddypress/Facebook/LinkedIn etc. turn that week into 10 minutes.

To me, improved community-wide searching and easy navigation by profile fields (can someone please load in locations?) are the most important areas where BP is clunky and needs improvement. We need to focus on turning that 10-minutes into 5, while being ever-more-user-friendly and intuitive in the process.

The trend is that all of these networks will share information with one another, so much so that, in time, walls will be torn down and eventually, “Social Networks” will be a big mosh of everything…made up of smaller topic-focused communities like each of ours.

BP gives each of us a chance to create a niche within this great mosh. We shouldn’t try to BE the mosh, but simply be the most efficient and user-friendly communities within it.

open bp-themes/bp-default/members/members-loop.php

instructions for what you need are line 42

This is now officially a “Potential Future BuddyPress Feature” for BP 1.4+ (ie, after BP 1.3, which looks to be essentially the WP 3.0 compatibility release). Here is the short list:

A quick blog post form via the theme. (try plugin: BuddyPress QuickPress)

Privacy controls (try plugin: bp-authz)

Global content tagging

Inappropriate content flagging

Bulk accept/reject friendship requests

Grouping of similar activity stream items

Ability to block all communication from a user

Option to receive forum post notifications via email

Message file attachments

Structured profile fields (templates for address / phone number)

Profile field specific searching (try plugin: BP Member Filter)

AJAX live updating of site wide activity stream

Well, yes, you should be able to make the username field non-editable. I would assume the username field is a “textbox” type. In edit.php, you should be able to just filter out the username field and not create a form “textbox” HTML element. So, in member/single/profile/edit.php around line 21, add in a check something like:

<?php if ( 'username' == bp_get_the_profile_field_name() ) : ?>

// Just display the Username with bp_the_profile_field_name() and add HTML to style how you want.

<?php else : ?>

// Do the existing <label... code on line 23 and 24

<?php endif; ?>

Now, a creative user might still be able to circumvent your little hack and submit their change directly to the form. I see a nonce being used though in the form so that might not be too much of a concern after all.

Great thread, Mr Maz.

For my part, I am very very leery of the phrase of the moment, ‘social networking’. It’s a buzzphrase, and even when it’s used specifically and accurately, it makes me want to punch throats, a little bit, because it doesn’t mean much when you dig right into it, and to me, it evokes cheesy cheap-suited salesman making currency of faux friendship.

But I’m kinda old skool that way.

For those of us — most, probably — who’ve been working or at least dabbling in the data for decades, we’ve seen dozens of bandwagons boarded and polluted and just as quickly disembarked and abandoned when the next thing came along. The avalanche of ‘social networking gurus’ and all the rest will fade in time, too.

For me, the real thing at the highest handwavy level is ‘community’ and more specifically, community on the web. Tools and toolsets and platforms and apps and APIs and all the loosely- and tightly-coupled stuff that enables people who share some set of interests, no matter how specific or broad, to get together and interact and form communities, with all the real-world parallels but also all the special because-it’s-on-the-internet factors rolled in.

This means a couple of things, and again, talking at a much higher level than the technical here — it means that the platform itself disappears for the user after they become accustomed to it. That it’s designed in terms of interface and functionality to not only provide the features users want, even if they don’t know it, but also to be as invisible as possible as they use it.

It also means that the platform has to have a robust set of tools for the administrator and moderators of the community (because these things are necessary, to some extent, in community on the web) to use a light hand in keeping the community on an even keel.

I think web community, more perhaps for people who are not so much of the disposable, in-the-moment, ritalin-riddled, post-it-and-forget it generation, needs to have feet solidly planted in not only the ongoing ephemeral stream of conversation, but also in a more long-term, permanent ‘space’ of shared history, shared interactions that are performed in public and can be gone back to, interactions that more than any set of xprofile fields or avatars build a mutual understanding between users based on personality and past discussion. Build, in other words, community.

This last is why I keep mentioning how important I believe the forum component of Buddypress to be, and why I’ve spent the bulk of my time on my current not-yet-launched BP site for an existing community trying to beef it up (with the help of some of the excellent plugins that people have been releasing).

‘Social networking’ doesn’t excite me. Communities of people from all over the place, communities that can only exist because they are on the internet, that’s what excites me. Buddypress, to me, is a toolset for building communities on the web. It may be a distinction without a difference for many, but I think it’s an important one.

OK, enough handwaving.

So, yes, by default, the register page only shows group 1 (the “base” group). You only retrieve one group via the profile_group_id= parameter in the bp_has_profile() call.

So, by default, this happens:

What I’m trying to accomplish is to hide groups 3 and 4 on the registration page not to overwhelm the user with a bunch of fields to fill out during sign-up, those fields can be filled out once the user has activated her/his account via “edit profile”.

There have been other threads on the forum regarding showing more than one profile group on the registration page; I found several, but take a look at https://buddypress.org/forums/topic/all-fields-for-registration. It’s probably going to be really difficult to implement unless you have a decent understanding of PHP.

Nope, I don’t think so. I was thinking you could remove the ‘profile_group_id=1’ arg from bp_has_profile but that doesn’t seem to allow the registration page to show more groups. I guess it appears that the only “required” fields for registration are the required ones in the Base group.

Might be worth opening a ticket on this one to see if that is the expect behaviour. Alternatively, ping R-a-y or DJPaul and see if they know.

No worries. The code I gave should display everything except group 3 & 4. Sorry, I think I said it backwards in the previous post.

That said, even without the code, I’m only getting group 1 showing up on the registration page so I’m not really sure what’s going on in register.php now.

Well, you should be able to create pretty much everything you need in your theme’s functions.php file.

First you need to decide at what point you want to populate the fields. Find a hook in the code to attach to by looking for do_action(‘some_action_hook_name’) calls. In your functions.php file, make a new function and call something like:

add_action('some_action_hook_name','my_nifty_auto_pop_function');

Then create your nifty_auto_pop_function that fills in the xprofile fields you want to populate.

Look in the bp-xprofile directory for all of the different files/functions to help fill in and read profile fields.

OK, now I’m scratching my head.

When I create a second group, even if I tag the fields in the second group as “required”, they don’t show up on the register page (the bp-default version). The second group only shows up on the user’s profile page where they can edit the fields. They are tagged as “required” but nothing seems to force the user to fill them out.

I’m confused now as to what you’re seeing and/or trying to do.