Opened 15 years ago
Closed 14 years ago
#2172 closed defect (bug) (fixed)
Function bp_profile_field_data () returns raw data for non-string data types
Reported by: | foxly | Owned by: | boonebgorges |
---|---|---|---|
Milestone: | 1.5 | Priority: | minor |
Severity: | Version: | ||
Component: | Core | Keywords: | has-patch, dev-feedback |
Cc: |
Description
The function bp_profile_field_data () is used to retrieve data from the current buddypress user’s extended profile.
When the function is called on string data fields, it returns the value the user entered.
However when the function is called on ‘date’ type data it appears to return it in milliseconds 1/1/1970 format; and when the function is called on a “checkbox” field, it returns the data as some sort of internal data structure; for example, a checkbox group “Customers”, “Friends”, and “Networking” would be returned as:
a:3:{i:0;s:9:"Customers";i:1;s:7:"Friends";i:2;s:10:"Networking";}
To replicate this problem:
1) On a default buddypress installation using the default template, create several extended profile fields using checkbox and date data types.
2) Log in as a test user and fill-out the profile fields you created.
3) At line 7 in members/single/profile/profile-loop.php, add the following code:
<?php bp_profile_field_data ('field=XXX') ?>
<?php bp_profile_field_data ('field=YYY') ?>
<?php bp_profile_field_data ('field=ZZZ') ?>
(where ‘XXX’, ‘YYY’, and ‘ZZZ’ are names of valid fields in the BP extended profile, which are date or checkbox data types)
Then visit the user’s “profile” page.
The raw field data will be dumped into the user’s profile listing.
While both of the above data formats are easily converted to human-readable forms, is this the intended output of the function, or is it defective?
IMPORTANT: There is no documentation for this function in the buddypress source code or on the buddypress website. (Forum posts are not an acceptable form of documentation as they often contain outdated or incorrect information.)
Please consider releasing properly documented source code.
Attachments (1)
Change History (4)
#2
@
14 years ago
- Keywords has-patch dev-feedback added; bp_profile_field_data () bp_get_profile_field_data () removed
- Owner set to boonebgorges
- Status changed from new to assigned
See #2685, which is related.
I'm assuming that the reason why the value was being passed without unserializing had to do with the filter being applied at the end of xprofile_get_field_data(). That filter 'xprofile_get_field_data' is used by BP core to run some common formatting/security filters, filters that can't take arrays as values.
The attached patch 2172-1.patch contains a fix that checks to see whether the value is a serialized array, and if so then it applies the filter xprofile_get_field_data in question to each value in the array. I'm posting it here before committing because I'd like a second opinion about whether this is the best strategy.
That function is returning serialized data. You need to call maybe_unserialize() on it and then format it yourself. I would think that it should be unserialized automatically, but maybe that is by design for some reason.