[buddypress-trac] [BuddyPress Trac] #6347: XProfile fields used for signup should be configurable

[buddypress-trac]

#6347: XProfile fields used for signup should be configurable
-----------------------------------+------------------------------
 Reporter:  johnjamesjacoby        |       Owner:  johnjamesjacoby
     Type:  enhancement            |      Status:  accepted
 Priority:  high                   |   Milestone:  2.3
Component:  Component - XProfile   |     Version:  1.0
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------------------

Comment (by boonebgorges):

 Thanks for your work on this so far.

 I am a big fan of converting the disparate query methods to `get()`
 wrappers, especially since it builds in cache support for all these
 methods. I see that you've built in centralized invalidation for these
 caches - which I like - but let's make sure to check that this covers all
 the ways in which the field table can be updated. I haven't looked at this
 specifically, but my knowledge of the bp-xprofile component is such that I
 wouldn't be surprised if we were doing some direct UPDATE/INSERT queries
 elsewhere.

 It looks to me like the `get()`/cache support refactoring comprises a
 standalone improvement. It would be nice to see it broken out at the time
 of commit. The signup IDs stuff is pretty straightforward and independent
 once the `get()` refactor is done.

 I'm not sure I understand the `parse_args()` suggestion. Is it just so
 that we don't have to repeat the `$args` signature? A class property
 `$default_args` or something like that would also work.

 The existing meta-cache implementation - by which I assume you mean
 `bp_xprofile_update_meta_cache()` - is indeed pretty clunky, and is built
 specifically with the needs of `bp_has_profile()` and its funky nesting in
 mind. I agree that it's probably a good idea to make it more flexible.
 Something like your `update_field_caches()` method, except for meta
 caches, might be good, though we'd want to make sure that in cases where
 we *do* cascade the hierarchy, we do a single query for each level of the
 hierarchy to populate the cache. (In other words: if querying for four
 profile groups, each with two fields, we do a single query to populate the
 four groupmeta caches, and a single query to populate the eight fieldmeta
 caches - *not* four separate fieldmeta cache queries, as the normal tree-
 walking technique would suggest.)

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