XProfile: a group's first field becomes last after save

[SGr33n]

Hi,
Looks strange nobody yet reported this, I searched but nothing similar found, so sorry if it's a duplicate.
Anyway when you have multiple profile fields, if you update the "Name" field (the main field, the one with id 0 on the bp_xprofile_fields table) it will order automatically as last. I took a look at the DB and on the bp_xprofile_fields table the field_order becames e.g. 3 in a 3 fields configuration.

Thanks

[dontdream]

I've seen that happen with other profile fields too. After updating an existing profile field, *sometimes* I've seen it move to the last position in its field group.

I didn't submit a bug report because I wasn't able to consistently reproduce the issue, but now I confirm I can reproduce it editing the Name field (field_id=1).

[DJPaul]

Yep. Good report, I can recreate too.

[Offereins]

For a long time I've tolerated this bug, but the time has come to fix it. My first guess would be that the zero-based indexing of fields within the fieldgroup (this concerns all fieldgroups) is to blame. BP's logic would read that the field your editing has a falsey value for $field_order, thus BP considers it new and pushes it to the end of the field list. Will investigate further.

Edit: my guess was correct. Patch incoming.

[Offereins]

I've attached the smallest patch possible which fixes the bug described. Further sanitization of data types is needed in the saving of profile fields (and groups), but that's for later.

[boonebgorges]

I've noticed this too. The approach in 7428.01.patch​ seems sensible as a first step toward better sanitization.

[offereins]

In 11409:

XProfile: keep the field order value on save

Fixes a bug where the group's first field would be pushed to the bottom of
the field order stack on field save.

Fixes #7428