The call for a secondary user system in WordPress

The user system in WordPress is great with its functions for roles and capabilities  but as WordPress is used more and more for membership and e-commerce sites where we have the need for a login system for members and customers who shouldn’t have to access the admin panel.

The WordPress user

The user system in WordPress was build for facilitating access to the admin panel. Different roles grants access to the various functions and section of the WordPress admin panel.

All this works great, no doubt about that and I wouldn’t put a finger on it.

The challanges

But with the rise of WordPress as a platform for membership sites where we have members who need a login to access content and the ability to edit their own information the user system is used for something it is not intended. As site owners we don’t want these members or e-commerce customers to have access to the admin panel – not even a part of it.

It’s confusing for your customers to see a complete different interface when they want to edit their personal infomation and in WordPress they will be shown an empty dashboard which benefits no one.

Furthermore it does have some risc when it comes to the security of your site. It might be small or in most cases where WordPress has been proberly configured non-existing, but it’s never a good idea to have “strangers” in your backend.

This can be locked down by making a new role and restrict it’s capabilities but I would again argue to keep visitors away from your backend.

The solution

At this point it’s no secret I’d like to propose a secondary user system for WordPress – lets call it a member-system, to borrow the terminology from Umbraco CMS.

Members

It could somewhat easily be made with a custom post type and some helper functions to hash and encrypt passwords, log ins and setting cookies/sessions but for something as specfic as this – and to keep in mind that larger sites that have thousands of members – I’d prefer to store the members and their meta data in their own tables. Both for performance and data seperation.

Member groups

Where with the normal WP users we have roles and capabilities I would suggest a Member Group system.

This would make sense in categorizing members into groups and sub groups and have template functions to check for these. My take would to use the standard WordPress taxonomy system. No need to reinvent the wheel.

Under the hood

I’d suggest to add three custom tables:

• PREFIX_members
• PREFIX_members_meta
• PREFIX_member_groups

The tables would look something like this:

PREFIX_members

• ID
• first_name
• last_name
• login
• pass
• status
• registered

PREFIX_membermeta

• mmeta_id
• member_id
• meta_key
• meta_value

For the first two we can imitate the user and user_meta tables and the last one we can borrow a lot from the terms table.

Furthermore we need template functions for checking for setting cookies and sessions, checking for logged in or not and for member groups.

I think most of this more timeconsuming than difficult – but then again, I’m not a good enough adeveloper to know.