Today I received "Fatal error: Call to a member function Logout() on a non-object in /home/techmi5/public_html/urbanministryjobs/sites/all/modules/gigya/gigya.module on line 457" when trying to log in to my test Socialize site. I don't have much data on this bug yet, other than that I was trying to log in with Twitter.

Here was the URL: "http://www.urbanministryjobs.org/socialize-login?destination=&signature=..."

I'll try to update with more data, and change priority higher or lower based on what I find out.

Comments

EvanDonovan’s picture

EvanDonovan commented

For more info:

line 457 in my gigya.module is simply $user->gigya->Logout();

It looks like gigya_user is getting called with an $op of "logout", when I am trying to log in. Maybe I broke the code?

I will try clearing cookies, etc.

EvanDonovan’s picture

EvanDonovan commented
Title: Twitter Socialize login fails with fatal error » Gigya Socialize is incompatible with Legal module when terms are updated
Priority: Normal » Minor
Status: Active » Postponed

Turns out this was due to the login hook of the Legal module calling module_invoke_all('user', 'logout'...) when the terms & conditions for the site had been updated. Thus, the logout hook was being called when there was as yet no Gigya object.

This may be better off being handled by the Legal module, since it is such an odd case.

EvanDonovan’s picture

EvanDonovan commented

Cross-reference: #753442: Simply changing the display settings should not create a new version of terms.

azinck’s picture

azinck commented

In general I've been wondering about how fragile it is to rely on the gigya object being attached to the user. I chose that architecture but it might not be for the best. I'm not familiar enough with the inner workings of some of the more complex modules to know if that's a bad idea. The practice also seems to cause a problem with the new webform module (v3) that apparently inspects the user object for some reason. Hmm...thoughts anyone?

EvanDonovan’s picture

EvanDonovan commented

I didn't realize that the gigya object didn't used to be attached to the user. I'm going to poll IRC on this, see if folks more experienced in the Drupal way can weigh in.

If we are going to change architectures, then we should cross-reference related issues here.

Also, I will try to remember to post an issue to Legal module in regard to the (lack) of use of user_module_invoke & the missing of the "load" op prior to the "logout" op.

EvanDonovan’s picture

EvanDonovan commented
Title: Gigya Socialize is incompatible with Legal module when terms are updated » PHP error when "logout" op is called when there's no $gigya->user object (was Gigya Socialize is incompatible with Legal module)
Priority: Minor » Normal
Status: Postponed » Active

This same error happened on my site (where Gigya is now live, btw) in a different circumstance. I wonder if there is some kind of error checking we should do to see if $user->gigya exists before doing operations to it in the "logout" op.

EvanDonovan’s picture

EvanDonovan commented
Version: 6.x-2.0 » 6.x-2.1

I do think we should have the gigya object attached to the $user object, though, probably. We should see if we can get feedback from some more experienced Drupal developers on this.

EvanDonovan’s picture

EvanDonovan commented
Title: PHP error when "logout" op is called when there's no $gigya->user object (was Gigya Socialize is incompatible with Legal module) » PHP error when "logout" op is called when there's no $user->gigya object (was Gigya Socialize is incompatible with Legal module)

Probably this could be fixed simply by checking isset($user->gigya) before proceeding to unset it.

EvanDonovan’s picture

EvanDonovan commented

In the hook_user implementation (gigya_user), I changed the "logout" $op to the following:

if(isset($user->gigya)) { $user->gigya->Logout(); }

I'll report back and post a patch if that resolves the issue.

gambaweb’s picture

gambaweb commented

I think it is a good idea warping the logout with isset

EvanDonovan’s picture

EvanDonovan commented
Status: Active » Closed (won't fix)

I reported this issue on a legacy version of the module, so I doubt that it is going to be relevant anymore.