WordPress-BuddyPress User Profile Implementation
Given the conceptual framework described above, the next thing is to look at how that framework is implemented within both WP and BP. Figure 2, below, provides another information model. This time we are looking at a model of the database tables used by WP and BP to maintain User and User Profile information. This is where the rubber meets the road.
The three tables at the top of the diagram (bp_xprofile_data, bp_xprofile_fields and bp_xprofile_groups) are the implementation of the BuddyPress Profile Features entity described in the conceptual model in Figure 1. The three tables in the lower portion of the model (users, usermeta and options) implement the WP portions of the conceptual model. (A detailed description of the WP database tables can be found here.)
WP Users Table
Let’s start with the WP tables. The users table is obviously the core of our information set and it is the key (only?) point of real overlap in the core portion of both WP and BP. It associates a user’s ‘log in’ ID with the internal numeric ID that is the key to all user functionality in the system, and it performs this function for both WP and BP. This is where the ‘join’ happens and it cannot be avoided. As it happens this table also identifies a series of other user profile attributes:
- an encrypted user password
- user ‘nicename’
- user display name
- the date/time the user was originally registered
- the user’s email address
- the user’s status
- a user activation key
- the URL of the user’s profile page
WP Usermeta Table
The usermeta table is where all the other data attributes that make up a WP User Profile are stored. Each entry in the table consists of 4 fields:
- A unique ID number that serves as the key for the attribute within the table.
- The user ID of the user that the attribute is associated with.
- A name for the attribute (e.g., first_name, last_name, nickname, description, etc.).
- A value field defining the content or ‘value’ for the attribute (e.g., ‘Joe’).
WP OPTIONS TABLE
The options table is a utility workhorse within the system. In effect it is a keyed storage system to store away and retrieve all kinds of miscellaneous data. Blocks of information are given an identity by use of a key name and then stored and retrieved using that key. One of these blocks is keyed with the ‘user_roles‘ tag name. That information block defines all Roles identified in the system and it identifies all Capabilities assigned to each Role.
BP xprofile groups
The bp_xprofile_groups table is very straight forward. Each data field in a user’s profile is assigned to a group. This table defines those groups and gives them labels for display purposes. This data grouping ability is not provided by the WP user profile facilities.
BP xprofile fields
The bp_xprofile_fields table is another enhancement over the native WP profile facilities. This is where BP shows its sophistication and concern for quality management of user profile data. User profile fields defined to the BP profile management facilities are described in this table. Each field has the following characteristics:
- A unique identifier
- A group assignment (pointing to a group in the bp_xprofile_groups table)
- A potential parent field identifier for associating fields in hierarchies
- A field type designation
- A display name for use on forms
- A description for use as help text
- A field order designation for managing display sequence on forms
- A designation as to whether the field is required or optional
BP xprofile data
The bp_xprofile_data table is the intersection map between users and fields. For each user this table contains an entry making each field’s data assignment. Each table row contains:
- An identifier for the row
- A field ID (pointer to the field in the bp_xprofile_fields table)
- A user ID (pointer to the user in the WP users table)
- A value assignment for field for that user.
- A timestamp for the date and time the value assignment was last changed.
Pingback: Drupal-WordPress Evaluation, Part 1 | Building Architected Futures™
Pingback: BuddyPress – Your Own Social Network
Still none the wiser… this is a real pain! Has anyone any more info to share?
Thanks for the comment. I’m not sure how much is being done on this. I’d suggest tracking through the BP ticket system, including the ticket I identified on the last page of this article.
Sorry, I realise my comment sounded very negative, especially in light of the fact that your article is the best explanation by far so far. I am wiser, thanks to you, but I suppose frustrated that these (basic) things ‘get in the way’ of setting up a working system. As a fan of BuddyPress who has spent many, many hours putting sites together and convincing users they will have a great system working for little outlay, I keep tripping up over ‘simple’ things like this. Can’t help feeling BuddyPress will be steamrollered by something else within a short while and that will be that. But I digress.
Hello,
Just come across this and looking at doing the same for a site I’m working on, wondering if this ever got resolved? Thanks
Hi Andy.
I haven’t really followed what’s happening on this for a while now. What I do know is that I am still getting a steady trickle of interest, people reviewing this issue, on an ongoing basis. So my impression would be that the general issue remains.
For myself, the issue came up as a function of trying to decide whether or not to use WP or Drupal as the basis for another site I was building. The handling of users and permissions was a factor that caused me to go with Drupal. I use WP for this blog, but this site doesn’t have the multi-party profile management issues so it’s not a problem here.
If you do find a solution, or create one, feel free to provide a link and reference it here as a further comment. As people continue to search through here to investigate the topic I would be pleased to point them through to a more updated discussion and resolution.
For the latest on this, please see https://buddypress.trac.wordpress.org/ticket/3335#comment:8.