"Settings > Profile" hidden field doesn't list all field IDs

[r-a-y]

If you're on your "Settings > Profile" Page, we output a hidden field to keep track of the number of xprofile field IDs that are rendered:

<input type="hidden" name="field_ids" id="field_ids" value="<?php bp_the_profile_group_field_ids(); ?>" />

The problem with this is bp_the_profile_group_field_ids() only recognizes the last profile group loop and not all profile groups.

Case-in-point, when there is more than one xprofile group, only the fields from the last xprofile group are listed in the hidden field. This means that a user is unable to set the visibility for any field in the first profile field group.

---

To fix this, I wanted to get rid of the bp_the_profile_group_field_ids() function when rendering the hidden field, but that might lead to backpat issues for themes that are already using this template.

So the attached patch:

• Adds a filter to bp_get_the_profile_group_field_ids()
• Records all the field IDs when on a user's "Settings > Profile" page using the new bp_xprofile_settings_record_all_group_field_ids() function
• Overrides the bp_get_the_profile_group_field_ids() value with the recorded value

If there is going to be an interim 2.0.2 release, this should also be part of that.

Let me know what you think.

[DJPaul]

Storing data in the global at different parts of the loop like this seems a bit overcomplicated. Did you consider your idea to re-work it by removing bp_the_profile_group_field_ids(), but leave it in/look for it's data in the POST submission as a backwards compatibility fix?

[r-a-y]

but leave it in/look for it's data in the POST submission as a backwards compatibility fix?

That's possible, but I prefer my technique because it's simpler. I'm happy to be overruled by a majority though :)

[DJPaul]

This needs more dev-feedback from another core dev, please.

[boonebgorges]

r-a-y, your suggested solution is clever, but I'm with Paul that it seems a bit overengineered for our edge case. I'd rather put a real fix in place for the problem (which is that bp_the_profile_group_field_ids() is the incorrect function to use here) and then build a backward compatibility layer on top of the fix, rather than leaving the broken status quo in place and then engineering a layer on top to fix it. (Does that make sense?)

Anyway, 5666.02.patch is my suggested solution. Basically, don't use bp_the_profile_group_field_ids() anymore. Use bp_the_profile_field_ids() instead, which gets all field IDs available in the $profile_template loop. r-a-y, as you note, there is backward compatibility issue with sites that have overridden the template; I've chosen to fix that in a very direct way, inside of bp_xprofile_action_settings(). The backpat fix is a bit ugly, but I'd rather have the ugliness relegated to the backpat fix and keep the rest of the logic as elegant as possible. What do you think?

[r-a-y]

Works for me!

[boonebgorges]

In 8819:

Introduce bp_the_profile_field_ids(), and use as appropriate throughout BP

The POST routine run when editing one's xprofile-powered profile (or
registering for an account when the registration form includes xprofile fields)
works in part by sending a list of field IDs in the 'field_ids' <input> element.
These field IDs are then used to decide which POST keys to look for when saving
submitted profile values. Historically, the function powering this field_ids
element has been bp_the_profile_group_field_ids(), which pulls up only the
field IDs from a single field group. Normally this works fine, because the
typical Profile > Edit screen only allows for the editing of a single field
group at a time. However, the introduction in BP 2.0 of Settings > Profile
demonstrates that this technique breaks when attempting to save more than one
field group at a time.

The new bp_the_profile_field_ids() replaces this logic by pulling up all the
field_ids from all the groups in the $profile_template global object.

In order to provide for backward compatibility with themes that may have
overridden the modified templates (in particular, members/single/settings/profile.php),
we add logic to the Settings > Profile save routine that looks for any
submitted profile fields that are not present in the field_ids array.

Fixes #5666

Props boonebgorges, r-a-y

[DJPaul]

Nice fix. Good job team. :)