Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
On "People mentored by [name]" pages for not logged in users one can see:
Notice: Undefined property: stdClass::$visibility in profile_view_field() (line 283 of /var/www/git-dev.drupal.org/htdocs/modules/profile/profile.module).
Example: https://git7site.devdrupal.org/profile/profile_my_mentors/jhodgdon
Comment | File | Size | Author |
---|---|---|---|
#13 | d7qa-code-2090207-13.patch | 716 bytes | helmo |
#11 | pic2.png | 92.02 KB | tvn |
#3 | profile-error-page.txt | 58.28 KB | davidhunter |
error_messages.txt | 11.74 KB | Tor Arne Thune |
Comments
Comment #1
eliza411 CreditAttribution: eliza411 commentedThanks for the detailed report!
Comment #2
jthorson CreditAttribution: jthorson commentedThe 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.
Comment #3
davidhunter CreditAttribution: davidhunter commentedI 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
Comment #4
jthorson CreditAttribution: jthorson commentedI'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.
Comment #5
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedI'm still getting the error (undefined property visibility together with "creating default object from empty value") by going to https://git7site.devdrupal.org/profile/profile_my_mentors/jhodgdon both as anonymous user and logged in user.
Not sure what more info to give, as I don't see how this could be a browser problem or a problem showing up only for those connecting from Europe.
Comment #6
jthorson CreditAttribution: jthorson commentedNo ... 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!
Comment #7
tvn CreditAttribution: tvn commentedtag
Comment #8
drummI 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.
Comment #9
drummFalse alarm, #2046677: Strict warning: Creating default object from empty value in template_preprocess_profile_listing is deployed for us.
Comment #10
drummOk, 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.
Comment #11
tvn CreditAttribution: tvn commentedPlease 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()".
Comment #12
helmo CreditAttribution: helmo commentedHere'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...
Comment #13
helmo CreditAttribution: helmo commentedComment #14
helmo CreditAttribution: helmo commentedComment #15
jthorson CreditAttribution: jthorson commentedI'm not sure what else adding this might potentially affect, but the approach seems reasonable and I can confirm it resolves the issue.
Comment #16
drummCommitted to Drupal.org's BZR repo.
Comment #16.0
drumm.
Comment #17
David_Rothstein CreditAttribution: David_Rothstein commentedLooks 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