Skip to:

Opened 10 years ago

Closed 10 years ago

#5334 closed defect (bug) (fixed)

Getting warning "Creating default object from empty value when enabling extended profiles"

Reported by: clamoreaux's profile clamoreaux Owned by: boonebgorges's profile boonebgorges
Milestone: 2.0 Priority: low
Severity: minor Version: 1.9.1
Component: Extended Profile Keywords: needs-patch
Cc: templaries@…


I originally posted this here: but decided it may be a bug.

I am getting this warning on the member’s pages when I enable extended profiles:

Warning: Creating default object from empty value in C:\Users\C\Documents\Websites\\wp-content\plugins\buddypress\bp-members\bp-members-template.php on line 662

I am using WordPress 3.8 and BuddyPress 1.9.1 with a custom theme. I don’t recall seeing this error before I updated both WP and BP. Any ideas what is going on and how to fix this?

Change History (10)

#1 @DJPaul
10 years ago

  • Keywords reporter-feedback added

Hi clamoreaux,

I can't recreate this, which suggests the problem is in the interaction with your theme. Which theme are you using? One you built, or something you downloaded?

#2 @walbo
10 years ago

  • Version set to 1.9.1

I also get this warning when I use bp_member_profile_data( 'field=About Me' );

#3 @M-BP
10 years ago

Dear all

I would like to confirm walbo's comment.

In the template ...buddypress\members\single\member-header.php starting on line 49 it is possible to print xProfile field data (e.g. bp_member_profile_data( 'field=About Me' ); ). Doing so always results in the above mentioned warning (has also been the case in older versions of BP).
This issue seems to be independent of the theme. I have tried it with multiple themes (incl. Twenty Fourteen and calling the field via the bp-legacy templates) and always received back the same warning.

#4 @boonebgorges
10 years ago

  • Keywords needs-patch added; reporter-feedback removed
  • Milestone changed from Awaiting Review to 2.0
  • Priority changed from normal to low
  • Severity changed from normal to minor

Yes, I can see how this would happen if you were using this function outside of a bp_has_members() loop. If we're going to support this use (and it seems like we are, since we accept a 'user_id' param), then we should fix the reported issue. Probably the easiest is just to do the $members_template->member->profile_data setting only if isset( $members_template->member ); there's no need to cast it as new stdClass and then set this global if we're outside a loop (and in fact it could potentially cause problems).

#5 @M-BP
10 years ago


I have tried to implement a solution based on your comment above. Tried multiple codes in..\buddypress\bp-members\bp-members-template.php on lines 660-667 (error gets caused by line 662 of that file) but to no avail. I managed to make the error disappear but then it was not possible to retrieve the field value anymore either.

Do you have a fix ready in mind? Or some more details that could point me into the right direction?

Thanks a lot for your help.

P.S. I didn't dare to change the priority but for me this is important. I think printing some values of profile fields in member-header is likely to be a pretty common request and makes sense to do.
Version: 1.9.2

#6 @boonebgorges
10 years ago

I think printing some values of profile fields in member-header is likely to be a pretty common request and makes sense to do.

If you're seeing notices show up on the front end of your public site, you should turn down the PHP error reporting level on your site.

This will be fixed for the 2.0 release.

#7 @templaries
10 years ago

  • Cc templaries@… added
  • Milestone 2.0 deleted

Is there any temporal solution for this?

I added bp_has_members() before bp_member_profile_data() to fill the global variable "$members_template".

bp_member_profile_data('field=MY EXTENDED FIELD');

But this is still showing the warning message

I've used this for temporal solution:

$profile_data = BP_XProfile_ProfileData::get_all_for_user( bp_displayed_user_id() );
$field = "MY FIELD";
$data = xprofile_format_profile_field( $profile_data[$field]['field_type'], $profile_data[$field]['field_data'] );
Last edited 10 years ago by templaries (previous) (diff)

#8 @boonebgorges
10 years ago

  • Milestone set to 2.0

We will fix this one way or another for 2.0.

In the meantime, it's a harmless warning. If it's displaying to your users, then you should turn down error reporting on your public site. Put the following in wp-config.php:

error_reporting( 0 );
@ini_set( 'display_errors', 0 );

#9 @boonebgorges
10 years ago

In 8081:

Improve variable naming in bp_get_member_profile_data()

The overuse of the $user_id variable, combined with the ill-advised use of
explode(), was resulting in situations where it was impossible to pass a custom
value of $user_id to the function.

See #5334

#10 @boonebgorges
10 years ago

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

In 8082:

Improve behavior or bp_member_profile_data() when used outside of members loop

Our documentation suggests the use of bp_member_profile_data() to pull up
miscellaneous pieces of user profile data anywhere in a template. Technically,
this works, but the internals of the function made a few assumptions that it
would only be used in the context of a bp_has_members() loop. This would result
in needless PHP notices when using the function outside of a loop context.

This changeset introduces checks to ensure that the $members_template global
is only manipulated if it exists, making the function safe to use anywhere.

Fixes #5334

Note: See TracTickets for help on using tickets.