Managing Front End Users and logins

[NikNak]

Hi there

Can I ask what would be the best way to approach a situation where you require front-end users to log in before before being shown certain content and being able to download files.

The users would be set up by the site manager (not superuser), but I want to keep it simple for these admins, without mixing guests up with all the site admins, and for them not to have choices over user roles etc.

Would the best option be to use the built in users functionality? In which case, is there a way to keep this section of users separate from the main users list.  

In an ideal world, you'd create a new user as a new page under a separate parent and separate from the rest of the sites admin users.

I've been searching on the forums and am getting a little confused.

Many thanks if anyone could share their opinion.

Kind regards

Nik

[ryan]

User creation is an administrative task, so if you need non admin/superusers to create users, you'd probably want to create your own form to do it. It would be relatively simple. Creating a user from the API is as simple as:

$u = $users->add('username'); 
$u->pass = 'password123';
$u->addRole('example'); // optional, if role other than guest needed
$u->save(); 

From the sounds of it, you don't want to create actual PW users, but maybe something like them using pages. You could certainly do this (perhaps mapping them all to 1 single PW user behind the scenes). However, I'd encourage you to use PW's users. There is a roles system that is designed to separate users, so the typical way to maintain this separation is by role assignment. 

[NikNak]

Thanks Ryan

I agree and think the best approach is to use PW users - I think I need to do more research into how to make such a page with a form work in the admin area. Still a noob.  Previously I was planning on making each new front-end-user initially as a page, and then creating/updating the pw-user from the page every time a save is made - using a hook. I guess this might be seen as unecessary duplication. Any thoughts?

Much obliged for the help

Regards Nik

[ryan]

I agree that it does sound like unnecessary duplication. What's the benefit of creating your own users as pages separate from ProcessWire users? I'm not sure I understand the considerations there yet. But if you want to go that route and create your own pages as users, then there's probably no reason to maintain a 1-to-1 mapping with PW users. Instead, you can probably have a single user that you map all your own user pages to. Or perhaps a few separate PW users that you can map to, each with different levels of permissions... but then this is treating PW users as roles or groups, circumventing a system that's already there. I think the question of what users are may be the wrong question and instead it might be better to look at using the existing users system and what management additions are needed in your case. Perhaps modifying or extending the current ProcessUser module to provide the capabilities you need would be the simplest route. 

[modifiedcontent]

I wondered about this and had almost decided to store 'members' in my site under a page instead of as users.

I will now store members as regular users, but am still worried about user management if you have potentially hundreds or thousands of members in the system. The Access > Users area doesn't look like it could handle that; no way to sort alphabetically or by signup date, no users search box, no way to separate users lists by roles, etc.

Or are those all hidden, built-in features? Or are there effective 'user management' modules to cover bigger user databases?

[LostKobrakai]

@modifiedcontent Please do not double post, just look at the provided answers under your post here: 

 

[modifiedcontent]

@LostKobrakai, apologies, but I had never seen those answers - wasn't signed up for alerts I guess - and forgot I had posted that question before.