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.

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:

1. The actual fields being synchronized.
2. 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.