BuddyPress.org

hey Boone, you got me
Yes, the operative is the line which @boonebgeorges mentioned. But the file is itself more versatile than the default bp-register.php to allow you show all the profile field groups fields and so on.
Must check line 157 to 160.
But for sarah’s case, that is not required

that’s easy to do. I had posted a solution for showing all the fields from all the profile groups on a buddypress install which is here
http://bpdev.pastebin.com/RLreXE7X

You just need to modify the while loop, well, I have already modified it.
here you go
http://bpdev.pastebin.com/0GeJKXUj
Let me know if it works for you or not

Not bp_profile_fields; function bp_has_profile() does if that’s any use? It only takes user_id and profile_group_id.

Hey @scotm – That’s not the correct usage.

What I meant was copy the the template file I listed above in your child theme and remove everything in it.

Then use bp_profile_field_data(‘field=YOURFIELD’); to list only the xprofile fields you want to list (no need to use functions and remove actions here).

The other method is using a variation of this:
https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/faq-how-to-code-snippets-and-solutions/#post-13243

Same here!
I have installed it, copied the form to members/index.php
All it did was create a submit button + “by name” next to search
Wasn’t it supposed to add filters with my x-profile fields to filter the search?

This is a longstanding issue with WP/WPMU/BP. I’m not sure why in 3.0 the existing profile page wasn’t discontinued in favour of something that doesn’t require access to admin and that would be trumped if a BP install was present.

this hasn’t be fixed yet. Has the ticket been created?
Moreover what was bp_fields_has_data supposed to do originally? Because if it should check if the field exists, it seems straightforward to fix.

Sorry, no answers, just additional questions:
@katendarcy Which plug in do you recommend or use for facilitating the payments?

In the front end I would like to display custome fields of paid users only. Still I want all users to see all custom profile fields when setting up their profiles so they see what they are missing when they have a free membership.

designodyssey: I found that role scoper helps to shape the user types and their capabilities. So the user role should be the key. In future there might be two or more categories of paid users.
I see there are a few more of you working on this, so any hints are appreciated.

See this thread: https://buddypress.org/community/groups/creating-extending/forum/topic/privacy-component-where-is-it/

Can anyone help?

We desperately need :

– Privacy Features

– Advanced Search & X-Profile Fields

– User-Blogs-Posts from Front-end

When will that be?

Download this plugin and check out the code: https://wordpress.org/extend/plugins/custom-profile-filters-for-buddypress/ It will show you the basic method I used to modify specific xprofile fields. Short version: you can filter the output of xprofile fields in general, and then you use a conditional to detect the name of the profile field that you want. Not enormously elegant, but hopefully that code will get you part of the way there.

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

WP, WPMU and BP each have their own member admin areas, both frontend and backend, and data tables in MySQL, some of them synced, most not. Member management is an afterthought for Automattic. Hopefully it will be fixed in 3.0.

If you mean the User entered data, it is available on their profile not inside the wp-admin. You will need to visit their profile to see the data.

@Andy Peatling, so version 1.2 does sync separate firstname and lastname from the xprofile field to the fields in wp_usermeta?

I will upgrade when WP 3.0 is out, probably this Summer when my day job work is slow. I have a custom theme. It will be a complicated operation.

nice one. would be good to admin what profile fields should be made available to user. I have long list of fields that only get used as custom fields for other purposes than regular display. but yea some changes on backend don’t update on front, specifically the V/H Layout option didn’t work by setting it in admin, only when i set to allow user to decide layout does it update on hitting update badge. btw what’s the best way to overwrite the default logo image. thanks.

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.

I worked nonstop this weekend to finish up our own advanced importer we started a few months back. Allows you to do a full import of a Ning network’s users, their custom profile fields, and avatars to BuddyPress! It reallywas a bit of work to scrape avatars from the profile pages but looks real cool while importing. Full support for very large member lists via optional FTP upload and batch processing so it won’t timeout on you.

http://premium.wpmudev.org/project/ning-to-buddypress-user-importer