sync of profile between Wordpress and Buddypress

[worldfreenews]

I am not sure why Buddypress does not sync the full Wordpress profile but, it needs to. It is silly to have info in the Wordpress profile that is not available in the Buddypress profile on the same site.

Example: Wordpress default profile has a "Bio" section, Buddypress does not. I have to manually create a bio section then, copy and paste the bio...and all the while, it's the same user!

Please make it simple, all the fields in the Wordpress profile need to be available in Buddypress and vice-versa. ONE PROFILE FOR ONE USER, NOT TWO.

[cnorris23]

First, presenting your issue in the above manner isn't going to gain you much sympathy, and it certainly won't inspire anyone to work on a solution.

Second, this was done for a specific reason. That reason is to prevent BP profile data from hijacking WP profile data. Hence, the option "Disable BuddyPress to WordPress profile syncing?" option in the dashboard. I opened a ticket a while back that proposes moving xprofile data into the user_meta table, however, that doesn't mean they will be fully in sync (see point 1). For technical reasons, that ticket won't be addressed until at least BP 1.4.

Finally, if you're doing it manually, then you're doing it wrong. This can easily be done with a custom function or two. See xprofile_sync_bp_profile() and xprofile_sync_wp_profile() for more clues on how to get started.

[DJPaul]

cnorris23 makes good points.

And, taking the opposite view, why would I want BuddyPress to automatically create a biography field, or the other messenger services' contact details, when I install it? What then happens if I delete the biography field? The one in WordPress will still be there.

However, in a future 1.4 release, we're re-writing BuddyPress to use custom post types, so we'll be able to have a fresh look at ideas like this. Thanks for your feedback.

[johnjamesjacoby]

I think there's merit in the idea - it's dizzying to have different sets of fields that can't be seen or reached from one platform to the other.

Sadly, no time to freshen up this code/ui/ux in 1.3.

Bumping to 1.4 where it will all get a good once-over.

[joevansteen]

I've done some thinking and research on this and decided to write a post on my blog. I'm new here, so I don't know if I got everything right - probably not. But I spent some time on it and I think it might be helpful: ​http://architectedfutures.info/2011/08/23/bp-wp-profile-sync/. If I made any stupid statements that reflect badly or misinform, please add a comment or send me a note using the contact page so that I can correct them. As you can read in the blog post, I'm in favor of eliminating the synchronization problem through core processes.

[cnorris23]

Related #3127

[joevansteen]

@boonebgorges @cnorris23 I'm posting here rather than on #3127 based on Boone's comment on #3127 that this ticket was more appropriate. Regarding my comment about 2 profile facilities (WP+BP) I posted a reference to the #3335/#3127 discussion issue on a WP "custom user meta" forum. Any migration path for a single facility would make more sense to me for WP to provide the base first as BP continues its cleanup. They would expand/enhance/revamp their facility to provide a new base, then BP would migrate the BP facility to dependence on WP.

The response I got was not encouraging. Maybe it was me, or the way I presented it, but there doesn't seem to be any interest in WP to build a BP-like profile capability (field groups, select/field-set support, etc). Not how I would have gone, but that seems to be their choice - keep it out of core. See ​http://wordpress.org/extend/ideas/topic/custom-user-meta#post-20304 for the dialog.

I'm not sure I understand the architectural logic, but I just thought I'd pass on the reference to the dialog in terms of FYI follow-up; and then drop the matter.

[joevansteen]

One last thought in terms of the whole synchronization issue. My 2 cents given the above post:

What struck me in terms of design is that BP has a concept of "field number" (field ID) for each field in the xprofile data. This I thought was crucial. WP only has labels in usermeta, and the labels are made up by the site admin or the programmer. Some labels match from display label to usermeta key, some don't. (For example the 'bio' field mentioned in the text that opened this ticket is actually 'description' in the usermeta table.) When I looked at structuring a "synch" facility, to me that was a significant problem. Mapping "field ID" to a label in the other system is very squishy. What I was really looking for was the ability to map "field ID" to "field ID." That would have been a little more solid in my opinion.

As it stands now, my tendency as an admin/developer would be to solve this issue by avoiding all WP usermeta to the extent that I could and bypass the whole synchronization issue. Don't use the WP "bio" or any other user fields except those that are in the base users table, or those which WP demands - i.e., the ones BP already synchronizes by default. All other user profile data should be built in BP only using xprofile. If an external system synch is required, it would be against the BP xprofile. If I wanted user profile data to be displayed on a non-BP display (for example if I wanted a 'bio' field to show on a blog or WP page), I'd probably use a plugin on the WP side to extract it from xprofile rather than maintain it directly in WP.

IMHO, there is much higher data quality assurance when dealing with a single copy of data than when trying to do dynamic synchronization - especially with systems that don't support transaction logic against the multi-database updates that are required.

[boonebgorges]

My takeaway on the larger issue is that the ball is in WP's court. If they want to inherit some of BP's more advanced profile features, they are more than welcome to do so.

my tendency as an admin/developer would be to solve this issue by avoiding all WP usermeta to the extent that I could and bypass the whole synchronization issue.

Agreed 100%. That's all we can do for now.

For the more specific issue raised by the OP, the only practical solution I can think of off the top of my head is to provide an option to admins at the time of BP profile field creation that allows them to sync it with a given WP profile field. But even this will cause some confusion, as WP doesn't have an API for these profile fields, and thus there's no reliable way for us to know whether a plugin has added additional fields to WP's user profiles.

Punting this to Future Release, unless anyone can come up with a specific plan of attack or a patch.

[boonebgorges]

Rereading this thread, I've worn out my neck through vigorous nodding-in-agreement-with-two-years-ago-me ​https://buddypress.trac.wordpress.org/ticket/3335#comment:8. Given WP's lack of API for its profile fields, we can't even begin to talk about building a general sync mechanism. And a non-general one would be just as pointless, since WP's fields are so weird (ICQ?). The only ones that *might* make sense are First and Last Names, but that would be a specific use case, not really a general syncing platform like is being discussed here.

Closing this ticket as wontfix. If there are specific requests or suggestions, please feel free to open new, focused tickets with details.

[Collizo4sky]

We were able to solve this problem as a lot of our customers were demanding this feature. Basically, what our extension does is watch for changes in BuddyPress profile update and sync with WordPress and our front-end profile and edit profile form display. and vice versa.

See video demo ​https://www.youtube.com/watch?v=VWmGb2Yiwwc

Incase somebody needs this, you can get our extension here ​http://profilepress.net/downloads/buddypress-extended-profile-sync/