#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 | Owned by: | |
---|---|---|---|
Milestone: | 1.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Extended Profile | Keywords: | has-patch |
Cc: | mercime |
Description
As I was debugging:
http://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/date-selector-datebox-control-doesnt-allow-future-dates/
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)
Change History (12)
#3
@
14 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 ;)
#4
@
14 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
@
14 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.
#6
@
14 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.
Related: #2240.