2

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

[email protected] (parent)
[email protected] (where this is child1 to parent)
[email protected] (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) to[email protected] 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)

4
  • requirements doesn't make sense. being able to reset a password is the most basic functionality for a user. If a kid can't reset a password without his parents getting involved then it is not his user but his parents user. Commented Jan 28, 2014 at 9:22
  • Ok. I will try to clarify: 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). Does that make sense? Commented Jan 28, 2014 at 9:30
  • I think your problem is defining that "user of the academy" === "user of the site". If it is not even desirable that the pupils will be able to login to the site then they should not be users. If a pupil can and may login and set his own course then he has the mental capacity to be able to own an email address. that set aside, can you please add the info to the question itself. Commented Jan 28, 2014 at 9:53
  • Yes, good point about the the mental capacity :-) I don't mean the children should be able to login (cause I can't say that a 4-year can't (or is not allowed to by his/her parent)). yes, the actual issue probably is defining whom should be a user. It's not obvious though (or is it?) I have code which sets relations between users and payments/courses etc. A thought would be to create a user-role (named children) that is related to a specific user (parent). I really don't know if that is achievable and how to do that. But still there is a problem that each user should have an unique mailadress. Commented Jan 28, 2014 at 10:13

1 Answer 1

3

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_author field, 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.

4
  • Hi and thanks for your answer! I agree that users should be unique. That's why I have to manage to make the system more "sane". I've read your answer several times and it makes a whole lot of sense, but I don't really understand everything. "Now you can connect users to registration using post_author field," How do you mean? (The courses are currently custom post types and they have same custom meta fields like price, day, time and so on. I store which courses are relevant to each user in the user_meta - with something like course_1243, course_1257 where 1243 and 1257 is the id of CPT course) Commented Jan 28, 2014 at 13:08
  • "Now you can connect users to registration using post_author field" How do you mean? -- If registration are post type, post in that post type must have a post author. If you set the author to the user who registration is related, you don't need to use a meta field. @bestprogrammerintheworld
    – gmazzap
    Commented Jan 28, 2014 at 13:15
  • So if I understand you correctly, this is essentially what you're saying: Create a CPT registration. Make relations to courses through the registration CPT instead of the actual user. Create a relation between the registration CPT and the user by setting the post_author to the user. Have I understood you correctly? Commented Jan 28, 2014 at 13:38
  • @bestprogrammerintheworld yes. User connected to registration via post_author. Registrations connected to courses via meta field.
    – gmazzap
    Commented Jan 28, 2014 at 13:40

Your Answer

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

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