- 1 CPT named "Courses"
- 1 CPT named "Registrations"
These 2 are set in a many-to-many relationship.
Questions are:
1 - Each course will have a date and location to which a user can register (so a post to the Registration CPT will be added) via the CRED form. Will this be the perfect use for the intermediary CPT and will we be able to create the cred form for this intermediary CPT automatically assigned to the course of the current page (we don't want the user to select a course from a select field)?
2 - Each intermediary CPT will have a limit of registrations, we are thinking about using a generic number field (inserted in the intermediary CPT, so the limit is assigned to a location/date) and using conditions to see if the number of "Registrations" CPT is lower than the generic field. I guess this is possible using the fields relationship API correct?
1 - Each course will have a date and location to which a user can register (so a post to the Registration CPT will be added) via the CRED form. Will this be the perfect use for the intermediary CPT and will we be able to create the cred form for this intermediary CPT automatically assigned to the course of the current page (we don't want the user to select a course from a select field)?
In the typical workflow for creating a post and relating it to another post in an M2M relationship, there are at least two Forms:
1. Create one new Registration post (New Post Form)
2. Relate one existing Registration post to one existing Course post (Relationship Form)
If you want to create a new Registration post and also relate that Registration post to an existing Course post (or multiple existing Course posts) in a single Form, that will require custom code using generic fields, our Forms API and our Post Relationships API.
So for example, a new User will come to the site and fill out a Registration Form to create a new Registration post. Once created, to associate that Registration post with an existing Course post "Course English 101", the User might visit the Course 101 post and click a link "Register for this Course", which will redirect the User to the Relationship Form to connect a course and a registration. That Form will basically have two select fields - one to select a Course and another to select a Registration. Coming from a known Course post, you can automatically select the Course in the relationship Form. The trick will be how to select a Registration automatically, otherwise, the User would have to find their Registration post in a select field, mixed in with all the other Registration posts. This might require a bit of custom code, like a custom shortcode that gets the ID of the Registration post created by the current logged-in User.
That's one scenario I can think of to explain how this process might work in the Toolset workflow. If you have something else in mind, please elaborate and we can discuss options.
2 - Each intermediary CPT will have a limit of registrations, we are thinking about using a generic number field (inserted in the intermediary CPT, so the limit is assigned to a location/date) and using conditions to see if the number of "Registrations" CPT is lower than the generic field. I guess this is possible using the fields relationship API correct
I'm not quite sure I follow the date/location setup you're describing. Are you saying that it is possible for one Course to be available in multiple date/location combinations? For example, a single Course post "English 101" is available July 1 in London, August 1 in New York, and September 3 in Madrid?
Or are you saying each of these course/date/location combinations would be a separate Course post, like
- English 101 July 1 London
- English 101 August 1 New York
- English 101 September 3 Madrid
Each a separate post?
If you're saying the former is the case, then you need a separate post type for a date/location combination if you want to enable relating a Registration to a single date/location combination. In this scenario, Registrations are not linked to Courses, they are linked to Course Instances (a single date/location combination of a Course). Then you would have a one-to-many relationship between Course and Course Instances, and a many-to-many relationship between Registrations and Course Instances. There would be no direct relationship between Registration and Course in this scenario, only an indirect one via the Course Instance.
Or maybe I've misunderstood how you plan to assign date/location combinations to each Course? Feel free to elaborate.
I created the image attached because I believe it's simpler to understand.
The user should not be forced to do any additional clicks to assign a registration to a location.
The ideal scenario is that the user can just register for a location/date that is assigned to a course. Considering we will be implementing all in the same page doesn't toolset forms allow to insert a relationship field (hidden) that sets the relationship to the course of the current page?
I'm not quite sure I follow the date/location setup you're describing. Are you saying that it is possible for one Course to be available in multiple date/location combinations? For example, a single Course post "English 101" is available July 1 in London, August 1 in New York, and September 3 in Madrid?
Yes a course is assigned to multiple locations.
If you're saying the former is the case, then you need a separate post type for a date/location combination if you want to enable relating a Registration to a single date/location combination. In this scenario, Registrations are not linked to Courses, they are linked to Course Instances (a single date/location combination of a Course). Then you would have a one-to-many relationship between Course and Course Instances, and a many-to-many relationship between Registrations and Course Instances. There would be no direct relationship between Registration and Course in this scenario, only an indirect one via the Course Instance.
I understand what you're saying. So what you recommend is that date/location should not be intermediary CPT. Just a separate CPT?
Considering we will be implementing all in the same page doesn't toolset forms allow to insert a relationship field (hidden) that sets the relationship to the course of the current page?
Yes, that type of workflow is possible and will require a bit of customization. You can place a Relationship Form directly in the template for Courses, or if you decide to implement another post type for Course Instance (a course/date/location combination) you could place the Relationship Form in a View of the Course Instances related to the current Course. You could predefine the Course or Course Instance side using the current post ID, or ID of the current post in the loop of the View of related Course Instances. To predefine the Registration side of the relationship, you will probably need a custom shortcode that gives you access to the current User's Registration post ID. Then you would be able to predefine both sides of the relationship and hide the two input fields with CSS. Once you've predefined the two sides of the relationship and hidden both inputs with CSS, the Relationship Form would just look like one button to the front-end User, you could set it to say "Register Now" or something similar.
So what you recommend is that date/location should not be intermediary CPT. Just a separate CPT?
Yes, a separate CPT is probably required. It sounds from your description like you expect to be able to predefine a course/date/location combination in the intermediary post type. That's not really how intermediary posts work - I think there is a bit of a disconnect there. Intermediary posts do not exist yet when the site starts, so you can't predefine options in intermediary posts that don't exist. Intermediary posts are created automatically, as a behind-the-scenes utility post, when someone registers for a course, one intermediary post per course/registration. So the question is where to define this combination of course/date/locations, if you do not predefine them in the intermediary post type? You can create custom fields in the Course post type that store these values somehow, or you can create a separate post type, where one post represents a specific combination of these values. I suspect that a separate post type will be more robust and give you the features you really need here, and allow you to match registrations to each Course/Date/Location combination effectively.
If you'd like to set up a sandbox to see how this might work, we can collaborate in a sandbox site you create at https://discover-wp.com. If you sign up for a free account there using the email address associated with your Toolset account, I can find you and request admin access to that site so we can try out a few scenarios and work through the process together.
You are most kind.
We will then follow your advice and create a new CPT so we can create the course/Date/Location instances.
We are using a staging site for the moment and I will get back to you when we need help. We will first try to do it on our own and will provide admin access when time comes!
Ok great, thanks for the update. I will stand by for a follow-up here. Feel free to close out the current ticket and start a new ticket instead if you'd prefer.
I just wanted to check something about the relationships.
In your advise above, how would the 3 cpt interlink each other? Would it be all with a M2M relationship like in the picture I attach?
Christian is on vacation this week, let me step in here.
I read briefly the thread. Looking at the image you created, it appears your relationships could be simplified a little.
You have a Course Instances post type connected to the Courses post type. A Course Instance post can only be an instance of a single Course, right? An instance of a Maths course cannot also be an instance of a Geography course. So that can be a one-to-many relationship, one Course can have many Instances.
And is the relationship between Courses and Registrations redundant? If a person has registered for an Instance of a Maths course, then you implicitly know that they are registered for the Maths course.
And is the relationship between Courses and Registrations redundant? If a person has registered for an Instance of a Maths course, then you implicitly know that they are registered for the Maths course.
Client doesn't want user registration (the default WP registration i mean). Could we simplify in any way?
You say "if a person has registered" but without the registration CPT (which would have a form) how would he register? That's why we thought about creating the registration CPT.
As christian is on Vacation I will pickup where Nigel and Christian left off.
Nigel is correct in that a 1-M relationship can be used because I would imagine 1 course having many streams in your Case Instances but it is still the same math course and base on the fields that you have then the instance will be specific to the course.
This means that there won't be any overlap because Math and English won't have the same instance in terms of time and location. While they can share the same Time they won't be able to share the same location, so English will need its own instance which would mean 1-M relationship.
Client doesn't want user registration (the default WP registration i mean). Could we simplify in any way?
Based on this I understand that the users won't be able to register onto the site. They will essentially be guests correct?
If the users aren't registered to the site itself how will a user be able to list out the courses he/she is registered for ?
Thank you for your time.
There won't be a need for the user to check the courses it has registered to. The client just wants the registration form to be e-mailed to him but at the same time that toolset keep track of the registration limit so that the location/date instance be checked as sold out.
This question is a major one because we can't start doing much until we sort this issue and we are running a bit out of time.
We already determined that courses and instances(location/date) are 1-M relationship.
How about the registrations relationship between courses and registrations? We were thinking about if we actually need that relationship. If we set hierarchical relationships (courses -> instances -> registrations) we can perhaps call grandparents content and grandchildren depending on where we are? Would this be the best way?
Does toolset forms allow to send grandparent content in email notifications? So when a registration is submitted specify to which course it corresponds to.
How about the registrations relationship between courses and registrations? We were thinking about if we actually need that relationship. If we set hierarchical relationships (courses -> instances -> registrations) we can perhaps call grandparents content and grandchildren depending on where we are? Would this be the best way?
There are 2 ways to look at it. The first way is that you have the M-M relationship between Instances and Registrations where a user is registered to a course using the instance of a course. How i'm picturing this one working is that a user navigates to a course , lets say Maths. Then on that math course you'll see the description, lecturers etc, on that same math page you'll have the instances of that course which displays the times locations etc. Now the student will register for an Instance of that course .
I believe this is the better way to do it. It may just be slightly more involved if you want to list out the registered students since you're going to have to list it out through the relationships Course -> Instance -> Registrations.
The second method is having Course related directly to Registrations. I'm assuming here that Students can register for many courses which would require an M-M type relationship.
The only advantage i see to this is if the listing of the Registrations. Where if you want to see all the registrations for Math you can just list it through the Course -> Registrations relationship rather than having to go through the Instance CPT.
Does toolset forms allow to send grandparent content in email notifications? So when a registration is submitted specify to which course it corresponds to.
However it would be much easier to pass the email of the parent as a URL parameter to the registration form so that we can add this email as a field itself on the registration.
The first option you mentioned is the workflow we want, BUT in the admin (only admin) we should be able to go to Registrations CPT and see all the cred forms submitted and to what Location/date (instance) and Course (so both CPT) they sign up for.
Additionally, the admin should receive this data in the e-mail.
Would these two features be possible?
The second method is having Course related directly to Registrations. I'm assuming here that Students can register for many courses which would require an M-M type relationship.
That would be very easy if the course was related directly to registrations, problem here is that limit of registrations is not associated with the course itself, instead, it's associated with its locations (instances).
However it would be much easier to pass the email of the parent as a URL parameter to the registration form so that we can add this email as a field itself on the registration.
I mentioned the CONTENT of the grandparent, not email addresses. Considering that Courses would be parent of Instances and Registration child of Instances. So for example send in the notification the name of the grandparent (course) the user registered to.
If first option is doable, how would they be set, would be something like this?
Course ---- 1-M ----> Instance ---- M-M ----> Registration
The first option you mentioned is the workflow we want, BUT in the admin (only admin) we should be able to go to Registrations CPT and see all the cred forms submitted and to what Location/date (instance) and Course (so both CPT) they sign up for.
Ok so in regards to relating the Registration to the course through the Instance CPT you won't be able to see the Course the user is registered for on the backend, however you can click on the instance that will be on the Registration to know which Course it belongs to.
Additionally, the admin should receive this data in the e-mail.
Would these two features be possible?
Regarding the grandparent data in the email, yes this is possible. You can pass the grandparent ID into the post form using a URL parameter and populate hidden fields for the Registration. Then use these hidden fields to populate the email notification.
You didnt answer the question about what would be the best way to set the relationships (last paragraph), anyway i will try to set as i wrote in the question and see how things go.
