I have performed a standard install of gigya, and was able to connect my drupal account with my FB account at user/me/edit/gigya without any trouble.

Here's a description of the problems:
1. If I try to create a new account by clicking on the "create new account" link, I get a form that includes all of the required fields, but repeats the user location block, the OG groups block, and the terms of service block (via the legal module). Each of these blocks is posted both above and below the "submit" button.

2. If I try to create a new account by clicking on one of the social network icons in the login block, a form opens up that does not include the email or username fields (I have checked in all the collapsed fieldsets) and because the form won't pass validation without an email and username, its impossible to go forward. The "already a site user" fieldset only includes a password field, and the "register a new user" fieldset includes only the "create new account" button.

By installing the profile module and adding a profile field to the registration form, I am able to make the second problem go away (although I believe there are missing fields meant to configure the social networking settings), but the first problem is unchanged.

Comments

azinck’s picture

Subscribe

azinck’s picture

StatusFileSize
new1.46 KB

Here's a quick and dirty patch that removes the duplicate fields on the registration page (your complaint #1).

In general, the form handling of this module needs to be improved. It makes assumptions and takes liberties altering the registration and log in forms to an extent that's bound to make it conflict with other modules. All that to say that I'm not surprised you're seeing your complaint #2 but I don't have a quick and easy solution for it.

EvanDonovan’s picture

Title: Gigya broke my user registration forms » Gigya user registration form override causes issues w/Organic Groups, User Location, Legal

I am experiencing this issue as well. As ln282 said, I can fix the 2nd problem by adding a user profile field, which I will do until a more permanent solution is found. I can always use unset($form[ONLY_SOCIALIZE_USER]['Blog']); near the end of gigya_link_accounts_or_register_form() in gigya.pages.inc. (Note that "Blog" is the name of the fieldset of profile fields that I am using.)

However, I discovered a further problem which is that the checkbox for Legal is no longer required. I can actually submit the form without having checked off the legal field. I will look into this further, since I think that it is caused by the overriding of the form submit handler.

EvanDonovan’s picture

I have worked for hours on trying to figure out why the Legal checkbox is not getting validating and it has me completely stumped. Not only that, but I can't even get any of my submit or validate functions to fire on form submission. Anyone know of a good guide to how to debug FormAPI?

EvanDonovan’s picture

Also, azinck: Thanks for the patch in #2; it solves the issue of duplication, although for me that is the less significant issue in comparison to the incompatibility with the Legal module.

azinck’s picture

You're welcome.

Your submit and validate functions aren't firing because the gigya_form_alter function is intercepting the submission and calling the gigya_create_user_and_link_accounts() function which attempts to do a sort of "synthetic" user creation, bypassing the normal user registration workflow. I'm currently working on a patch to fix this.

EvanDonovan’s picture

Thanks so much, azinck! Since getting Gigya Socialize to work with Legal is my top priority at the moment, I will continue to work on it as well. Now that you've pointed me in the right direction with the function to modify I might be able to figure it out... If not, I will wait for your patch.

EvanDonovan’s picture

I added the following code to the gigya_create_user_and_link_accounts just before the line that says $form_values = array(.

It's pretty much a hack on top of a hack, but it works:

	if( module_exists('legal') ) {
		if ( !isset($currPost['legal_accept'])) {
			drupal_set_message('You must accept the Terms and Conditions to use this site.', 'error');
			$failThePost= TRUE;
		}
	}
ln282’s picture

Thanks for the fixes, azinck and EvanDonovan!

cerup’s picture

I have the same problem.

The location module setup for 'registration' causes other fields to disappear when used in conjunction with gigya. Adding a profile field does fix it, but this is a really bad hack especially since it ads a field I (and others) don't want.

Also, gigya seems to ignore the location form weight and therefore the location is placed above the username/e-mail section. If you go to /user/register/ the problem of disappearing fields isn't evident and the form weight is used correctly.

I should probably put this in it's own issue (and I will if not addressed here), but adding a captcha to the registration doesn't work when using 'sign on with social network' for the first time; users can avoid putting in the captcha and it'll still create the account.

I think there's some pretty big problems in the way gigya is modifying registration forms and fields. It'd be nice if it could just add forms (like location and other modules do) rather than changing the internal form. Aside from any problems with actual gigya login/registration, I think these issues (double profile fields and clashing with other registration fields/modules) is a high priority/critical issue.

azinck’s picture

I'm making good progress on all of these issues and fixes are coming soon.

cerup’s picture

Great to hear azinck :)

I'm sure you already know, but just to stipulate - it seems any form that is not part of the profile form is ignored which is why location, captcha, legal, etc are all ignored when registering through social network login.

azinck’s picture

Yes, unfortunately the module currently bypasses most of Drupal's built-in registration functions in favor of its own separate registration code. This means that not all of the normal hooks get called for the registration forms and processes. This makes the module incompatible with most other registration modules. I'm working to make Gigya play nicer :).

EvanDonovan’s picture

Title: Gigya user registration form override causes issues w/Organic Groups, User Location, Legal » Gigya user registration form override causes issues w/Organic Groups, User Location, Legal, LoginToboggan

Thanks for working on this. Do you have an estimated time that a patch will be available? This is especially critical for our site, since we use LoginToboggan for registration and don't want to have to give up the ability to login with email addresses and to add users to the pre-authenticated user role.

Gigya’s picture

Status: Active » Fixed

Hi All,

We have released beta10, which should fix most of the problems mentioned here.
Please try to evaluate this and tell us what you think.

Thanks!
The Gigya Team

cerup’s picture

Hi Gigya,

Beta10 isn't posted to the front page, but I managed to find it and install. Unfortunately, the issue in this thread is not fixed at all (for me) and it still ignores captcha, location and any added registration fields.

I posted more here about beta10: http://drupal.org/node/668434

azinck’s picture

I'm chatting with the Gigya folks. There seems to have been a miscommunication and most of my work on this didn't make it into beta-10. We'll update once we get things sorted out. Apologies, and thanks for your patience.

cerup’s picture

Thanks azinck! You've been great thus far :D

socialnicheguru’s picture

subscribing. is this still active until there is either a patch or the fix is included in a release?

EvanDonovan’s picture

@azinck: Thanks again for your work on this - I just got back from vacation, and am wondering, should I test beta10? Or is it not working with custom fields, such as those provided by the Legal module? If the latter, then should this issue be reopened?

azinck’s picture

The issue definitely needs to be reopened. Beta 10 does not include the fixes I've made. I'm on vacation myself and I'm hoping to hear back from Gigya about getting my fixes incorporated.

rfay’s picture

Status: Fixed » Needs work

This issue is NOT resolved in beta10, and is critical.

Setting to "needs work" based on my check and on #21.

rfay’s picture

Priority: Normal » Critical
RcLRaptor’s picture

I'm having this same exact problem, too. do I need to wait for a patch, or will there be an updated version soon? I wanted to release my website this week, but if there's goign to be a patch in the next week or two, it won't hurt me to push my release back a bit.

Also, is there any work going into making Gigya work with Auto Role, allowing users creating accounts to do so under different roles? I haven't seen any support for this yet, and I was just wondering?

azinck’s picture

StatusFileSize
new106.7 KB

Since it's been so long and Gigya and I haven't managed to get my work integrated into a release I'm going to go ahead and throw my patch out there in the wild. It's based on beta 10 but significantly rewrites the module. Please consider it ALPHA. It has not been tested thoroughly enough for me to feel comfortable using it on a production site. If you install it on a production site and lose user data please don't blame me.

Known regressions:
A few of the options regarding suppressing the login block and allowing/disallowing linking of accounts to social networks may no longer work. Also, I've more-or-less broken profile pic importing for the time being.

That said, I would love for folks to test it out and fix it up.

I'm working on this intently right now so I'll be responsive to feedback. I need this to work for a site I'm building so I'm highly motivated :).

azinck’s picture

By the way, there are enough changes to the module that running update.php after applying the above patch would be a good idea.

EvanDonovan’s picture

Thanks, azinck. I will probably test this tomorrow. I have my own changes that I made to the module provisionally, though, so I'll probably have to merge those in.

azinck’s picture

The merge might be tough due to the extensiveness of the changes I made.

cerup’s picture

I just wanted to let others know that I've been testing azinck's work for about a week now (he had me test before posting) and things have been running great so far.

I have about 20 people logged in through social networks to test. The registration works with content profile, location, and other registration types. So far, so good! I'll report back if I have any major issues.

Hopefully gigya gets time to review this and make the necessary changes.

azinck’s picture

Thanks for the vote of confidence, cerup. That said, I've significantly refactored it even since sending the code to you; I've streamlined some things, made the code more maintainable, and improved performance but it's entirely possible I've introduced some new bugs.

RcLRaptor’s picture

Quick question, since I'm interested in helping test this patch: I've never used a patch like this before (I usually wait for newer version of the module to be released) so how do I apply the patch?

azinck’s picture

RcLRaptor’s picture

Oh, awesome. Thanks, azinck.

mariano.barcia’s picture

@azinck
You may want to check out #533750: Improve support for Content Profile.

We made a patch for adding Content Profile support in beta7, but now it's useless with beta10. You have provided another patch on top of beta10 to address this and other issues, perhaps you could add consider that patch when merging as well?

I will be looking forward to your comments, thanks in advance.

azinck’s picture

Yeah, sorry that the Content Profile patch got behind the development curve here. Unfortunately, since Content Profile isn't a priority for me personally, and there are still tons of bugs to fix in this module, I don't think I'm going to spend time trying to merge in your fixes. Hopefully you or someone else with a desire for Content Profile support will be able to tackle that. That said, I think my changes make the module simpler and easier to maintain and I wouldn't be surprised if you found it pretty easy to incorporate your work.

mariano.barcia’s picture

@azinck,
I understand. However, I will be much more comfortable with your latest changes in the repository, as "official", in order to avoid having the same problem again. Can you or the committers tell when will such a beta11 release happen?

azinck’s picture

Yes, I completely agree. Hopefully we will hear from Gigya soon about their plans.

RcLRaptor’s picture

Almost a week. Anything from Gigya yet?

azinck’s picture

I don't want to be specific or hold Gigya to any release dates. I hope they'll respond on here themselves, but I will say that I've made progress with them in the past couple days towards getting this code integrated into the next official release.

mariano.barcia’s picture

A bit OT, but I've been giving some thought to the way Gigya module is altering the register form because I got feedback from a couple of friends who tested a new website of ours, and they're saying the registration and login pages are confusing with the addition of the Gigya "Login using Social Networks" block at the top.

Gigya adds an important variant to the mix when a person is in front of the register screen.
"How should I register? Should I use Facebook, should I use Gmail?"
"How about sharing Facebook information with this site"
"Where should I fill out the information?"

Currently, a new user can fill out the regular register form, and if he/she clicks on any of the SN icons, those changes would be lost, since Gigya will redirect to a new form (at least, that's the way it was until beta7).

My point is: Now Drupal has two different pages, one for sign-in, another for sign-up. That is not the best choice. However, it can be worked out, as you can see here:
http://proofgroup.com/blog/2008/sep/drupal_combining_login_registration_... (Drupal core)
http://drupal.org/node/264332 (Logintoboggan)

Now, I haven't tried, but would these approaches work with Gigya installed? IMO, it's not a good idea to just embed the Gigya block on top the login and register forms. The Gigya icons should be placed perhaps in a 3rd block, in an unified page, clearly stating it's a different choice, and that it implies:
1 - not having to maintain a different password (authentication)
2 - sharing some information with a SN (newsfeed, or status update, if applicable).

Following the procedure in http://proofgroup.com/blog/2008/sep/drupal_combining_login_registration_..., I would add the gigya icons block at the bottom of the login form, or perhaps somewhere in the middle bottom...

Thoughts?

azinck’s picture

Thank you for bringing this up, Mariano. I think it's an important discussion to have and your questions identify some important weaknesses of the current implementation.

It occurs to me that there are 2 things for us to consider:

  1. Improving the module's out-of-the-box user experience
  2. Creating the module's components in such a way that a themer or implementer retains a lot of flexibility in customizing their Gigya experience.

Regarding #1:
Out of the box the module should be fairly unobtrusive, offering the best user experience we can while conforming as much as possible to the default Drupal way of doing things so that we'll have a baseline that's compatible with most themes. In that vein, I don't think the Gigya module should attempt a unified login/registration form (that's more in the realm of configuration and theme development). We do, however, want to clearly indicate that registering or logging in with Gigya is an alternative to using the other form found on the page. I'm thinking that it would be good to put Gigya at the bottom of the forms, just below the form's submit button. The registration form's submit button, for example, would read "create new account", then be immediately followed by text saying "or sign in using...".

Regarding #2:
I think there are a some fairly simple things we can do here:

  1. Ensure as much of the module's output as possible runs through theme functions.
  2. Reassess the parameters we're accepting in our theming functions. Currently the parameters being passed in are a little haphazard and these could be improved
  3. Switch to using template files instead of theme functions.
  4. Define blocks for some of the Gigya elements such as login, friends, and connected networks.
azinck’s picture

Does the lack of comment/complaint about my patch indicate it's been stable for everyone and resolved their problems? Has anyone tried it?

RcLRaptor’s picture

I've been super busy over the past week with my paid work, so I've not been able to really test the patch after I installed. Hope to have some time free up this next week to lend some feedback, Az.

EvanDonovan’s picture

azinck: Sorry, I've been working recently on a server upgrade, so I haven't had time to test the patch after all. It would take me more time since I already made hacks to the code, so I'd have to merge them back in.

mattwfx’s picture

subscribe

cyjambo’s picture

subscribe

mattwfx’s picture

Hi everyone and thanks azinck!!!
Patch working for me in version gigya-6.x-1.0-beta10. Now module doesn't repeats the user location block and Gigya start working with Mollom module too.
But i have now another problem. After login with any of social networks, module can't redirect to user page and showing this errors on top of the homepage:

warning: include_once(/modules/user/user.pages.inc) [function.include-once]: failed to open stream: No such file or directory in /home/<foldername>/<foldername>/sites/all/modules/gigya/gigya.pages.inc on line 102.

warning: include_once() [function.include]: Failed opening '/modules/user/user.pages.inc' for inclusion (include_path='.:/usr/local/whcp/php5/lib/php') in /home/<foldername>/<foldername>/sites/all/modules/gigya/gigya.pages.inc on line 102.

Where foldername = my private names of folders in path.
When I login with normal login form, page redirects me correctly and i don't see any errors. Where is problem? :/

Sorry for my English.

azinck’s picture

Thanks for the feedback and for bringing the redirection bug to my attention.

The warning you're seeing is harmless and can be remedied by simply commenting out line 102 of gigya.pages.inc -- it will be fixed in future releases.

mattwfx’s picture

Yes it's works. After commenting out line 102 of gigya.pages.inc errors disappeared. Thanks again azinck!

bcn’s picture

Wanted to cross-post here with a note of support for azinick's patch, which I used (with a few small changes) in a patch that I posted over at #533750: Improve support for Content Profile. I haven't found any problems yet, and wanted thank azinick for getting the ball rolling.

cheers!

azinck’s picture

Thanks for your work, noahb.

You mentioned you made a few small changes to my patch. Aside from adding content profile support, did you find/fix any other bugs in the patch? We're trying to get my work into the next release and while I've fixed a few bugs since posting the patch I'm curious if you found anything else that needs changing.

Thanks again.

8ballsaysiwin’s picture

Thanks for the patch azinck. I haven't found any additional bugs and have been testing for about a week.

bentoo42’s picture

I am having an issue where if you are logged in as a user that is not linked to a socialized account (i.e. the master admin user) and you click logout (which takes you to socialize-logout), you get redirected to the logout page which generates a WSOD. I think that perhaps the logout page is missing or its handler is overwritten. Any ideas how this can be fixed?

Should I create a new login page?

Note: I am using Gigya beta-10 and I have applied azinck's patch above which helps a ton.

azinck’s picture

StatusFileSize
new127.42 KB

bentoo,

There are some bugs in my patch relating to logout in some circumstances. There should be a new release out any day now with my original patch incorporated, the logout bugs fixed along with some other changes for more stability.

In the meantime I'll go ahead and give you a patch that incorporates all my latest code. This patch is again based on beta10 and should be applied *instead of* the previous patch.

minus’s picture

Hi

When users logon for the first time using their facebook ID they get this message
Fatal error: Call to undefined function dd() in /sites/all/modules/gigya/gigya.module on line 675

I applied this patch yesterday gigya-beta10-content-profile.patch 111.57 KB

Maybe this patch will solve this issue ?

Looking forward to the updated release.

Morten

azinck’s picture

@minus:

I haven't looked carefully at noahb's patch but it appears he left some debugging code in it; dd() is a debugging function that you don't have because you don't have the devel module installed. You can just comment out any lines that call dd. The patch I just posted will does not have support for content profile rolled into it so if you need that you'll have to stick with noahb's patch for now.

minus’s picture

ok, thanks :-)

bentoo42’s picture

Azinck,

Very much appreciated. Here is the website that I am using Gigya on http://ideapals.org . We are looking to launch as soon as we can get through some of the bugs. The one feature that I would love to have but is not supported in the module today is to be able to invite your friends from other social networks to join this site. For example, I would like to easily select some of my friends on facebook, and send them a mass-individual email letting them know about the launch of ideapals and inviting them to join.

As part of our contest on IdeaPals, we award points to users based on whether they invite people to our network. Having this work with the user points module and the invitation module would be amazing! Let me know if you have any ideas/suggestions in relation to this.

bentoo42’s picture

your patch file was truncated. :(

this is how it ends.

function gigya_newsfeed_action($object, $context) {
- global $base_path;
+ g

azinck’s picture

I just double-checked the uploaded file and it looks fine to me.

bcn’s picture

Status: Needs work » Needs review
StatusFileSize
new130.55 KB

@azinck Thanks for the updated patch... It applies nicely, and seems to work okay in the limited testing. It definitely is a functional step forward for this module. As for your earlier question, I didn't find any other problems with the changes you've made.

I went through and tried to clean up some white space and extra line breaks. There should be not actually code changes otherwise. I also used this new patch for the for the update over at #533750: Improve support for Content Profile.

I'm wondering though whether the size of this patch will make it difficult to get committed? I suppose we could break it up should that become an issue.

azinck’s picture

Well, as far as I know, the patch that I posted in 54 is basically going to be the next beta once Gigya completes some testing on it. Also, I can't take credit for all of #54. Tamir at Gigya added the ShareUI functionality.

michelle’s picture

Any insight on when the next beta might be? I'm very interested in Gigya but uncomfortable running it with a huge patch on my live site. Considering I use 3 of the 4 modules in the title and am planning on using the 4th plus content profile, I could really use this. :)

Michelle

8ballsaysiwin’s picture

Should rules running on "User account has been created" trigger now work with gigya with this patch?

azinck’s picture

@8ballsaysiwin:

Yes. The original module made a drupal_goto() call during login which interrupted the code flow and prevented the login hooks of other modules from being properly called. That is fixed in this patch.

EvanDonovan’s picture

Status: Needs review » Reviewed & tested by the community

I have now tested the patch in #54 and it seems to be working perfectly with my system (LoginToboggan + Legal), without requiring me to put profile fields in the user registration form. I was also able to eliminate some of the hacks I had made myself.
I have tested the following actions and they all worked as expected:

  1. Regular Login
  2. Regular Logout
  3. Regular Create Account
  4. Socialize Create Account
  5. Socialize Login
  6. Socialize Link Account
  7. Socialize Logout

I was especially glad to see that now when new users are created via Socialize they get real passwords, which are sent out via email. This is way better than my hack to the old Gigya account creation code (which was so messy that I didn't post it, presuming something better would come along).

I have tested the following identity providers and they all worked:

  • Facebook
  • Twitter
  • Google
  • AOL

Since I and others have reported that this patch works, I am marking it RTBC, in the hopes that it will be released as an official release soon, as per #62. Thanks to azinck & the Gigya team for their hard work in resolving these issues!

Gigya’s picture

Please use version 2 : http://drupal.org/node/720046

The Gigya team.

socialnicheguru’s picture

why did you get rid of the share with friends feature? is there another way to do this?
Also does it still work with popups? we had no issue with the popups at all.

Thanks.

minus’s picture

Version #2 is great.

Can we remove the facebook application created when using version #1 ? This is a little off topic, will there ever be possible to send updates to groups/pages? That would be awesome for companies etc.

Great upgrade Gigya!
Thank you :-)

Carl242’s picture

Subscribe - want to know when this will be in a release

edit: eating my words . . . i forgot to press "refresh" between last night and now, and it looks like you have made a release in that time! :)

azinck’s picture

Status: Reviewed & tested by the community » Fixed
8ballsaysiwin’s picture

I am using the newest version 2.0, and my rules do not seem to be evaluating on User account has been created... How do I fix this?

azinck’s picture

@8ballsaysiwin:
please open a new issue with specific information on the problem you're seeing.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.