Undefined property: stdClass::$visibility in profile_view_field()

Thanks for the detailed report!

function profile_view_field($account, $field) {
  // Only allow browsing of private fields for admins, if browsing is enabled,
  // and if a user has permission to view profiles. Note that this check is
  // necessary because a user may always see their own profile.
  $browse = user_access('access user profiles')
        && (user_access('administer users') || $field->visibility != PROFILE_PRIVATE)
        && !empty($field->page);

The error is thrown when the code above reaches the $field->visibility check ... since $field->visibility does not exist ... even though the other field properties do exist. I found a similar core issue from way back (#326607: undefined property: stdclass visibility when viewing profile pages) which resulted in the $field->visibility check going in ... not sure why it would be failing now, though.

The debug_backtrace on this one is essentially profile_browse -> _profile_update_user_fields -> profile_view_field ... but I didn't dig deep enough to determine where the profile fields are actually being defined.

I cannot replicate the error in pages wit /user/ in the URL/
I can only replicate the error in pages with /profile/ in the path.
i.e. https://git7site.devdrupal.org/profile/profile_conference_prague_2013

I'm no longer able to reproduce the 'undefined property' error on git7site ... I wonder if it may just have been an issue with a particular database snapshot?

Postponing for now, as we can not reproduce with the current instructions ... if this doesn't crop back up, then it's probably safe to assume it was data corruption and/or resolved by another issue elsewhere.

No ... you're correct ... I was granted an increased level of user permission on drupal.org this week, which masked the issue. Going back as the anonymous user, it's definitely still there.

Back to confirmed ... Thanks!

tag

I think this is a duplicate of a core issue which I fixed and it got committed. I'll make sure we are running a dev version of core or have this patch applied.

False alarm, #2046677: Strict warning: Creating default object from empty value in template_preprocess_profile_listing is deployed for us.

Ok, I think it was #2046677: Strict warning: Creating default object from empty value in template_preprocess_profile_listing, fixed on Oct 1, which is after problems reported in this issue.

Please double check. Notices are present on git7site right now for not logged in users (see screenshot), e.g.: https://git7site.devdrupal.org/profile/profile_my_mentors/jhodgdon

#2046677 is about "Strict warning: Creating default object from empty value in template_preprocess_profile_listing()". Here we are talking about "Notice: Undefined property: stdClass::$visibility in profile_view_field()".

Here's a core patch that seems like a logical fix.
Moving to the core queue to get a review.

Tested on http://project-drupal_7.redesign.devdrupal.org/profile/profile_my_mentor...

I'm not sure what else adding this might potentially affect, but the approach seems reasonable and I can confirm it resolves the issue.

Committed to Drupal.org's BZR repo.

.

Looks correct to me too. The extra field eventually gets passed to profile_view_field(), which expects it to be there (and which already gets it passed in the alternate code path in profile_browse(), not visible in the patch file).

Looks like there shouldn't be any side effects except the PHP notice.

Committed to 7.x - thanks! http://drupalcode.org/project/drupal.git/commit/70e25d7