[Greg]

[I’m on WPMU 2.7.1 and BP 1.0]

This is easiest to explain with an example. Let’s say I have a radio custom profile field with three options, A, B, and C. I set ‘C’ as the default in the admin Profile Field Setup page.

As expected, the first time a user sets this field it is set to ‘C’ by default before they change it to something else.

Let’s say they change it to ‘A’.

The next time they go to edit the field it defaults back to ‘C’, instead of remembering ‘A’.

This is really not the desired behavior. The global default set by the admin should only apply before the user has set the field. After that, the default should be the last option the user selected.

Rationale: with multiple radio fields, a user entering the edit page to change one of them is probably going to unwittingly change the others back to the global defaults.

Is this a known bug? Is it possible I’ve missed something during setup?

Thanks.

[Jeff Sayre]

This is not an issue in my BP 1.0 setup.

Are you sure that you hit the “Save changes” button to write the changes to the database? When editing a profile field, a user must save their changes. If they do not, then whatever value was recently stored in the DB is displayed–in this case the default radio button selection.

[Greg]

Jeff, yes, I hit save changes. I also checked to see that the changes were accepted by looking at my profile in a separate browser window.

After pressing “Save Changes” the default BP theme returns me to the edit page for that part of the profile, and the radio buttons there are set to my global defaults (not the options I just chose). If I browse away to my profile page without saving changes again, the correct (new) options are in place.

I have now tested this on a second (new) BP installation. One thing I found was that it didn’t affect the very first radio button custom field I created in the Base group. I do see the issue for every subsequent custom field I create (in the Base group or in a second field group that I added) though.

Jeff, have you tested this on your install with more than one radio button custom field?

[Jeff Sayre]

Rebootnow-

Since I had only one radio button field, which was located in my first field group, I did the following:

• I added a new radio button field to my second field group and tested. No issue.
• Then, thinking it could be an issue if two or more radio button field sets were in the same field group, I added a second radio button field set to the same group. No issue between all three radio button field sets.
• Then I created a new field group and added a fourth radio button field set. No issue. Each change I made showed up and remained properly set, whether just changing a single radio button field, or changing all four radio button fields.
• Finally, thinking maybe this could be an issue only within the first field group, I added a second radio button field to the first field group. I now had 5 radio button field sets. No issue. All five worked as expected. No issues within filed groups or between field groups.
• Since the first radio button field set in the first field group was set to “Required”, I reset it to “Not Required” to see if that would make a difference. No issue.
• I then set both radio button field sets in the first field group to “Required”. No issue.

So, I have tried numerous combinations and cannot recreate your problem.

A few questions:

1. Do you have any plugins other than BuddyPress installed and activated? If so, try disabling .
2. Are you using the standard BuddyPress themes or customized themes? If customized themes, try switching to the default BP themes.
3. Are there any errors in your server’s log files?

[Greg]

Jeff, thanks for the extensive efforts to repro on your side. I have answers to your first two questions:

1. No other plugins

2. Default BuddyPress Home Theme

I will investigate the server logs.

[dwdutch]

I’m refreshing this thread because I’m experiencing this same problem in my blog but I’ve not found a solution anywhere else in the forum. I believe I’ve tracked the problem to its source in bp-xprofile-templatetags.php but need a little help to resolve it.

To recreate this issue, I have a 5-value radio-button sequence with the default-value being the 3rd value in the sequence and the assigned value being the 1st in the sequence. As a result, during the for-loop in the ‘radio’ switch case, TWO values are marked as being “checked” but (since it’s presented as radio-buttons) only the last in the sequence is reported as the activated button.

The problem occurs because the if-statement that decides which field is “checked” is a series of ORs — this is correct for a checkbox field-type that can have multiple values. but for radio field-type, it should be either the set-value OR the default-value but not both.

I’m still just a little too new with the code-base to be confident of what should be the correct fix but, having described the problem, I’m sure @jeffsayre or another BP-expert can propose a straight-forward correction.

In case my description this doesn’t make sense, below is the $html string that is generated from the bp_get_the_profile_field_options() call on a radio-button field type:

Professional

Organizational

Standard

Volunteer

Student

[dwdutch]

oops… I forgot that the html string wouldn’t display properly and I don’t know how to include it in this Post. Embarrassingly, I know coding well enough to debug but don’t know a simple strategy like how to display html soooo, i’ve converted all of the “<" characters to be "[" — hope it works.

[div id=”field_125″>
[label>
[input checked=”checked” type=”radio” name=”field_125″ id=”option_126″ value=”Professional”>
Professional
[/label>[label>
[input type=”radio” name=”field_125″ id=”option_127″ value=”Organizational”>
Organizational
[/label>[label>
[input checked=”checked” type=”radio” name=”field_125″ id=”option_128″ value=”Standard”>
Standard
[/label>[label>
[input type=”radio” name=”field_125″ id=”option_129″ value=”Volunteer”>
Volunteer
[/label>[label>[input type=”radio” name=”field_125″ id=”option_130″ value=”Student”>
Student
[/label>[/div>

[dwdutch]

uuuughhh… I converted all of the “<" to be "["

[Hugo Ashmore]

Wrap in <code> tags and escape the opening less than angle bracket of markup. html entity for ‘less than’ = & lt ; no spaces!

[dwdutch]

I think the following properly displays the output from bp_get_the_profile_field_options() as an example of when radio-buttons intermittently display incorrectly. Below that I also show a potential fix – although @jeffsayre or another BP-expert may have a better solution. (Thanks @hnla for explanation)


<div id="field_125"><label><input checked="checked" type="radio" name="field_125" id="option_126" value="Professional">
Professional</label>
<label><input type="radio" name="field_125" id="option_127" value="Organizational">Organizational</label>
<label><input checked="checked" type="radio" name="field_125" id="option_128" value="Standard">Standard</label>
<label><input type="radio" name="field_125" id="option_129" value="Volunteer">Volunteer</label>
<label><input type="radio" name="field_125" id="option_130" value="Student">Student</label></div>


Notice that there are TWO checked=”checked” settings in the list. This occurs in the ‘radio’ switch statement of bp_get_the_profile_field_options() because of an IF-statement within a for-loop that I believe too liberally assigns the “checked” value to the default-value in the list regardless of whether or not there is already a set-value.

One alternative is to assign a variable before the for-loop…

$SomeValueChecked = FALSE;


… then check this variable within the IF-stmt before setting the default-value. Something like the following:


if ( $option_value == $options[$k]->name || $value == $options[$k]->name || ( $options[$k]->is_default_option && $SomeValueChecked == FALSE ) ) {
$SomeValueChecked = TRUE;
$selected = ' checked="checked"';
}