1

i'm hoping you guys can help with recommendations for the best user management module for my particular problem.

i want to be able to have two levels of user - site admins and members. site admins would be able to view / add / remove members from their designated 'location' only (so I guess a field to identify where they're based would be required). this should all happen on the front end of the site, outside of the EE admin.

i also want to be able to view / filter all users by specific custom fields (for example their location) and if possible export all users to CSV (appreciate this may need to happen outside of the module though...)

There seems to be lots of modules available so before I take the plunge I'm just trying to work out which one is the best fit for me.

Cheers Matt

2
  • Here's an interesting article for you focuslabllc.com/blog/member-profile-add-ons-in-expressionengine where they compare 3 of the leading member 3d party functionality add-ons. The other big one to look at is Solspace's user solspace.com/software/detail/user Jun 7, 2013 at 16:14
  • I've recently built a very similar system successfully. I used Profile:Edit combined with Matrix and Playa, all tied together with a custom module that fills in the gaps, tightens up security and locks-down permissions per location. It all works really nicely, but if you're not comfortable building your own custom add-on it will be frustrating. One of the tricky parts I encountered was that a given user could be both an admin of one area and an ordinary member of another, so I avoided multiple member groups and instead used Playa to define 'is admin of...' and 'is member of...' fields. Jun 9, 2013 at 10:07

1 Answer 1

1

You may get some of the way there with Profile:Edit or Zoo Visitor in that they abstract out member management to channel entries so you would be able to READ members from front-end templates using their module tags along with native EE channel entries tags.

You could possibly CREATE members from the front-end too if — in the case of Zoo Visitor for example — you set autologin="no". This should prevent the the person from being assigned a session ID and automatically being logged in as that user. You would need to ensure that you remove any {if logged_in} checks in the template.

UPDATE would be possible if you pass in the member_id or the member_entry_id of the profile you wish to update as is the case with Zoo Visitor. Profile:Edit will only enable you to update the profile of the currently logged in member.

[EDIT 1: James (below) has mentioned that you can also pass in the member_id to Profile:Edit to allow you to edit a specific member profile and not just that of the current logged in user.]

As far as DELETE goes I don't think either module will provide a way to do this in the way that you're hoping from the front-end. Profile:Edit doesn't provide this option at all and whilst Zoo Visitor provide a delete tag it can only be used to delete the currently logged in member from the front-end for obvious reasons.

You should be able to achieve most of what you want to with both addons if used in the control panel however and being regular channel entries you can assign member groups with varying permissions along with custom member fields. This would be your easiest option but if working from the front-end is essential then it could be worth checking out Open API. It acts as a platform and doesn't provide a ready made solution as soon as you install it so you need to be prepared to get your hands a little dirty in getting in building a CRUD based member management system.

[EDIT 2: Although I've not used the module myself it seems that Solspace User has the ability to both UPDATE and DELETE users along with providing a means for a single Admin user to CREATE users from the front-end. Overall this seems to be your best bet in achieving what you're looking to do.]

3
  • Just a correction on this - Profile:Edit does allow you to edit other profiles - just pass in the member_id (it doesn't work with the profile entry_id) Jun 9, 2013 at 10:10
  • Also, the Open API will eventually be a really awesome tool, but at the moment it doesn't support fieldtypes that store their data outside of exp_channel_data (ie, matrix, playa etc), so sticking with SafeCracker could be a better option at the moment. Jun 9, 2013 at 10:12
  • Thanks for the update James, that's useful to know. I couldn't find mention of it in the docs. In this respect is it just using regular Safecracker parameters? Any yeah, still no silver bullet in terms of abstracting EE's content management capabilities away from the control panel, but it's getting closer at least.
    – Ian Young
    Jun 9, 2013 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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