In cases where the $edit array isn't populated with full user data (, fb_user_user_update is freaking out and failing to map the account. Additionally, throws error if the $edit['map'] variable simply doesn't exist.

Attached patch adds empty check for 'name' key before doing any processing, and empty check for 'map' key.

Comments

james.williams’s picture

StatusFileSize
new1.13 KB

The attached patch fixes the reference to fb-fixed in the original patch.

berliner’s picture

Status: Needs review » Reviewed & tested by the community

fixes the issue for me

james.williams’s picture

StatusFileSize
new1.45 KB

New version of the patch against master.

james.williams’s picture

StatusFileSize
new1.46 KB

sorry, I didn't update the newly renamed constant. Try the attached patch instead. :-(

rollingnet’s picture

This patch is working for me
Can someone else confirm that is working so to include it in the next dev version and avoid re-patching it every time a new fb dev version comes out?

giorgio79’s picture

Works for me as well.

rollingnet’s picture

In Nov, 8th dev version this issue is still present, so the above patch has to be re-applied

imoreno’s picture

this problem still consist
with the last dev 2011-Nov-10 + save-user-notice-1117214-4.patch

any suggestions how to bypass this?

dimon00’s picture

I tried the save-user-notice-1117214-4.patch on the last dev release (10 nov) and it is not working for me.

Any suggestion?

Thank you

Dave Cohen’s picture

Status: Reviewed & tested by the community » Needs work

How do you reproduce this? Is it an edit form with multiple tabs?

This bug must have been introduced in the upgrade to D7. In D6, this code only executes when the "category" is "fb_user".

In D7, it looks like something like that needs to still take effect. If the "map" is on the main user edit form, it has to be changed to "fb_user_map" or $form['fb_user']['#tree'] has to be set to true. In other words, it looks more broken that what this patch solves.

imoreno’s picture

Hi,
it reproduce with any simple login to the site with facebbok connect using an application. (new or exiting users)

If i'm disable user mapping - error is still on.

I have disable these problematic lines - and now the alert is gone for all users and all is functional.

BUT: if an adminstrator is accessing the site when he is loged to facebook a new user is created and it is not mapped to his user account - it just create a new one. (many of new accounts..)

Thank you for your kind help,
Itzhak

hawkeye217’s picture

Seeing the same error message with the latest -dev. Will the patch in #4 be committed, or should the issue be solved some other way?

SolomonGifford’s picture

I also get this error when calling user_save manually (in other modules) unless I add:

$edit['map'] = true;

I think fb_user_user_update should check for existence of map and ignore if it doesn't exist - otherwise use its value to continue the logic.

imoreno’s picture

Last 6/1/12 dev, problem still consist.

onegenius’s picture

When I am on the "admin/people" page.

I get the error after checking a user from the list of users and change his/her role or any other information.

That is, after I click the submit button.

Anonymous’s picture

On my site users seem to get this error when logged in. Any news on this?

laboratory.mike’s picture

I've been getting the same problem; it can be reproduced by having a user log in via Facebook, and then having an admin change their role OR by joining an OG group. It appears to be that the map is deleted whenever the user is edited. In order to fix this (on a low-traffic site), you can manually enter user and Facebook IDs into fb_user in the database as a means of manually fixing this.

UPDATE: I've found that if you check "Map account when both local uid and Facebook id are known" and do not check "Map account when Facebook email exactly matches local account," and you disable all theme overrides in admin/structure/fb/fb_connect, the mapping does not appear to be deleted when you change the user's roles or group audience. This loss of mapping may have something to do with these settings.

james.williams’s picture

@Dave Cohen (comment 10) -- the code is just implementing hook_user_update(), so it will happen whenever a user is updated, regardless of the 'category'. In D6 land, it was just operating under the old hook_user(), with the following check: elseif ($op == 'update' && $category == 'fb_user') { (link) so that would have only operated for the fb_user category as you said, but that check has gone missing in DFF's D7 version with the new hook.
With that in mind, the patch I provided in comment 4 probably just needs an additional check at the start to check the $category (assuming that is now set correctly), as well as the checks for empty() variables (which is how things should be done in the world of D7).

Dave Cohen’s picture

Issue tags: +get involved

I still don't get the same error. I'd be more comfortable with a fix if I could reproduce the original problem. That said, I see a few things wrong. I just don't know how in D7 to do what the module did in D6.

I see the fb_user 'map' checkbox appearing in all user forms, no matter which module has added them. That's bad.

The 'map' needs to change to 'fb_user_map' or nested underneath an 'fb_user' data structure. 'map' alone is asking for a name collision with another module.

Finally I like the suggestion in #13 that it should not change the fb_user table unless that 'fb_user_map' is actually set (to an $fbu or to FALSE).

So this is still needs work. And I plan to work on it (unless someone else wants to do the above). Before I do, does anyone know the "right way" in D7 to upgrade a user category from D6?

Dave Cohen’s picture

Status: Needs work » Needs review
StatusFileSize
new4.04 KB

There's reason to believe this is more than just a PHP notice. I might be the cause of #974886: Duplicate User Accounts Created. So please test this patch ASAP.

Thanks.

Also, I'm now aware of hook_user_categories(), but I think this particular item might be better left on the main account form. Feel free to weigh in with opinions.

james.williams’s picture

StatusFileSize
new4.05 KB

Thanks Dave for taking a good look at this. I think you might have missed replacing one of the $edit['map']? Attached patch just changes that. Looks good though otherwise (I haven't actually tested it yet though).

imoreno’s picture

Hi Dave,
With the new DEV release for D7, this message is still there, but the main issue is that the user mapping is broken.
so one can login to the site, all is working, blocks, permissions, etc. BUT the Drupal CMS does not recognize the user as loged, and he is unable to comment, write and so on.

Did the patch on #4 made it to the new 14/3/12 dev release ?

Itzhak

james.williams’s picture

@ imoreno - none of the patches in this thread are in any of the releases or code yet. Download the latest DEV release for D7 and apply the latest patch in this thread, and test with that.

imoreno’s picture

More info,
patch of james.williams on #21 did eliminate the message and that is good.
on the other hand, users are still not being mapped and can not use drupal once they are authenticated with FB connect.
Maybe this is just not working for me... will keep trying.

imoreno’s picture

All is working OK for me,
Dave, i think this patch fb_user_form_alter-1117214-21.diff should be committed, so you will be able to close this one as well.

Itzhak

lucascaro’s picture

just confirming that the patch #21 removed the error message for me too...

Dave Cohen’s picture

Status: Needs review » Fixed

Great! Pushed to git.

Thanks everyone!

(Nice catch James, that I missed an important 'map')

Status: Fixed » Closed (fixed)
Issue tags: -get involved

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