[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