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

[buddypress-trac]

#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  |
-----------------------------------+------------------

Comment (by r-a-y):

 Yeoman's work here, boonebgorges!

 Like DJPaul, I have no qualms with the `fill_data()` method.  I did make a
 slight change in this method to use `stripslashes()` on the `field` and
 `description` properties so the properties are the same as in
 [https://buddypress.trac.wordpress.org/browser/tags/2.3.3/src/bp-
 xprofile/classes/class-bp-xprofile-field.php#L174 BP 2.3.x].

 My only concern is in `BP_XProfile_Group::get()`.

 On line 386 of `class-bp-xprofile-group.php`, in the `foreach (
 $uncached_fields as $uncached_field )` block, you are caching
 `$uncached_field` in the `'bp_xprofile_fields'` cachegroup.  At this
 stage, `$uncached_field` is not a complete row from the
 `$bp->profile->table_name_fields` table as it should be (see
 `BP_XProfile_Field::get_instance()` where the initial cache is set).

 Should the entire block from line 381-390 be removed?

 The reason I say this is further down on line 394, you grab the fields
 again via field ID, which should trigger the cache to be set if it isn't
 already via `xprofile_get_field( $field_id )` =>
 `BP_XProfile_Field::get_instance()`.

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