Here’s my problem.
I have a WordPress installation that has about 30 users with duplicates of emails in the users table. That’s ok, because that’s how I had to do it for the time being. I wanted users to register with exactly the same email because parents had to register their children into the system and their children did not have any email addresses (could be children from age 4 and up).
An example of the database could look like
x@gmail.com (parent)
x@gmail.com (where this is child1 to parent)
x@gmail.com (where this is child2 to parent)
I solved this temporarily (because I had to get this fixed quickly), but now I would like the users be able to login and change some stuff in their profile. Usernames and passwords are created and are totally unique so it’s possible to login – but no one has received usernames or passwords because the initial thought was not to give them ability to login.
I could solve the issue by sending usernames and passwords to the user (parent and the parent’s children) tox@gmail.com and go through all the 30 users (parents) and do the same.
But my issue lays in how to handle future registrations. Each user must be unique cause each user has some custom fields related to itself.
Any ideas?
UPDATE
It’s about registrering different dance-courses. The dance academy wants to keep track of how many pupils (users) there are at any course and wants to keep to track of user has payed the course or not. Sometime the user can be set as reserve and sometimes not. To complicate it further it’s not always this relationship between parent/child. Sometimes- let’s say an 18-year old wants to register at 3 dance-courses and the user is “child” (or could at least handle the registration him/herself)
IMHO you are taking a bad approach at the problem.
Users are unique, and should be unique for the application “sanity”.
If you think at your site structure, you have users that can registrer to courses. You want to have unique “entries” for every course, and that’s legit, but to do that, you should not duplicate users, but create an intermediary “entity” that as a one-to-many relation with users and one-to-many relation to courses.
In WordPress, when you need a generic “entity”, solution is, mostly, register a new post type.
Let’s assume you register a post type called “registration”.
Now you can connect users to registration using
post_authorfield, in this way every user can have multiple registrations and every registration belong to one user.Probably, registration can have some meta fields, e.g. one can be ‘Pupil Name’, where in case of user is a parent registering a child, is filled whit child name, in case user is an adult that want to apply to more courses pupils name is jsut user name.
Now you have the problem to connect this new post type to courses (that probably are another CPT).
WordPress has a lack here, because out-of-the-box is not possible connect posts to other posts, but you can solve the problem using a plugin like Posts2Posts ore create relationship by yourself using a custom field (something like a
'_course_id'custom field for registration post type).That’s the structure: you have unique users with unique emails, usernames and passwords.
Every user can login, manage the profile, get a new password when forgot, and any other feature a user should have.
At same time users can have multiple registrations, one for every courses.
In this way you can know how many pupils you have per course using a simple meta_query: ‘registration’ post type where meta_key = ‘_course_id’ and meta_value = $a_course_id.
Creating this structure is relatively easy, what you have to write is the UI to create new registration.
If users should not have possibility to register themself, you can use the core post type creation page:
create new registration post -> set post author to the wanted user -> use a metabox to select the related course.
Otherwise, if you want users are able to create new registration, you have to make registration post type non-public (hiding default UI) and create a custom UI for the purpose.
It’s a bit of work, but your application will improve a lot, structure will be “sane”, and you will be able to easily expand the site features, e.g. using newletter plugin to contact users (without worries about duplicate emails), integrating some shopping cart plugin to allow online pay for registrations, and so on.