While programmatically importing thousands of users from an old site, I'm facing this very strange behaviour. The code snippet below correctly attach commerce customer profiles to the created users on localhost site, but attach them to uid 1 on production site !

localhost is a strict copy of remote site : git clone for code and Backup and Migrate DB copy The users are imported uploading and parsing a csv file in a custom form, connected as admin

$new_user = array(
  'name' => $new_name,
  'pass' => $pwd,
  'mail' => $email,
  'init' => $email,
  'status' => 1,

$account = new stdClass;
$account->roles = array(
  DRUPAL_AUTHENTICATED_RID => 'authenticated user',
  9 => 'client',

if ($saved_user = user_save($account, $new_user)) {
  dpm($saved_user, $new_name.'/'.$saved_user->uid );
  //VERY STRANGE HERE (ON PROD SITE ONLY) see screen capture below
  //the dpm title prints $saved_user->uid as a new uid
  //but "inside" dpm $saved_user->uid is 1 ! 

//create user commerce profile
$profile = commerce_customer_profile_new('billing', $saved_user->uid);
$profile_wrapper = entity_metadata_wrapper('commerce_customer_profile', $profile);
//... add profile values ...

Localhost : expected uid when dpm($saved_user, $new_name.'/'.$saved_user->uid ); enter image description here

Production site : uid 1 instead. The user is created with the new uid though, but uid 1 is passed then to commerce customer profile enter image description here

  • Just curious for troubleshooting, what if you try to reload the user using user_load_by_mail($email)? I don't think it is the solution, just wondering if you get the correct results. – Quint Oct 26 '15 at 20:46
  • Tks, Quint. This doesn't change anything, AFAI understand where you'd like to reload it. Be what it is, it is this behaviour itself I'd like to understand. It is a kind of non sense : I restored from remote DB again and triple checked git statuses and files are absolutely the same... – Kojo Oct 26 '15 at 21:26
  • 1
    Like I said, just for troubleshooting. It isn't about changing anything, it is about trying to track down where strange stuff happens. Are you logged in as user 1? If you login as a different user with admin rights do you end up getting the uid of the logged in user? What have you tried at this point beyond restoring from backup? I may be wrong, but I don't think there is going to be a quick and easy answer for this one. – Quint Oct 27 '15 at 3:39
  • I appreciate your help, Quint. In fact, I tried different ways to save and reload user Object, ending always with the same. For the sake of understanding, I'll do further tests ASAP, but yesterday night I had to solve it yes or yes, so I used hard method : maintenance mode, installed backup DB on localhost, ran script, and restored modified DB on production!!! Dirty method, but people were sleeping at that time... – Kojo Oct 27 '15 at 11:20

Sounds like somewhere in the first few lines of code your $account variable is getting switched to the user 1 or perhaps the currently logged in user. Perhaps trying to change the "$account" variable name to something definitely unique to see if that fixes the problem.

  • 1
    Thanks Josh for your contribution. This is almost an old history now, I switched to other project, but I remember I discovered casually that the difference between dev and live site causing the mistake, was maintenance mode. In maintenance mode wrong uid was passed to commerce profile during the script execution. Don't know why though :( – Kojo Jan 28 '16 at 14:19
  • 1
    Good follow up. Weird bug. Yeah, a project from October of last year? Ancient history ;) – joshmiller Jan 28 '16 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.