"Notice: Trying to get property of non-object in..." when doing search.json

"Notice: Trying to get property of non-object in..." when doing search.json

Issue ID:3478
Issue Category:bug
Component:api
Priority:normal
Status:active
Assigned:Unassigned
Version:1.0
Keywords:1.0.1, api, avatar, json, notice, php, profile, search, statusnet

i get the following error when doing an api-request:
Notice: Trying to get property of non-object in /var/kunden/web14/user/elevate.at_peter.wetz/web/statusnet/classes/Profile.php on line 146

the request is the following:
http://status.elevate.at/api/search.json?q=%23e11opening

the code in profile.php is the following:
142 // GAR! I cannot figure out where _avatars gets pre-filled with the avatar from
143 // the previously used profile! Please shoot me now! --Zach
144 if (array_key_exists($width, $this->_avatars)) {
145 // Don't return cached avatar unless it's really for this profile
146 if ($this->_avatars[$width]->profile_id == $this->id) {
147 return $this->_avatars[$width];
148 }
149 }

infos to my statusnet-version: http://status.elevate.at/main/version
i have shell access and everything..
phpinfo: http://elevate.at/users/elevate.at_peter.wetz/phpinfo.php

statusnet-log says:
2011-10-14 08:24:59 LOG_WARNING: [status.elevate.at:13033.c03ca52a GET /api/search.json?q=%23e11opening&rpp=20&callback=jQuery16407833815943754445_1318579877532&_=1318580699072] Unable to find theme 'default', falling back to default theme 'neo'

and

2011-10-14 08:24:59 LOG_DEBUG: [status.elevate.at:13033.c03ca52a GET /api/search.json?q=%23e11opening&rpp=20&callback=jQuery16407833815943754445_1318579877532&_=1318580699072] apisearchjson prepare()

Updates

#1

btw: this issue does not neccessarily need to have something to do with the upgrad to version 1.0!

#2

i think the problem is that statusnet confuses the users here..
why i think that? because the API response is (if i comment the code which makes problems right now (profile.php)) putting in the wrong users:

one API response is:
{
"text": "@elevatefestival starts Oct.20th in Graz. Feat. Johan Galtung opening speech + Kumi Naidoo + more http://ur1.ca/5d1pl #E11fest #E11opening",
"to_user_id": null,
"to_user": null,
"from_user": "beta",
"id": "106",
"from_user_id": "7",
"iso_language_code": null,
"source": "Gwibber",
"profile_image_url": "http://status.elevate.at/theme/neo/default-avatar-stream.png",
"created_at": "Mon, 10 Oct 2011 20:48:01 +0000"
}

the problem is that the notice actually doesnt come from:
"from_user": "beta",
"from_user_id": "7",

as you can see here the notice is coming from the user DAN:
https://status.elevate.at/notice/106

and thats why i think that in the end there is a problem in the profile.php file...

so: why is search.json returning the wrong users for the notices?

#3

Simple fix - don't know whether it will solve the underlying problem.

in /path/to/SN/classes/Profile.php at line 144, change:

if (array_key_exists($width, $this->_avatars)) {

to:

if (array_key_exists($width, $this->_avatars) && is_object($this->_avatars[$width])) {

#4

Jon's fix will probably take care of all the error messages. However to solve the problem at its roots, it all arises in the Profile class _fillAvatar function (as a result from caching attempts in its getAvatar function?)

So my suggestion for avoiding generating new non-object entries in the Profile _avatars array is to make the function look like this:


function _fillAvatar($width, $avatar)
{
// This avoids storing null values, causing
if (is_object($avatar)) {
$this->_avatars[$width] = $avatar;
}
}

I'm submitting this as a merge request together with several other improvements to Avatar handling...

#5

Please see merge request #186 at https://gitorious.org/statusnet/mainline/merge_requests/186 for the merge request I mentioned.

Login or Register to modify this issue, or to receive updates by email.

You can also subscribe to the RSS feed for updates to this issue.