Skip to:

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#2947 closed defect (bug) (fixed)

bp_get_the_profile_field_options( 'type=datebox' ) - missing saved value and "type" parameter in filter

Reported by: r-a-y's profile r-a-y Owned by:
Milestone: 1.5 Priority: normal
Severity: normal Version:
Component: Extended Profile Keywords: has-patch
Cc: mercime


As I was debugging:

I found that $field->data->value is always empty in bp_get_the_profile_field_options( 'type=datebox' ), which prevents the datebox field to grab the saved value from the DB when editing a datebox field on the frontend.

Also the "bp_get_the_profile_field_datebox" filter should add the $type parameter, so plugins can override the day/month/year fields.

Patch against 1.3-bleeding.

Should also patch for 1.2.6 as this is a bug.

Attachments (4)

2947.001.patch (3.5 KB) - added by r-a-y 13 years ago.
2947.002.diff (10.1 KB) - added by cnorris23 13 years ago.
2947.003.patch (13.8 KB) - added by boonebgorges 13 years ago.
2947.004.diff (14.1 KB) - added by cnorris23 13 years ago.

Download all attachments as: .zip

Change History (12)

13 years ago

#1 @mercime
13 years ago

  • Cc mercime added

#2 @r-a-y
13 years ago

Related: #2240.

#3 @cnorris23
13 years ago

While working up a patch for #2240 I, too, ran into this bug. I went through and cleaned the bp_get_the_profile_field_options() function. I also added some documentation for the bp_the_profile_field_options() and bp_get_the_profile_field_options() functions. While searching to make sure this wasn't already reported before starting a new ticket, I found this one, so I went back through and added things from r-a-y's patch that I was missing. I'll be added a new patch to #2240 which builds on this patch. Hopefully, we can get both closed ;)

13 years ago

#4 @boonebgorges
13 years ago

Thanks for the patches, guys.

cnorris23, your patch had a problem or two of its own ($selected needs to be reset on each iteration through the $options loop). But it also uncovered some inconsistencies with the way that BP was handling default values. In particular, two of the profile field types - multiselectbox and checkboxes - allow the admin to set default values, but they also allow the user to save a null value for that field. That causes a problem, because if the user unchecks all the boxes (in the case of checkboxes), then xprofile thinks it should reapply the default values on the next load.

This problem was not visible before because of some bugs in xprofile that cnorris23's patch uncovered.

2947.003.patch cleans up cnorris23's patch, and fixes the default value problem described above by allowing those two kinds of fields to save an empty array to the xprofile_data table. That way, BP can distinguish between when a user has not yet provided a value for the profile field in question and should use the default value (namely, when BP_XProfile_ProfileData::get_value_byid() returns null), and when a user has intentionally saved zero of the available choices (when BP_XProfile_ProfileData::get_value_byid() returns an empty array).

I'm sorry to wrap this problem up with the original one, but the fixes were closely related. Please give it a test with all the different kinds of profile fields and default values.

#5 @cnorris23
13 years ago

Good catch boonegorges! Got a little overzealous with the cleanup, and since I had my blinders on from focusing on the datebox issue, I forgot to test the others. The new patch works well in all cases. Everything seems to save/delete just fine.

The only problem I saw was on the public profile portion. Since multiselect and checkbox fields are always an array on save, empty or otherwise, fields with an empty array were being displayed... well their field name was being displayed, since running the empty() function on a serialized array will always return false. Updated the patch to run maybe_unserialize() on the field data in BP_XProfile_Data_Template::the_profile_field() and all is well again. Probably needs another round of testing.

13 years ago

#6 @boonebgorges
13 years ago

Nice catch on your part, cnorris23 - I hadn't thought about empty fields showing up on the public profile. I made a tweak to your fix in 2947.004 to make sure that we avoid PHP warnings in cases where $field->data is empty (that is, when the user hasn't yet selected a value for that option).

Gonna commit this one as I think the two of us have been through it pretty thoroughly. Feel free to reopen if you spot more problems.

#7 @boonebgorges
13 years ago

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

(In [3650]) Ensures that datebox profile field types have their values displayed properly on the profile edit screen. Cleans us bp_get_the_profile_field_options() and reworks the way that default values work in the case of multiselect and checkbox fields. Fixes #2947. Props r-a-y, cnorris23

#8 @johnjamesjacoby
13 years ago

  • Milestone changed from Awaiting Review to 1.5
  • Severity set to normal
  • Version 1.5 deleted

Moving closed ticket out of Awaiting Review.

Note: See TracTickets for help on using tickets.