Initial Observations
After looking at the detail support for user profile data within WP and BP one observation seems to jump out at me:
Why aren’t the bp_xprofile_data table and the WP usermeta table the same table?
If there were only one table instead of two, the whole issue of data duplication and the need for synchronization would disappear. Conceptually they should be able to be collapsed. There are some technical issues, but they don’t seem insurmountable.
- User profile values in the BP table are keyed by field identifier number. Similar values in the usermeta table are keyed by a string value. That should not be a major issue (more in a minute).
- The BP table includes a last update timestamp. That should be a useful addition to the usermeta table.
- The usermeta table contains ‘hidden’ administrative attributes for the user. This is where the technical issue comes up, but it doesn’t seem to be monumental. These types of attributes could easily be assigned field types that define them for what they are. In fact, such labeling and assignment might make the administrative code within WP easier to maintain as the options grow over time.
A second observation that jumps out at me is this:
Why isn’t the complete BP profile management facility (as relates to the above discussion) adopted by WP as a WP core facility instead of a BP add-on?
I’ll leave the answer to that question alone for now. Perhaps it relates to the difference in perspective we talked about on page 2 of this post. I understand the desire to keep the WP core minimal, and BP is a very large volume of code. However, what we are talking about here is a very small part of BP being moved into WP core. Table wise it might only be one new table. (The bp_xprofile_groups table could also be consolidated into the xprofile_fields table which would be the one new table.) The synchronization issue would disappear and non-BP users of WP would have a very nice enhanced facility for maintaining high quality profiles for their bloggers. Opinions anyone?
What Does It Mean To Have Profile Synchronization?
Initially this is simple to answer. Both systems should have the same values for the same conceptual attributes of a user. But it goes further. Should both systems operate on identical sets of attributes as described above in a fully integrated system? Or, should a subset of shared attributes be maintained in a synchronized fashion and other attributes be associated with each separate system? How does that play out for addressing the needs of different communities, businesses, etc.To complicate the issue a little further – what if we introduce a third major subsystem on the WP base similar to BP. That system would also need to share the user object. Should that system share all user data and should both WP and BP share any unique attributes that the new system introduced? Not such a simple question. What if you want to share between two of the three systems but not share with the third? What if you added a fourth system?
Core Profile Synchronization
In the core code, profile synchronization is entirely a BuddyPress responsibility. WP is the foundation system. It is not responsible for tracking changes made by plugin modules. WP core code provides hooks and filters through the plugin API to allow plugin modules to track WP actions. It is the plugin’s responsibility to use those hooks to track WP and perform whatever action is desired.
In the discussion groups people looking to modify the profile synchronization rules implemented by BP are directed to wp-content/plugins/buddypress/bp-xprofile.php. In v1.5 this module has been eliminated and the relevant functions have been moved, slightly changed to wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-functions.php. There has been some fine tuning adjustments in terms of condition checks but the essential synchronization code has not been changed. An extract from the beta release of the new v1.5 code is shown below:
/** * Syncs Xprofile data to the standard built in WordPress profile data. * * @package BuddyPress Core */ function xprofile_sync_wp_profile( $user_id = 0 ) { global $bp, $wpdb; if ( !empty( $bp->site_options['bp-disable-profile-sync'] ) && (int)$bp->site_options['bp-disable-profile-sync'] ) return true; if ( empty( $user_id ) ) $user_id = $bp->loggedin_user->id; if ( empty( $user_id ) ) return false; $fullname = xprofile_get_field_data( bp_xprofile_fullname_field_name(), $user_id ); $space = strpos( $fullname, ' ' ); if ( false === $space ) { $firstname = $fullname; $lastname = ''; } else { $firstname = substr( $fullname, 0, $space ); $lastname = trim( substr( $fullname, $space, strlen( $fullname ) ) ); } update_user_meta( $user_id, 'nickname', $fullname ); update_user_meta( $user_id, 'first_name', $firstname ); update_user_meta( $user_id, 'last_name', $lastname ); $wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d", $fullname, $user_id ) ); } add_action( 'xprofile_updated_profile', 'xprofile_sync_wp_profile' ); add_action( 'bp_core_signup_user', 'xprofile_sync_wp_profile' ); /** * Syncs the standard built in WordPress profile data to XProfile. * * @since 1.2.4 * @package BuddyPress Core */ function xprofile_sync_bp_profile( &$errors, $update, &$user ) { global $bp; if ( ( !empty( $bp->site_options['bp-disable-profile-sync'] ) && (int)$bp->site_options['bp-disable-profile-sync'] ) || !$update || $errors->get_error_codes() ) return; xprofile_set_field_data( bp_xprofile_fullname_field_name(), $user->ID, $user->display_name ); } add_action( 'user_profile_update_errors', 'xprofile_sync_bp_profile', 10, 3 );
There are two major revelations here:
- The actual fields being synchronized.
- The action hooks which are being used as the trigger points for invoking the synchronization.
In the xprofile_sync_bp_profile function (at line 417 above) BP has hooked WP‘s user_profile_update_errors action hook and uses it to post any changes to the WP display name field to the BP profile.
In the xprofile_sync_wp_profile function (at line 379 above) BP has hooked two of its own action hooks (xprofile_updated_profile and bp_core_signup_user) and uses activity from either of them to parse data in the user fullname field to first and last names; and then to post the first, last and full names to the WP profile.
I don’t know if the code is ideal in terms of what it does. (Had the developer checked this with an example of someone that entered a middle name as part of their full name?) However, the code does provide insight into developing a strategy for accomplishing a customized approach to profile synchronization within the scope of the current systems. Knowing these hooks and how they are ‘hooked’ by the BP code provides the information needed to replace them and assume responsibility for the synchronization in a separate plugin. By using these same action hooks and emulating the framework of the BuddyPress code (in terms of when to synchronize and when not to synchronize) we can implement our own code to accomplish a more inclusive synchronization. And the synchronization code can be turned on and off using the same BuddyPress administrative option that is present today.
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.