Skip to:

Opened 11 years ago

Closed 11 years ago

#4912 closed defect (bug) (fixed)

xprofile BP_XProfile_Field populate do not fill data

Reported by: eggproject's profile eggproject Owned by: boonebgorges's profile boonebgorges
Milestone: 1.8 Priority: low
Severity: minor Version: 1.2.8
Component: Extended Profile Keywords:
Cc: eggprojec@…


$tmp = new BP_XProfile_Field(FIELDID,USERID);

do not fill auto with data...

function populate .... remove $user_id = 0;!

Change History (8)

#1 @boonebgorges
11 years ago

  • Keywords reporter-feedback added

Can you please be more specific about what your problem is? I do not understand what you're trying to say here. (BP_XProfile_Field does not have a populate() method.)

#2 @johnjamesjacoby
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

+1 to Boone's assessment. Closing as invalid for now. Reopen if/when you can attach more details.

#3 @r-a-y
11 years ago

  • Keywords reporter-feedback removed
  • Milestone set to Future Release
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 1.6.4 to 1.2.8

BP_XProfile_Field does not have a populate() method.

It does. See:

There's also an inline note denoting why we are even wiping out the $user_id variable:

The good news is we never use the second or third parameters of BP_XProfile_Field::populate() internally. So it looks like eggproject is doing something specific.

We should perhaps look at rectifying this.

#4 @eggproject
11 years ago

about i use...

$cfield = new BP_XProfile_Field($kitKeresekFieldId,$cuserId);
$cvalue = maybe_unserialize($dfield->data->value);

original code to the constructor is not charged in $ data ....

function construct( $id = null, $user_id = null, $get_data = true ) {

if ( !empty( $id ) )

$this->populate( $id, $user_id, $get_data );


call populate... my code fill this object ...

#5 @eggproject
11 years ago

  • Cc eggprojec@… added

#6 @boonebgorges
11 years ago

  • Milestone changed from Future Release to 1.8
  • Priority changed from normal to low
  • Severity changed from normal to minor

My bad, I was misreading the code. Let's check the logs to see why we're wiping out $user_id here. Since, as r-a-y notes, we're not using the $user_id param anywhere in BP, this should be pretty harmless to fix (though we may want to check the plugin repo to see if anyone is taking advantage of this mysterious bug in a plugin).

#7 @boonebgorges
11 years ago

Looks like the bug was inadvertantly introduced in r3369, in an attempt to clear some WP_DEBUG warnings. I'm going to go ahead and revert it.

#8 @boonebgorges
11 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from reopened to closed

In 7117:

Don't wipe out the user_id param passed to BP_XProfile_Field::populate()

This fixes a bug introduced in r3369 in an attempt to remove a WP_DEBUG
notice, but inadvertantly prevented plugins from directly calling the
populate() method using the user_id param.

Fixes #4912

Note: See TracTickets for help on using tickets.