[buddypress-trac] [BuddyPress Trac] #6638: XProfile fields should have cache support

buddypress-trac noreply at wordpress.org
Fri Oct 2 22:26:31 UTC 2015


#6638: XProfile fields should have cache support
-----------------------------------+------------------
 Reporter:  boonebgorges           |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  2.4
Component:  Component - XProfile   |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch 2nd-opinion
 * component:  API => Component - XProfile


Comment:

 [attachment:6638.diff] does a few main things:

 * Splits the field query in `BP_XProfile_Group::get()`, and adds cache
 priming support there
 * Turns `xprofile_get_field()` into a wrapper that can handle lots of
 different types of input, and convert to `BP_XProfile_Field` objects. This
 is similar to how `get_post()` and friends work.
 * Adds cache support to `xprofile_get_field()`.
 * Using these tools, `BP_XProfile_Group::get()` now returns real field
 objects (`array_map( 'xprofile_get_field', $field_ids )`) instead of
 `stdClass`. See #6358.

 What do people think of the approach? The awkward bit is `fill_data()` -
 our `__construct()` method expects an integer, and I could have used some
 parameter overloading, but thought that this was a bit more transparent.

 If we like the approach, we can apply the return-real-objects approach
 elsewhere in BP.

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


More information about the buddypress-trac mailing list