BuddyPress.org

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.