Skip to:
Content

BuddyPress.org

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#5666 closed defect (bug) (fixed)

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

Reported by: r-a-y Owned by: boonebgorges
Milestone: 2.1 Priority: normal
Severity: normal Version: 2.0
Component: Extended Profile Keywords: dev-feedback has-patch commit
Cc:

Description

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.

Attachments (2)

5666.01.patch (2.7 KB) - added by r-a-y 5 years ago.
5666.02.patch (3.6 KB) - added by boonebgorges 5 years ago.

Download all attachments as: .zip

Change History (10)

@r-a-y
5 years ago

#1 @DJPaul
5 years ago

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?

#2 @DJPaul
5 years ago

  • Keywords needs-patch added; has-patch removed

#3 @r-a-y
5 years ago

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 :)

#4 @DJPaul
5 years ago

  • Keywords dev-feedback added

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

#5 @boonebgorges
5 years ago

  • Keywords has-patch added; needs-patch removed

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?

#6 @r-a-y
5 years ago

  • Keywords commit added

Works for me!

#7 @boonebgorges
5 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

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

#8 @DJPaul
5 years ago

Nice fix. Good job team. :)

Note: See TracTickets for help on using tickets.