See http://drupal.org/node/1420350 for the starting point. I have IP login and Remember me installed in the same site. When someone with an IP login match field, containing a value, logs in, Remember me records something in the user profile and calls user_save(). user_save() calls ip_login_user_update(). ip_login_user_update() wipes out the ip_login_match field.

I set up a temporary change to stop the problem but it is not a generic all cases fix. I added the following code to ignore the update if it is from Remember me. This will work with Remember me and can fail when other modules do something similar.

  if($category == 'remember-me') {
    watchdog('IP login', 'user update: Ignore update from Remember me');
    return;
  }
CommentFileSizeAuthor
#2 ip_login-7.x-2.0-rc1.user_update.patch1.26 KBpeterx

Comments

peterx’s picture

peterx commented
Title: Clash with Remember me » Clash with Remember me and anything else using user_save()

Possible fix 1:
The regular user update page has a category of account. You could process updates only from account. This is probably too limited because there are so many other modules out there.

Possible fix 2:
The regular user update returns $edit[ip_login_match] as s:0:"". The Remember me update returns $edit without $edit[ip_login_match]. You could ignore the update when $edit[ip_login_match] is not set. That could handle all updates where there is no form or the form is not displaying the IP login field. I switched to this method and it works for my tiny set of quick tests.

peterx’s picture

peterx commented
StatusFileSize
new ip_login-7.x-2.0-rc1.user_update.patch1.26 KB

Fix 2 as a patch.

jim kirkpatrick’s picture

jim kirkpatrick commented
Version: 7.x-2.0-rc1 » 6.x-2.x-dev
Status: Active » Patch (to be ported)

I've committed something based on your patch in #2, thank you.

There is a lot of excess comment text in your patches with your name in it (e.g. "2012-03-15 PeterMoulding.com test..."). This will always be removed... I've attributed you in the head of the module file and will again during release, so please do not add this extra cruft to the patch files as it just slows things down.

But thanks for the fix!... Needs testing and D6 backport.

jim kirkpatrick’s picture

jim kirkpatrick commented
Status: Patch (to be ported) » Fixed

Now applied to 6.x-2.0-dev.

peterx’s picture

peterx commented

Hello Jim, sorry about the excess comments. I put that sort of stuff in when I am one of many contractors and may not be on site when someone needs the code explained.

jim kirkpatrick’s picture

jim kirkpatrick commented

No worries! Hopefully you find the new dev releases solve your problems and make things a bit nicer... Please re-open this or any other issue if you spot anything.

I'll give this another couple of weeks for people to fully test and then push out RC2.

nickl’s picture

nickl commented
Version: 6.x-2.x-dev » 7.x-2.x-dev

Just my two cents, this issue was cross referenced to an unrelated issue on on the remember_me module by peterx which prompted me to come spend some time looking through your code to see if I can find such a relation... which I didn't.

Albeit faster won't it make compatibility with other modules simpler if you used user_sove to persist $user->login field.

     $user->login = time();
     db_update('users')
       ->fields(array('login' => $user->login))
       ->condition('uid', $user->uid)
       ->execute();

I am not sure how that will impact the rest of your design but Remember_me as do other modules use hook_user_presave() for example and by not calling user_sove you are bypassing the hook_system which might cause problems living with other modules, might also save you some grace.

Keep the spirits high!

Status: Fixed » Closed (fixed)

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