Jump to content
chuckymendoza

Import/Export of user

Recommended Posts

Hello together,

I had a deeper look into the forum but didn’t found anything, so I like to ask the following simple question. :-)

Is there a module or a simple technique to export all users from the backend into a file?

Afterwards, it should be possible to import the users again.

I have a ProcessWire installation on a dev server and I don’t like the idea to add all users again by hand on the live server   :-)

Thanks so much for your ideas.

-Thomas 

Share this post


Link to post
Share on other sites

While it's certainly possible it's not as easy as you may think it is. Passwords are stored as hashes in the database. ProcessWire will never store the plain text password. The hashing is dependent on the salt value stored in the config.php. The salt is generated as part of the installation process and therefore your live installation may have another salt value as the dev one. If this is the case it means all the passwords of imported users would be invalid after moving them. What you can do is to copy the whole users database table and copy over the salt value, too. As long as all hashes of user passwords are generated with the same salt value you can exchange users as you wish. But if you have users in both installations, where the passwords where saved with different salt values, you can not move the passwords over from one installation to another. You would need to change/update the passwords by hand in this case. Everything besides the passwords shouldn't be a problem.

  • Like 6

Share this post


Link to post
Share on other sites

I am trying to find a solution for having same users with same passwords in 2 different PW installs and came across this thread.

How would I export the user table? There is no such table as users are pages. So  I would need to construct a MySQL query that gets all pages with user template and also grab required fields  name, pass, email.

Then the other tricky part would be to import that into the new PW install.

Is there a PW API side solution that also tranfers the password hashes to the new install?

Share this post


Link to post
Share on other sites

I think you should be able to read the hashed password to export them, e.g. with the PageActionExportCsv which comes with listerpro. I'm just not sure if those hashed passwords would be rehashed, when importing the csv.

Share this post


Link to post
Share on other sites

@LostKobraKai

Thank you. I will look into the Lister Pro Action.

Meanwhile I decided to export the users including their hashed password to csv with

// get desired users
$array = [];
$us = $users->find("roles=frontend");
foreach ($us as $key => $u) {
	$u->of(false);
	$array[$key] = ["id" => $u->id, "name" => $u->name, "email" => $u->email, "pass" => $u->pass];
}

// write to file
$fp = fopen('./inc/users.csv', 'w');
$i = 0;
foreach ($array as $fields) {
   // Add headings to the first line.
    if($i==0) fputcsv($fp, array_keys($fields), ",");
    fputcsv($fp, $fields);
 $i++;
}
fclose($fp);

Now I am looking into a way to import the users in the new PW install via API and in that process bypassing the regular $user->pass method for setting the password. So that I can store the hashed password as is during import. Then I'd only need to copy over the salt from the original PW install and the users should be able to login.

But when looking at the ___setPass($value) method in /wire/core/Password.php, I am not sure how to hook into it and make it just save the supplied value.

Also, looking at /wire/core/User.php, I don't see how this is connected to the Password class or vice versa.

Share this post


Link to post
Share on other sites

The user class is just an more specific page class, so it shouldn't have any correlation with the password, as 'pass' is a field with the FieldtypePassword. 

Share this post


Link to post
Share on other sites

Am I on the right path at all when I try and replace the ___setPass($value) method so that it sets $this->data['hash'] = $value (value that gets passed in to the method)?

Share this post


Link to post
Share on other sites

Hey gebeer, I'm trying to extend your function for admin only, by adding a button to the users screen: /processwire/access/users/

Do you know where exactly I would create my hook point?
I'm a little stumped, while adding hooks to ProcessPageEdit are relativley easy, I'm yet to see an example for the users section of processwire.

Share this post


Link to post
Share on other sites

ProcessUser is the module, which handles this section of the admin, and it does by itself use ProcessPageEdit for the user editing, so you'll probably don't need different hooks, but just a check if the current edited page is a user.

Share this post


Link to post
Share on other sites

Thanks Lost, but I'm still Lost!

Still no idea how to hook prior to output to add the new button, this is what I have:
 

$this->addHookBefore('ProcessUser::render', $this, 'usersAddButtons');

Share this post


Link to post
Share on other sites

ProcessPageEdit::buildForm is most likely the hook you want to use if you want to add things to the page edit form.

Share this post


Link to post
Share on other sites

For that page ProcessUser is inheriting the usage of a customized Lister from ProcessPageType, so you probably need to hook some of the ProcessPageType::execute… methods.

Share this post


Link to post
Share on other sites

I was unable to hook to this page, so ended up creating a custom admin page to support a button to export users via CSV.
Seems overkill, and I'm sure there are other senarios which may warrant additional buttons such as: Selecting all users for another operation (copy to clipboard) or email all users etc.
It would be nice to find out the appropriate method to hook to ;)
 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Marcel
      Hey,
      I am about to use the tool Create Users Batcher. We have 450 users. When I tryed it with like 20 test users it worked but it took a while. Now my concerns are that 450 might be to stressful? Does anyone have experience with several hundreds of users? My thoughts are to split it in smaller goups and upload them one group after another.
      best wishes
      marcel
    • By NorbertH
      I have trouble exporting fields via the buildin export. 
      For example when i export a single field  i get:
      { "bestellung_status_name": { "id": 194, "type": "FieldtypeText", "flags": 0, "name": "bestellung_status_name", "label": "Status Intern", "textformatters": [ "TextformatterEntities" ], "collapsed": 0, "minlength": 0, "maxlength": 100, "showCount": 0, "size": 0, "pattern": "[a-z\\A-Z\\(\\)]+", "showIf": "", "themeInputSize": "", "themeInputWidth": "", "themeOffset": "", "themeBorder": "", "themeColor": "", "themeBlank": "", "columnWidth": 100, "required": "", "requiredAttr": "", "requiredIf": "", "stripTags": "", "placeholder": "" } } exporting a secon single field i get :
      { "bestellung_status_name_ext": { "id": 195, "type": "FieldtypeText", "flags": 0, "name": "bestellung_status_name_ext", "label": "Status Extern", "textformatters": [ "TextformatterEntities" ], "collapsed": 0, "minlength": 0, "maxlength": 100, "showCount": 0, "size": 0, "pattern": "[a-z\\A-Z\\(\\)]+", "showIf": "", "themeInputSize": "", "themeInputWidth": "", "themeOffset": "", "themeBorder": "", "themeColor": "", "themeBlank": "", "columnWidth": 100, "required": "", "requiredAttr": "", "requiredIf": "", "stripTags": "", "placeholder": "" } } So far everything works fine .
      When i try to export both fields together  i get only an error message :
      Call to a member function getModuleInfo() on null File: .../wire/modules/Fieldtype/FieldtypeText.module:171 I added " bd($textformatter);" on line 170 to see whats wrong. so have a look at the screenshot i apended to this post.
       
      Its perfectly possible that one textformater module got removed by accident while experimenting whith some textformaters but my question is how to fix this maybe somewhere in the DB and possibly what went wrong?
      ProcessWire 3.0.120 © 2019
      Apache/2.4.25 (FreeBSD) OpenSSL/1.0.2k mod_fcgid/2.3.9
      PHP 7.1.2
           

       
      Edit: After adding
      if ($textformatter ===NULL) continue; I can export my fields , as there arent any Textformater missing in the fields , i get a perfect result. but still there is one textformater whith a NULL value.  
       
       
    • By karian
      I don't know why multiple instances (repeater_repeat_columns1, repeater_repeat_columns2, ...) of my repeater field are displayed inside Template field (see image).
      Is there a way to clean/reset it ?
       

    • By psy
      I'm combining two PW sites into one, Site A into Site B.
      At each step, I did it bit by bit as the 'all at once' approach failed.
       
      First, I exported all the fields from Site A and imported into Site B. Any field types not supported by import/export, eg FieldtypeOptions I manually recreated. All good.
      Next I exported all the templates from Site A and imported them into Site B and copied across their associated template files. All good.
      Finally I exported the pages I needed from Site A into Site B - again, bit by bit to ensure it all went smoothly.
      From the admin side, it all looked and worked perfectly.
      Front end was a totally different story. All existing pages in Site B worked as expected. NONE of the pages imported from Site A displayed. They all ended in a redirect loop with no errors in the PW logs or Tracy Debugger.
      After some trial-and-error, I finally got it working with:
      - create a new template in Site B admin with no associated template file and just a title field
      - import the fields from the imported Site A template into the newly created template (both on Site B)
      - copy the Site A php template file into a new file that matched the new PW Site B template name and save in Site B site/templates
      I can deal with the above workaround. Just curious to know if I did something wrong or if the template import/export feature is problematic?
       
      ### Solution:
      While the export/import was a slow process, turned out the front end redirecting issue was unrelated. For reasons unknown, all templates marked as HTTPS only were the ones redirecting, ie all templates from Site A. Finally solved it by changing the $config->https to true in site/config.php
      Now the pages display correctly as https whether the template forces the issue or not.
       
×
×
  • Create New...