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

buddypress-trac noreply at wordpress.org
Sat Apr 4 20:38:01 UTC 2015


#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  |
-----------------------------------+------------------------------
Changes (by johnjamesjacoby):

 * keywords:   => has-patch 2nd-opinion
 * owner:   => johnjamesjacoby
 * status:  new => accepted
 * priority:  normal => high


Comment:

 [https://buddypress.trac.wordpress.org/attachment/ticket/6347/6347.03.patch
 6347.03.patch] is a big patch that does the following:

 * Introduces smarter `get()` method for free-form querying of field data
 * Uses this new static method where appropriate
 * Modifies `BP_XProfile_Field` methods as appropriate
 * Introduces field caching, including for field options
 * Passes existing unit tests; needs tests to confirm cache invalidation is
 working correctly
 * Works with existing `xprofile_` functions
 * Works with field groups & options
 * Treats fields and options as one and the same, allowing them to use the
 same CRUD methods

 I would appreciate feedback and help with the following:
 * Are the query params okay? What can we add/remove/rename to make this
 better?
 * Should we introduce a dedicated `parse_args()` method that can be used
 for `DELETE` queries also?
 * Anyone want to wire-up the `meta_query` part?
 * Our existing meta-cache implementation is a bit of a bolt-on, making it
 difficult to unwind smoothly with multiple layers of caching happening. It
 would be nice to simplify this eventually.
 * Field groups getting Fields getting Field Data is quite the stack. It's
 not ideal, but I think it will need to be improved not as part of this
 initiative.

 TL;DR - this is a big patch that touches lots of existing code. Similar to
 attachments, I'd like to commit this into trunk ASAP to continue iterating
 on the approach before this patch goes too stale.

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


More information about the buddypress-trac mailing list