Manually insert user

Discussion in 'aMember Pro v.4' started by sportswar, Jun 19, 2013.

  1. sportswar

    sportswar New Member

    Joined:
    Mar 1, 2010
    Messages:
    7
    Hello CGI-Central,

    Need to manually insert users during a data migration into aMember 4. Which functions/parameters should we use to create compatible passwords to insert?

    $ph = new PasswordHash(8, false);

    $hash = $ph->HashPassword($newPass);

    This for example, does not seem to be working ...

    Thanks for any help.
  2. alex

    alex aMember Pro Customer Staff Member

    Joined:
    Jan 24, 2004
    Messages:
    6,021
    PHP:
    <?php
    require_once 'amember/bootstrap.php';
     
    $userTable Am_Di::getInstance()->userTable;
    $user $userTable->createRecord();
    $user->login 'xx';
    $user->setPass('111');
    $user->email 'a@a.c';
    $user->name_f 'Bob';
     
    $user->insert();
    // that is all
    echo "user_id = " $user->pk();
    ?>
  3. sportswar

    sportswar New Member

    Joined:
    Mar 1, 2010
    Messages:
    7
    I had to do some stuff remotely (without access to the aMember API)... I had attempted to use PasswordHash.php because it was portable.

    But everything worked out because I was able to use the REST API that aMember provides to insert users.

    Excellent.

    So basically I insert the user via POST variables and the REST API and then get the user ID back and use that to insert all of their subscriptions and other information.

    It's kind of a complicated import script because I'm actually pulling users out of two older architectures and inserting them into aMember 4. One of the older architectures is aMember 3, and the other one is some custom architecture.

    For CC information we were able to decrypt the am3 cc info which was stored in serialized PHP. It was no problem. The other old architecture that we have to work with stored CCs in plaintext ( Unhappy Face ).

    We were able to use the amember/library/Am/Crypt.php to encrypt the older CC information to insert it into aMember 4.

    The only issue I was worried about it that sometimes in the aMember 3 data, there were instances of the "state" field being abbreviated and sometimes there were instances where it was fully written out, such as "CA" / "California". I'm hoping this won't affect anything in our payment processing over in aMember 4.

    Besides that, so far everything has looked like it's gone through cleanly.

    Another question -- We're using the beta version of Payflow that you sent us awhile back... It's set to test mode. At some point could you look through our imported users and tell us if everything looks like it will work when we take the Payflow plugin out of test mode?

    Basically if everything looks like it came over okay, then we'll turn off our other two architecture's payment processing, then run our import script again, and finally take the payflow plugin out of test mode.

    I think everything will go very smoothly, but we have to be careful since we're working with around 70,000 users.

    Thanks a lot for all the help you've been giving us. The support from CGI-central is great!

Share This Page