[buddypress-trac] [BuddyPress] #3127: Switch to WP_User_Query for BP_Core_User

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Fri Sep 23 04:39:11 UTC 2011


#3127: Switch to WP_User_Query for BP_Core_User
--------------------------------------+-----------------------------
 Reporter:  cnorris23                 |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Future Release
Component:  Core                      |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  dev-feedback 2nd-opinion  |
--------------------------------------+-----------------------------

Comment (by joevansteen):

 If this is going to be opened for discussion I would advance the logic
 proposed in #3335 and in my blog post
 (http://architectedfutures.info/2011/08/23/bp-wp-profile-sync/). I don't
 see the logic for having 2 user profile facilities in BP, one from WP and
 one from BP. If BP has a separate standalone implementation without WP,
 then it makes sense; otherwise not.

 WP is the base system, and WP should provide the user profile. BP's
 profile happens to be better, richer and more sophisticated. But the
 profile facility should be a feature of WP. I'm new here and learning the
 scene, but aren't these two systems related and interdependent? Is there a
 joint planning forum or body? If the BP profile facilities were moved into
 WP, WP would be a better system with a richer profile, hierarchical
 fields, better edits, etc. BP would be closer integrated and no longer
 responsible for the profile proper. WP profile add-on modules and features
 would apply to BP "users" without the add-on needing to be specifically
 aware of BP special tables and rules. (Is that good or bad? I don't know.)
 Obviously, the "social" network integration of the user into groups, etc
 would remain BP. Features like profile security would be done as WP and
 apply to both sides. (Hypothetically that would open a wider audience and
 more opportunity for contributors for enhancements and maintenance at the
 same time.)

 I've seen some comments about the need not to interfere with the WP side
 of the system and questions about what happens when someone pulls the BP
 feature off of their site, but I think these arguments are moot. The user
 that decides to put a BP add-on on to a WP system made the choice to
 integrate. I think the desire for integration speaks for itself. By
 pulling BP off they can't automatically distinguish users who were BP from
 WP anyway. They are all one set of users, the users of the site. It's the
 attributes that are BP, not the users. If anyone wanted to get rid of the
 rich profile data at that point, they could just delete the fields, just
 as they would if BP were still active.

 This may not be the way people want to go, but I thought I'd give it a
 shot. Maybe some other folks will comment. In terms of people not
 demanding this earlier, which was another comment I heard, I think people
 by and large are just glad to have the BP feature set and ignore the
 conflict by focusing on the BP side. I think the system as a whole though
 would make more sense and there would be a lot of advantage to having a
 single user profile facility and having it based in the WP part of the
 system.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3127#comment:4>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list