![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Version 1 and Version 2 of Ticket #6789, comment 19
- Timestamp:
- 02/28/2018 09:52:43 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #6789, comment 19
v1 v2 3 3 In reply to your random feedback, the following. 4 4 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.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 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. 6 6 2. Handled in r11866. 7 7 3. Agreed. I'm leaning towards making a hookless method for the delete logic.
