[buddypress-trac] [BuddyPress Trac] #6789: XProfile: do not store serialized arrays for multi-value profile field data

[buddypress-trac]

#6789: XProfile: do not store serialized arrays for multi-value profile field data
------------------------------+-------------------------------------
 Reporter:  Offereins         |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Contributions
Component:  Extended Profile  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |
------------------------------+-------------------------------------

Comment (by Offereins):

 @boonebgorges Thanks for taking a look at this. I'm hoping we can form
 this to a solid solution for the issue of serialized data.

 In reply to your random feedback, the following.

 1. I find it plausible that a custom profile field would store its data as
 a serialized array. One of such examples would be an address field that
 comes with a preformatted layout and stores data for street, city, postal
 code, etcetera. I'm unsure how such a field would store its data otherwise
 within the current table structure of BuddyPress - or is this a potential
 case for field data metdata? A second example would be a column type field
 which allows admins to define their own subfields. I'm basically talking
 about ''nested fields''. Following from this, one can imagine a multi-type
 field which supports listing multiple nested fields of the aforementioned
 types. For this case I'm mainly thinking about my `BP XProfile
 Relationship Field` plugin. Whether it is plausible enough to support this
 in core is up for debate. I might be biased.
 2. Handled in r11866.
 3. Agreed. I'm leaning towards making a hookless method for the delete
 logic.
 4. That should be fixed. Do you prefer using the first value's key or the
 second? I haven't applied field data metadata before, but we should
 consider it since it is technically supported.

 Concerning your last point, I'm not quite sure I understand your meaning
 of an optional `get_data()` method. Would it serve as a default data
 getter where the data would always be unserialized/sanitized if applicable
 - so we can remove the unserializing from any logic outside of the
 profiledata class?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6789#comment:19>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac