Could not update

@majecdad I presume this is after deactivating and then reactivating?

You’ll need to look at your database and determine the IDs of the fields that held your “first name” and “last name” data was before deactivation, because – for some reason – the plugin cannot determine what they were. Hence the ‘SET id = 0’ in the SQL. Then, have a look at your options table and find ‘bp_xp_wp_sync_options_store’ – you’ll have to enter the correct IDs into that option’s serialised array, which is a bit of a pain, but do-able.

If that all sounds too complex and you don’t have large amounts of “first name” and “last name” data, I’d try deactivating and deleting the plugin, then reinstalling and re-entering the data.

Sorry that this is a PITA, but there’s no way to “deactivate” xProfile fields and the plugin’s recovery routines were the best I could do.

Hi @christian,

Thanks for your timely reply. OK, so swimming in the deep end for me, but here goes ??

Found the ID’s, they were First 37 and Last 38.

Then I found ‘bp_xp_wp_sync_options’ (but not …_store ?), and in it was Option Value:

a:2:{s:19:”first_name_field_id”;s:2:”37″;s:18:”last_name_field_id”;s:2:”38″;}

which seems to say that it already has the correct ID’s?

The plugin is currently deactivated, as it won’t activate, throwing that fatal error.

Thanks for any additional guidance.

Okay, what you’ve found are the *new* IDs of the “first name” and “last name” fields. Unfortunately, these don’t help you.

What you need to find are the *old* values that you want to reconnect the new fields to – for which you’ll have to look in the “wp_bp_xprofile_data” table. Find an example “first name” and and example “last name” and note their “field_id” values. These are the old values you’re after.

Now, look in the “wp_bp_xprofile_fields” table and delete rows for the “first name” and “last name” fields. The plugin will recreate them (or try to) when it is reactivated. But in order for it to reconnect these newly created fields with the existing data, you’ll need to add an option to the “wp_options” table. The “option_name” should be “bp_xp_wp_sync_options_store” and the value should look like:

a:2:{s:19:”first_name_field_id”;s:2:”XX”;s:18:”last_name_field_id”;s:2:”YY”;}

Replace “XX” and “YY” with the values you found in the “wp_bp_xprofile_data” table. Be careful, however, because if these are single digits you’ll need to edit the data above so that it reads s:1:”X” and s:1:”Y” – this means “here’s a string (s) of length 1 with the value X. You get the idea.

Then go ahead and reactivate the plugin. If all goes well, you should have two new fields in the “wp_bp_xprofile_fields” table with IDs that match the corresponding entries in the “wp_bp_xprofile_data” table.

Let me know how it goes!

This has been interesting…

So in “wp_bp_xprofile_data” there are no other field id’s except “1” which looks to be structured as “first_name last_name” (NOT username or nickname).

I also deleted all of the First Name Last Name instances in “wp_bp_xprofile_fields” (there were about 15 of each).

After doing that, I tried to reactivate the plugin, and got the fatal error again. Interestingly, back in “wp_bp_xprofile_fields” 5 more of each First Name and Last Name were created. (Haste makes waste, I should listen better.)

This time, I deleted all but one of each, and modified the id’s to equal those which I pulled from wpusermeta.

Then I went and *added* that “bp_xp_wp_sync_options_store” (I had misread that the first couple times I read this).

Again, I errored in that the plugin could not sync these fields because they already existed (so I went back in again and deleted all of the f_n l_n instances). (Note: I should really listen better, deja vu.)

Voila, it worked. I was sweating bb’s the entire time – and this was on a clone dev db. I can not even imagine doing this on our real live site. haha.

One final note, after this entire process, we only had two users listed as ‘members’ in BP (there were about 35 ‘users’ on the dev site). Since this is a dev clone, I don’t even recall for absolute certain that those others were members before this issue started. I’m *pretty sure* they were, but wouldn’t swear on it.

In each case, once I logged in as a specific user, they then became added as a member. Is this a known issue?

It’s unfortunate that the deactivation of the plugin creates all these steps, but I understand it’s one of those things that comes with the territory.

Thanks again for all your help with this, it’s been interesting.

Thanks for the extensive feedback. I’m sorry that the process has been so complex.

So in “wp_bp_xprofile_data” there are no other field id’s except “1” which looks to be structured as “first_name last_name” (NOT username or nickname)

So, that presumably means you had no “first name” and “last name” data… BuddyPress itself is responsible for the “field_1” data and, in the absence of any other input, will sync WordPress “first_name” and “last_name” fields to that field in the way you describe. It’s that field that this plugin hides and replaces with separate fields.

If you had no data for this plugin’s fields, then my initial suggestion would have been quickest – i.e. to delete the plugin and reinstall.

I tried to reactivate the plugin, and got the fatal error again. Interestingly, back in “wp_bp_xprofile_fields” 5 more of each First Name and Last Name were created.

How odd. It should only create one pair of fields per activation. Are there any other plugins that might be interfering?

This time, I deleted all but one of each, and modified the id’s to equal those which I pulled from wpusermeta.

The “wpusermeta” table? Are you sure? I presume you mean “wp_bp_xprofile_data”?

In each case, once I logged in as a specific user, they then became added as a member. Is this a known issue?

Yes. BuddyPress only shows members who have logged in at least once.

When you come to doing this on the live DB, I’d suggest doing it on a clone as you have done already, then replacing the live DB with the modified one. Take a backup of live before you do, of course!

@majecdad I think your upgrade errors may be solved with the latest version. As usual, however, it’s best to simply replace the plugin files rather than update via the WordPress update process.