I've been working on fixing several bugs in the module so rather than attempt to break the fixes out into separate patches I'll create a home for them here. I've attempted the following:

- #615350: Add block with just the Gigya login - Added a separate Gigya login block. It could use some work but it's there. As of now 2 Gigya login blocks on the same page aren't supported and won't work, so be sure to hide the dedicated gigya login block when the user is at user/login
- #720130: Gigya 2.0 removes the password field on use account pages - No longer hides password changing forms
- Properly escaped text being fed to the ShareUI component (component would fail to show in some cases due to the improper escaping)
- Prevented the ShareUI component from scrolling off the top of the page when used on a page with an anchor (#) in the URL.
- Made the module compatible with the Services module (there's no functional integration with the services module but the way this module implemented a hook caused the Services module to fail)
- Fixed a timezone bug; it would switch to GMT for certain page requests which had the potential to wreak havoc on other modules.
- Module now maintains the "destination" variable all the way through login/registration. Unfortunately one side effect of this appears to be broken compatibility with Google Chrome. This seems to be a javascript problem in the Gigya API itself. I'll be looking into it further.
- Marginally improved the theming layer. We still need to break it out to use tpl files.
- Changed the Account->Edit->Social Networks page to use the ConnectUI instead of the EditConnectionsUI. This may turn out to be the most controversial aspect of this patch but the EditConnectionsUI is what you see when you click "edit" from the ConnectUI. And the EditConnectionsUI has an "OK" button on the bottom of it that makes sense in the context of its being a popup, but which was confusing when the control was embedded on the page. Also might address this? : #698732: I can't see anything in Social Networks tab in User Edit
- Added a block for the Connect UI. This is just like the gigya login block in that it fails if there are two of them on the same page so be careful to ensure that never happens. Also, you may not want to allow non-authenticated users to see the block since in the context of this module connections are really only useful to authenticated users (as a way to link up accounts for alternate means of authentication).
- Fixed a handful of other small bugs

The patch is based on version 2.0

Please test and give feedback.

Gigya: would you consider integrating these into the next version of the module?

CommentFileSizeAuthor
#1 gigya_742430.patch59.48 KBazinck

Comments

azinck’s picture

azinck commented
StatusFileSize
new gigya_742430.patch59.48 KB
Anonymous’s picture

Anonymous (not verified) commented

Good job! I'm going to test this on a few sites. Recently I've started to add Gigya to several sites, to see what the effects are. Hope to do some testing this week for the patch.

I love the ConnectUI Block!

EvanDonovan’s picture

EvanDonovan commented

azinck: Thanks so much. I will try to test this today. Not sure if it's best to have one mega patch, instead of filing separate issues & having a meta-issue to coordinate work on them, though.

I have really appreciated the work that you did in pushing to 2.0. Now that LoginToboggan works with Gigya, I think I can actually implement it on my site (once some of these other bugs are resolved).

azinck’s picture

azinck commented

Thanks for the feedback, EvanDonovan

I wasn't sure the best way to release this. To be honest, I just didn't want to spend the time to break out all of the fixes into discrete patches (not sure it would have been all that possible anyways). Hopefully it's useful in this format.

EvanDonovan’s picture

EvanDonovan commented

I've started testing & it seems to be working well so far. Thanks for these fixes - particularly to the connectUI block.

On my particular site, I didn't like the (large) text that said "Login using social networks" on the user login block, and I wanted it below the password field, so I switched the code to

$form['pass']['#suffix'] .= theme('gigya_login_block', $item, TRUE);

on line 680 of gigya.module.

By the way, is there a way to get the Gigya module to use the non-Flash version of the Gigya widgets? Or do I have to code that myself. I'd prefer not to use Flash if possible.

EvanDonovan’s picture

EvanDonovan commented
Status: Needs review » Needs work

Actually, I spoke too soon. The Gigya login links (FB, Twitter, etc.) are not working now. They say they are connecting you, but they actually are not. You stay anonymous.

So I am going to rollback to the original 2.0 code, since that was mostly working for me.

Would it be possible for you to break out the fixes for #720130: Gigya 2.0 removes the password field on use account pages and #698732: I can't see anything in Social Networks tab in User Edit into separate patches, and post them to their respective issues? Then we can turn this issue into a meta-issue for coordinating work, as I suggested in #1.

I didn't want to insist upon that before, but now that I see that this patch causes problems, at least for me, I think it will stand much more chance of being committed if it is evaluated on a component-by-component basis. That is the way that things are done in the Drupal community ordinarily.

azinck’s picture

azinck commented

Hi EvanDonovan,

Are you sure you're using the login block and not the connect block to login?

azinck’s picture

azinck commented

Also, just to be on the safe side would you clear your cache and run update.php? I'm not sure why you're seeing the problem you describe; I'm having no issues with that.

EvanDonovan’s picture

EvanDonovan commented

@all:

azinck & I are currently in discussions on testing this patch. Stay tuned for more results.

EvanDonovan’s picture

EvanDonovan commented
Status: Needs work » Needs review

The patch works for me now, after running update.php & saving admin/settings/gigya again.

However, I have one concern: The ConnectUI, unlike the EditConnectionsUI, does not have an option to unlink accounts. This, in my mind, is a critical feature.

(Just as I was writing this, I discovered you can load the EditConnectionsUI from the ConnectUI by clicking the tiny "Edit" link. It's too small I think for people to see, though. I'll look into whether customization can be done of the ConnectUI to make that bigger.)

I am bringing this back up to "needs review" so that others can test. It is not perfect, by any means, but I think it can allow you to have a functional implementation of Gigya on your Drupal site.

EvanDonovan’s picture

EvanDonovan commented

Another thing I forgot to mention: for some reason, I can't get the user/[uid]/edit/gigya page to work with this page when $scripts *is* in the <head>. But that may just be a fluke of my system - I have a lot of contrib modules installed....

EvanDonovan’s picture

EvanDonovan commented
Status: Needs review » Reviewed & tested by the community

This patch is working on my site...need to push this forward, so I'm marking as RTBC. Possibly we should consider starting a new branch, but incorporating #533750: Improve support for Content Profile, if possible. (I use Content Profile also, but don't need to populate it during registration.)

EvanDonovan’s picture

EvanDonovan commented

For all those who come here from other issues, remember: this patch has been made necessary by #743162: WARNING: Gigya module is currently poorly supported/needs new stable branch. We need to try to get a stable release, and I think that if people can use this patch, that is the best option for now, until a new branch can be made.

Remon’s picture

Remon commented

subscribe

Canine Coaches’s picture

Canine Coaches commented

subscribing

vacilando’s picture

vacilando commented

Subscribing.

azinck’s picture

azinck commented
Status: Reviewed & tested by the community » Fixed
EvanDonovan’s picture

EvanDonovan commented

a big +1 to azinck for committing his own patch :)

Status: Fixed » Closed (fixed)

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