Improve support for Content Profile

I second this, at least in theory. The question is what is the best way to achieve this, since the content profile is just a node with a collection of CCK fields, and there can be multiple node types enabled as content profiles (on my site I have 4 different content profile node types, one or more of which can be created by a particular user based on their assigned user roles).

Again +1 for this please.

I totally agree, however currently this is outside of the project's original scope . If anybody from the community would like to help make the module support that, Gigya and Acquia will be glad to help.

+1

Marking postponed. If somebody would like to work on this please feel free to change the state when the work is underway.

What would something like that cost to develop? Perhaps if there's enough interest and a developer would step forward, we could support the effort. Any interest?

+1

+1

I would pay something for this

Who wants to build it?

I am not sure that this issue is still relevant. Slide 44 of what's coming with Drupal 7.0 seems to imply that Content Profile will be going away. See the slide show at http://webchick.net/files/presentations/drupal-7-drupalcon-paris-2009-09... [12.5 MB].

Thoughts?

Indeed the Drupal 7 version of the Gigya module would not need to integrate with a module like Content Profile.

This doesn't solve the problem for sites on Drupal 6 however.

What has to happen is the code that looks at which fields are available on the registration form needs to be expanded to include a check for Content Profile and use its functions to assess what fields are available for mapping in the Admin interface.

I would love this.

Chris

I like that a lot - clever solution !

Anyone willing to get this done? We have some budget to get this done, please post here or pm me. We want this quite fast!

bennos had a good idea. However, EMF is built upon a reversed use case: it takes the external service as the "target" for the info, considering Drupal as the "source".

In this case, Gigya is the source, and Drupal data structures are the target.

We need to _write_ in those Drupal data structures, not read.

If we are to replicate EMF's code in the gigya code, then we would be leaving it up to the users of the module to write special PHP code to write into the Drupal fields, and that doesn't seem very usable solution to me... thoughts?

We would just add the case for D6 Content Profile.

Thanks bennos.

Data types are:
- alphanumeric (nickname, email, first name, last name, age, city, state, country, zip)
- date (birthdate, it's actually 3 numeric fields, month, day, year)
- select list (gender, 'm' or 'f')

Now, I tried birthdate and the data is not being received properly from the Gigya Socialize Service (at least, Yahoo/Google/Facebook). Or, I'm having privacy issues with the user I was using in those services... in any case, birthdate is the most difficult to map and import...

With kind sponsorship from Demotix, via OpenlyConnected, developed by Colaborativa.net, I'm hereby submitting this patch and related documentation to the community for revision.

Installation instructions

1. Change directory to sites/all/modules/gigya and apply the patch
2. Run drush updatedb or point your browser to http://www.example.com/update.php
3. Have your Content Profile configured for any or all of these fields: first name, last name, age, city, state, country, zip, birthdate, gender
4. Go to admin/settings/gigya and configure the mappings at the bottom of the screen.

Features

• Adds Content Profile fields to the list of fields available for mapping (see this screenshot)
• Allows for drupal username to be mapped to gigya nickname
• Preserves previous (core profile) mappings
• Updates weight of the module automatically (needs to execute after content profile registration)

Known issues

• Birth date pre-complete is not working properly.
• Login providers from gigya (Yahoo/Facebook, etc.) do not seem to be sending the birth date info properly.

Attaching screencap (the d.o. way)

which version of gigya did you patch against?

I used both of these versions:
Version Downloads Date Links
6.x-1.0-beta9 Download (47.61 KB) 2009-Dec-03 Notes
Development releases

Version Downloads Date Links
6.x-1.x-dev Download (49.79 KB) 2009-Dec-27 Notes

I got this:
$ patch -p0 < gigya-cp.patch.txt
patching file gigya.admin.inc
Hunk #1 succeeded at 552 (offset 18 lines).
Hunk #2 succeeded at 567 (offset 18 lines).
Hunk #3 succeeded at 577 with fuzz 1 (offset 18 lines).
patching file gigya.module
Hunk #1 succeeded at 871 with fuzz 2 (offset 333 lines).
Hunk #2 FAILED at 881.
Hunk #3 FAILED at 892.
2 out of 3 hunks FAILED -- saving rejects to file gigya.module.rej
patching file gigya.install
Hunk #1 succeeded at 111 (offset 3 lines).

*** 880,888 ****
if ($profiles && $profiles[$category['name']]) {
foreach($form[$cat_name] as $arr_name => $arr_val) {
if (is_array($arr_val)) {
- if (variable_get('gigya_profile_'. $arr_name, '') != '0') {
- $bio_assoc = variable_get('gigya_profile_'. $arr_name, '');
- $form[$cat_name][$arr_name]['#default_value'] = $bio[$bio_ass
oc];
}
}
}
--- 881,890 ----
if ($profiles && $profiles[$category['name']]) {
foreach($form[$cat_name] as $arr_name => $arr_val) {
if (is_array($arr_val)) {
+ foreach (_gigya_get_profile_fields() as $field_key => $field_na
me) {
+ if ($arr_name == variable_get('gigya_bio_'. $field_name, ''))
{
+ $form[$cat_name][$arr_name]['#default_value'] = $bio[$field
_name];
+ }
}
}
}
***************
*** 890,895 ****
}
}
}
unset($form['account']['pass']);
unset($form['pass']);
$form['mail']['#required'] = FALSE;
--- 892,941 ----
}
}
}
+
+ // TODO remove this dd
+ // dd('------Loop------');
+ foreach (_gigya_get_profile_fields() as $field_key => $field_name) {
+ if (!isset($bio[$field_name]))
+ continue; // skip empty values from XML call
+ $var_name = 'gigya_bio_'. $field_name;
+ $mapped_field = variable_get($var_name, '');
+ /* TODO remove these drupal debug
+ dd('----Field item----');
+ dd('----var_name:'); dd($var_name);
+ dd('----mapped_field:'); dd ('"' . $mapped_field . '"');
+ dd('----value:'); dd ($bio[$field_name]);
+ dd('END Field item----');
+ */
+ if (strpos($mapped_field, 'field_') === 0) {
+ if ($var_name == 'gigya_bio_birthMonth' || $var_name == 'gigya_bio_birt
hDay' || $var_name == 'gigya_bio_birthYear') {
+ // date parts go to a birthdate CCK field
+ $form[$mapped_field][0]['#default_value'] = array('month' => $bio['bi
rthMonth'], 'day' => $bio['birthMonth'], 'year' => $bio['birthYear']);
+ }
+ else {
+ if (strpos($var_name, 'gigya_bio_gender') === 0) {
+ // Gender CCK field, must have keys 'm' and 'f'. Labels can be what
ever needed.
+ $form[$mapped_field]['#default_value'][0]['value'] = $bio[$field_na
me];
+ }
+ else {
+ // Regular text CCK field
+ $form[$mapped_field][0]['#default_value']['value'] = $bio[$field_na
me];
+ }
+ }
+ }
+ elseif (strpos($mapped_field, 'username') === 0) {
+ // when nickname is mapped to username
+ $form['account']['name']['#default_value'] = $bio[$field_name];
+ // TODO remove this dd
+ // dd('username!'); dd($form['account']['name']);
+ }
+ }
+ // TODO remove this dd
+ // dd('------END Loop------');
+
+ // TODO remove this dd
+ dd('---Form!'); dd($form);
+

The patch is against beta7. I could to re-roll the patch against the latest dev before next week.

Ok, I've been looking into the beta10 release (which is not displayed in the front page of the module BTW, I managed to update to beta10 via drush).

After merging the patch manually, the feature is not working ==> the code in beta10 renders the patch useless.

The code in beta10 adds a "weiner" function in pages.inc gigya_link_accounts_or_register_form() that simply doesn't look good, and it's the main reason why our contributed is not working after the merge. So I went further and looked into the issue queue, and stumbled upon #647334: Gigya user registration form override causes issues w/Organic Groups, User Location, Legal, LoginToboggan considered "critical".

As you see, there is a critical problem with many other modules, precisely in the registration form of Gigya, so it seems this feature will have to wait until the code gets stable enough as a code tagged "beta" should be, so we can contribute to.

As a workaround, I may suggest using beta7 and applying the patch for testing the functionality and review. However, considering the release notes of the subsequent releases, I'd not use beta7 on a production site due to a security issue, and many other important bugs. Please refer to the releases page to download beta7 and check the subsequent releases.

Cross-posted to #647334: Gigya user registration form override causes issues w/Organic Groups, User Location, Legal, LoginToboggan

Subscribe -

It sounds like the patch works for Beta 7, but not for the most recent v10.

What is the recommended course of action?

-CarbonPig

CarbonPig, at the moment, not really sure. azinck has made a patch here http://drupal.org/node/647334#comment-2443452 which is said to improve the module a fair bit - but its pushing it back to alpha status. I would test his patch and feed back in that thread, as that is, i think, our best chance of getting this module working and stable.

I hope Gigya are following the communities efforts here and merge his changes in soon, test them and get this module stable. From our site alone they are missing out on 10,000 potential new users to their service.

here's a patch against beta-10, including the most of the patch from #647334: Gigya user registration form override causes issues w/Organic Groups, User Location, Legal, LoginToboggan. It also has a few changes to account for more than one content profile. There are still lots of problems, and I'm not even sure this patch is the best direction. but...have fun.

PS
This patch may do bad things to your kittens.

updated...

I tried the latest path but I don't think it's working.

I have a content profile type. I went and set some of the fields to display on registration, but they don't display.

per #30

subscribing--love to see this in a release :)

is this included in gigya version 2 that just came out?

don't believe so. other problems were fixed, like compatibility with logiontoboggan, mollum, etc, but no fields are auto-populated with my content-profile based site. I'm reluctant to use the patches because a) i'm a noob, and b) they were made for versions earlier than 2.0, and I think there was a hefty amount of code change in 2.0.

I could look into re-rolling this patch to work with the latest release, but I'd like to first get some feedback from the maintainers whether they would consider this for inclusion before I go ahead and re-roll.

Gigya - August 12, 2009 - 22:20
I totally agree, however currently this is outside of the project's original scope . If anybody from the community would like to help make the module support that, Gigya and Acquia will be glad to help.

We funded the production of the patch #20 and would very much like to see that investment come good and be able to start using the module. Hopefully Gigya will come back in and confirm their commitment to this module and its success.

Please do re-roll the patch.

Could you re-roll against gigya v2?

After having it confirmed that no help would be coming from Acquia (http://drupal.org/node/743162), despite comment 3, and Gigya totally ignoring this issue, other issues in this queue, emails and contact form submissions - i'm giving up and looking into alternatives.

A shame too, as i thought their service had promise.

I am also quite disapointed

We also use Content Profile on our site, although we don't need to integrate into the initial registration workflow. If I have time, I will see if a version of the patch from #28 or #29 can be re-rolled for compatibility with 2.x + #742430: Patch to fix several bugs.

Setting status to "patch (to be ported)" and moving to the 2.x branch.

Just bumping since I want this to be the first thing to get in on the roadmap after #742430: Patch to fix several bugs and some of the code cleanup. See #743162: WARNING: Gigya module is currently poorly supported/needs new stable branch for why we are in this state currently.

I have ported the patch from #20 to the new stable release (6.x-2.1). All I guarantee is that the patch applies cleanly, and it does not seem to break the module's core functionality.

On my install, I have also gotten the patched version of the code to see the textual fields in my Content Profile content type. However, I have not gotten this patch to actually create a new content profile for a user who registers.

Still I thought I would submit this patch, as it will at least provide a base from which we can work.

Setting to "needs review" - I know that it most likely "needs work", but I would appreciate if people can test this first. Maybe if your Content Profile set up is very standard, unlike mine, it will work.

The level of kittens killed by this patch is dramatically reduced from the re-roll from #28, though I used that as a guide in my porting process.

Very cool, thanks Evan. Truth be told, I hadn't even peeked at this patch yet so I'm glad you took a stab.

azinck: Yes, you should just be able to apply my patch and then test. (Note: I don't actually know how the patch works; I just ported it to the latest version so it would apply.)

I think the best way to test would be:

1) Create a new Drupal site.
2) Set up a Socialize API key & social network linkages for that site.
3) Download & install Content Profile.
4) Create a Content Profile content type & add CCK fields that match up with the screenshot in #21. (Note that the gender fields apparently have to have keys of "m" & "f" - I didn't test that part.
5) Install Gigya Socialize 6.x-2.1.
6) Apply the patch.
7) Try creating a user & see if a content profile is created for that user, and populated correctly.

If that's too complex, you could just try testing on an existing site with Content Profile enabled. Of course, anyone else can test this too - a_c_m, especially, might be interested :)

subscribe

Would love to be ale to use this.

@all the people who said "subscribing":

Would you be comfortable testing the patch? I can help if you need it - find me on #drupal IRC sometime. The patch will be more likely to get committed if it has testing. I wasn't able to test it fully since my site is too customized, and I don't believe azinck is using content_profile.module himself.

I've set up a test bed and the patch doesn't appear to work in its current form. I'm working on fixing it...

i could probably set up a clean site to test on in a few days.. the current site i'd like to use this with is also pretty customized as well

I will do more work on this patch in the next couple of days but here's something that at least appears to me to be functional. Please test and give feedback.

Too bad that it doesn't work. I hoped that it might work on a basic install of Content Profile. I don't know where the problem comes in; I hoped I had done pretty much a straight re-roll of the earlier version's patch.

Sorry for the crosspost. I was referring to my earlier re-roll. azinck's new patch needs review.

subscribe

FYI, this is in dev -- please test and give feedback so that we can get some data before making a release.

Ah, good to know that this is in -dev. I probably won't be able to test until next week at the earliest, though.

g8 work EvanDonovan & azinck...........:).......cant wait to test/ implement it........:).......

do see to integrate it with date & location module as well...........it can help more.......:).......

marking as fixed unless I hear otherwise

I haven't investigated bennos' complaint but there's at least one other thing that needs to be improved in our Content Profile support. We need to switch around the mapping so that Gigya fields are mapped into Content Profile fields, rather than the other way around. In fact, in an ideal world we'd do this with tokens rather than crude direct mappings.

is this implemented in v2.2 because i do see the cck fields in the drupal profile field mapping...?

lasac:
Content Profile support is in 2.2, but my comment #60 was just listing the ways it needs to be improved. If what's in there now works for you, then great!

azinck: well actually it doesn't work, the gender nor the date birth, well actually no field gets populated.

subscribing, will try and test this out when i get a chance.

Here's a stab at it and should be a significant improvement. This patch is against dev. The Token module is now required for profile mapping.

• Added Gigya Tokens (these can actually be used in many other contexts and should be helpful)
• Mappings are now completely different. You can map arbitrary text with tokens into the username and email fields and any Drupal core Profile field or Content Profile field that has been configured to display on the registration form.
• There should be no problem with multiple Content Profile content types
• You can only map values into fields configured to display on the user registration form. I'm planning to add back the ability to map values to other fields eventually but there are still some difficulties that need ironing out.
• I've tested this with a smattering of different CCK field types and input widgets with success but it's very possible (likely?) that there are some that will break it. I'm still getting the hang of form_alter with CCK fields. If anyone has expertise in that area, please contribute or at least contact me!

I'd love to get this tested as much as possible. Please report any problems you have on this issue.

I've just gone through and done a style cleanup on the patch. No substantive changes at all. Will poke it hard with a stick and report back.

Well I really like the idea of adding token support :) I'm taking a look to see if I have any feedback to provide.

I tried the patch out. I have content profile set up with several fields, some text, some numeric, one for the gender field with 'm' and 'f' as the keys as noted above.

I realized I have to enable the Token module and configure Content Profile to show my fields on the registration form. That allows me to set up tokens for my fields. I didn't have those enabled/set up before this patch, but I finally realized that much.

So far so good.

I try to log in via a social network. It takes me to a registration form with my content profile fields on it, but none of my token values seem to have worked, all the fields are blank.

I suspect I am missing something in the setup. Do I need to enable something else, Token Actions perhaps?

Once I get past that, I can't figure out where to look in the code to see how the substitutions are handled. I was going to see if I have any feedback on the CCK handling. I have buried down several levels deep but can't find it.

@KarenS: did you try the previous version, prior to the addition of token support? There were reports that that one worked, with CCK + Content Profile.

Thanks for looking into this, KarenS. I'm away on vacation right now so I'm sorry for the brief response. I'm not sure why you're not getting the replacement. It's definitely working on my installation. I've mainly tested with Facebook, so maybe give that a try?

The replacement is occurring in gigya_form_alter for the registration form, where it calls array_walk()

Thanks again.

Also: no, you don't need token actions.

Try just sticking static text in for the replacements (no tokens) to check if the replacement is happening.

When using the dev version the Gigya login block does not display linked icons to allow login. These icons show up in 6.x-2.2. Any ideas on why?

azinck: since we need to display the fields on the registration field, to populate them. Would there be a way to only show the fields we want to populate when users use the gigya module?

Let say.
User A presses the register button on the website and gets send to the registration page and presses on of the gigya buttons, they enter there (let say facebook) info and get send to a special registration form just for users who try to register trough gigya. There the fields that need to be populated are shown, user checks them and presses register, done.

User B presses the register button on the website and gets send to the registration form, but this users does not want to register trough gigya so he does not press any gigya button and just sees the basic, small, registration form. He registers and done.

lasac: We won't be supporting the workflow you suggest. Instead, I will be working to add support for populating fields that aren't visible on the registration form.

BTW, did this patch work for you?

yankeemoose02: I'm not sure why you're not seeing the icons. Do you have a test site I can look at? Try visiting the gigya settings page and clicking save, even if you didn't change any settings. Also, be sure to run update.php

azinck: that offcourse would be even better. I did not try the patch for it stated that it only populates the registration fields.

Just to report back so far, I haven't gotten the content profile fields to work either. When I go to create a new account, the username and email fields are filled in, but none of my additional fields (just textfields right now) are being populated. :-/ Still figuring out why not.

add1sum: you do have mapped out what info goes in which field, right?

@lasac, yes. Have you tried the patch yet and if so, is it working for you?

add1sun: Have you tried simply mapping plain text into your extra fields? That would take any social network privacy or other API issues out of the equation.

OK, azink and I were poking at this together and realized that it is a module weight issue. You need to weight Gigya heavier than Content Profile Registration (which sets itself to 1). Once I changed the Gigya weight to 2 in the system table, it magically worked. ;-)

I did a tiny bit more clean up to help get rid of notices and included an update hook to set the module weight heavier than content profile registration. Make sure you run update.php to test the patch on an existing install.

We're still poking around to see if it is possible to get this to work without the module weight, but for now, at least this should help people test the underlying functionality we are trying to look at.

Mixed success so far. I create profile fields for gender, birth month (just an integer, didn't try any fancy date stuff), first name and last name. I see that different services are expected to only provide certain info, so I know some of the problem is that I'm trying to access info that service doesn't provide. But I'm not sure I'm even getting what I was supposed to get.

And then I realized it's really hard to test this because some services only provide specific bits of information AND you have to have set those bits up in your account.

It's hard to figure out a good way to test this. How do you suggest testing it? I'm starting to think I need to set up a dummy account on various networks that has every possible bit of information filled out on the social network side and then test that it comes across when I register.

Also, what is the best way to unset things and start over to re-test? If I delete the test user account completely will Gigya 'forget' what it knows so I can test how a fresh registration would behave?

I'm wondering how to make this all more clear to other site administrators, who are going to trip up on the same things -- thinking it is broken when perhaps it is just a bit of information that the network does not provide or that has not been filled out.

OK, did the dummy account thing and had pretty good success. The token fields get filled in properly. I figured out the Facebook account I tried earlier had gender and birthday info, but I had indicated it should not be displayed on my profile, which probably kept it from coming across.

I think the patch is working. I'm still thinking it will be important to have some good documentation about what will and won't work -- which networks provide what information and that nothing will show up if it wasn't filled out or the user chose not to allow it to be displayed.

KarenS: When you are on the profile, there is a additional tab i think it's called gigya. Click it and you will see the info that the gigya module got from the other service. This way you can easly check if the fields got popuplated.

KarenS:

I'm glad you got it working!

You're right, configuration of this is not trivial. There are a lot of ways for an admin to get confused. Documentation will be important.

Have you had a chance to take a look at the code that populates the CCK fields? I'm using form_alter; is that my best bet? I didn't see any way to hook into the field generation earlier in the process. Also, the relatively inconsistent structure of #default_value for different cck fields makes me wonder if I'm doing it correctly. Check out gigya_apply_profile_mapping() in gigya.inc for the mapping code.

this patch still not makes it popuplate the field that are not in the registration field right?

lasac:

Correct.

I spoke with Karen and it looks like module weight is what we'll need to roll with (and overall the code looks sane to her). So, I'd say it's time to branch and apply this patch. We'll need to work on documenting this well to stave off lots of confusing support requests. Any future issues/bugs/features around Content Profile should be opened in new issues.

@azinck, there are various ways to hook into the CCK fields. What you have done so far seems to work, at least for simple fields. I suspect we will find ways to improve on this going forward, but I don't think that has to derail this ticket, since getting this much done will fix things in many situations. We can open other tickets if we find better ways to do this.

BTW I really like the addition of token support, it's a nice clean way of handling the mapping.

This has been committed to HEAD. There will be a new dev tarball for this, 6.x-3.x-dev, once the 12-hour dev cron runs.