Skip to:
Content

BuddyPress.org

Changes between Version 1 and Version 2 of Ticket #6789, comment 19


Ignore:
Timestamp:
02/28/2018 09:52:43 PM (20 months ago)
Author:
Offereins
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #6789, comment 19

    v1 v2  
    33In reply to your random feedback, the following.
    44
    5 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.
     51. 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 a variation on my `BP XProfile Relationship Field` plugin, which would enable you to make a listed version of a single-type field. Whether it is plausible enough to support this in core is up for debate. I might be biased.
    662. Handled in r11866.
    773. Agreed. I'm leaning towards making a hookless method for the delete logic.