XProfile name field created through multiple triggers

[Rourke]

Every time I either disable Advanced Profiles in the BuddyPress settings, or disable BuddyPress entirely, then re-enable it, BuddyPress creates another Name (Primary) (Required) field. This happens with or without BuddyPress being the only plugin.

There seem to be more triggers because I had a situation where I haven't disabled or updated BuddyPress and I discovered another 3 Name fields have been created in 1,5 week.

This is extremely problematic because this can disable (external) registration pages silently.

[DJPaul]

I can't reproduce this on BP trunk with some pre-WP 4.4-beta1 trunk.

[boonebgorges]

The problem would presumably be in bp_core_install_extended_profiles(), in src/bp-core/admin/bp-core-admin-schema.php. At the end of that function, BP creates field group 1 and field 1 if none are found. So the existing field check(s) must be failing in your case. They look like this:

$wpdb->get_var( "SELECT id FROM {$bp_prefix}bp_xprofile_fields WHERE id = 1" )

It's a bit odd that we hardcode the id of 1 here, but it's worth noting that throughout BuddyPress we assume that the Name field has the ID of 1. So if you deleted your Name field and then recreated it (with a new ID, due to auto-increment), lots of stuff in BP would likely break, not just this.

Rourke, are you able to do some debugging around this? Is it possible that something on your installation - a plugin, etc - is causing the Name field to be deleted when you deactivate xprofile? What is the id of the Name field in your wp_bp_xprofile_fields database table? If it's not 1, how did it get to be something other than 1? :)

[Rourke]

@boonebgorges You seem to be spot on.

My profile fields had id 2 and up. Just changing my id 2 field to id 1 solved the problem.

At one point I think me or another administrator added a new field, and decided the default Name field wasn't necessary anymore. We couldn't delete the Name field from wp-admin so we changed can_delete to 1 and deleted it from wp-admin anyway.

So honestly I think I was the problem, not some plugin. Apologies for the inconvenience. Lesson learned: should never tinker in the database unless you know 100% what you're doing. ;)

[boonebgorges]

Thanks for checking back in, Rourke.

I would like for BuddyPress to be more discriminating about this, but our hands are kinda tied. On the one hand, we could keep track of which field is the 'name' field - something we used to do, via the xprofile_name_field_id option (or something like that) - but this creates problems with syncing and performance. We hardcode the 1 as a way of ensuring consistency, and we try to enforce this by setting can_delete to 0 on that field, but obviously there are workarounds :) Given that we already attempt to enforce the deletability, and given that we don't have any other great solutions on hand, I'm going to close the ticket.

[r-a-y]

Related #7109.