Support

August 12, 2024 at 12:04 pm

Hi Keith,

When you select “Additional Registrant questions” and purchase more than one ticket. The “Primary registrant” got all the tickets. However, all the tickets should be created for each individual separately as well.

Can you please go to EE > Messages and check if the tickets have been created for each individual?

August 12, 2024 at 6:31 pm

Hi Keith,

When a purchaser buys more than one ticket for an event, I want the other ticket holders name on their ticket.

The short answer to this is you need to collect the 3 System questions for First Name, Last Name (which is technically optional) and Email for the additional registrants.

Those are all allocated to the ‘Personal information’ system question group.

When I say this the usual response is that group now has a bunch of other questions in which you don’t want to ask all registrants… if that’s the case, move those additional questions into another custom group and allocate that group to the Primary registrant.

—-

In the “Question Groups” I added “Additional Group Person” with a description of “Name of Party/Group member. Is only used to personalise each ticket”

In the “Questions” I added Additional Ticket Holder Name” which is enabled and set to TEXT

In the Event at the bottom right hand side under “Questions for Additional Registrants” I tick the box “Additional Group Person”

When I buy three (3) tickets the registration page correctly asks for the two additional ticket holders names.

Whilst initially, this sounds like a working option you can consider this the wrong way to set this up.

What you have there is a 1 Contact assigned to 3 registrations, each of those registrations has a custom question assigned to it for the Ticket Name. However, everywhere that outputs the registrant name is going to use the contact assigned to the registrant. You technically can get the ticket to output the values to registration questions so you ‘can’ eventually get the tickets to chow the value you are using now… but then everywhere else will be ‘wrong’.

Can you link me to an event I can view this on so I can advise what needs to be changed?

August 13, 2024 at 7:49 am

The first part of your latest reply is all the same way you’ve been doing it previously, your adding custom questions and then expecting EE to use those for registrants. That’s not what you need to do for this.

This part:

The registration form shows the three attendees, but the tickets all still showed only the purchaser.

Is exactly how I would expect to work with that setup.

Custom questions could be used for anything, so we can’t rely on those for core functionality (such as creating the contacts linked to registrations). There are only 3 require questions for the majority of EE’s core functionality and those are the 3 System Questions First Name, Last Name (which is technically optional as not all cultures use a Last Name) and Email Address. The labels for those can be changed but they should be Questions ID 1, 2 & 3.

What we do with the answer to those questions is create a ‘Contact’, which is the registrant themselves, think of the contact as the Person and becuase we use our 3 questions solely intended for the contact it means we can always refer to those as the core questions. Whenever we want to know the contacts first name, we know it was created using the system question for first name and can rely on the fact that $contact->fname() should be valid (this is all also part of what you see the ‘wrong’ information used for the registrants, its using the contact for the Primary Registrant becuase your not asking for those 3 questions to create a contact for each registrant).

If I use an example of why we DON’T use custom questions for them… say I wanted to know your First name but instead asked ‘What colour is your car?’… to which you reply with Red, your name is now Red becuase I’m expecting to use that answer for a specific value. Lets say you did use a custom question that was originally ‘What is your First Name’… then later repurposed that question to be the above. Its messy, and becomes very difficult to fix, especially if the question(s) has been repurposed multiple times (and Yes, I’ve seen exactly that happen within EE3 with custom code from a users developers, the data within the database was a huge mess).

I brought 3 tickets and it showed Attendee 1, 2 & 3 with the same questions as expected which is not really what I want, but it does put the names on the tickets.

Same questions as expected? I don’t follow that part of the reply here.

But… from your opening post….

When a purchaser buys more than one ticket for an event, I want the other ticket holders name on their ticket.

Using the 3 system questions for First Name, Last Name and Email address is the the only way to get EE to create the contact for each registrant.

I still must be missing something, its not exactly intuitive..

Creating custom questions to use for registrants’ names (and Event Espresso allowing that) is going to end up in a hot mess further down the line. Like I said previously this sounds like a working option but the deeper you dive you into the more you realise it’s not a good solution for your to use or for us to implement.

However, I do think there’s some confusion here and things can be cleaned up more than what you have which is why I asked for a link to the event to see, can you link me to the event?

You will always need to ask for First Name, Last Name and Email address in the personal information question, those are the minimum questions to create the contact. But you can set it up to only ask those 3 questions for additional registrants (tickets) and no other questions.

August 13, 2024 at 9:03 am

Ok, so I selected 3 tickets to work through using the same setup you’ve mentioned above. So right now, what you have with this:

https://monosnap.com/file/cWTmo47T6hiWzdH8dTgxjIpz1hrkNh

Is the bare minimum you can have.

Each registrant is asking for the Personal Info group and that group has the system questions First Name Last, Name and Email Address in it.

To have all of your registrants show up separately, that’s is the requirement for Event Espresso to work.

—

If you want additional questions asked just for the Primary Registrant you can do that, you just need an additional question group (NOT the Personal Info group as that used by all registrants here).

If you don’t have one already you can go to Event Espresso -> Registration Form -> Question Groups.

Create a new group… for my purposes I call it ‘Tonys Group’.

Add the additional questions you want to ask the primary registrant to that group.

Then in the event editor the above event, select Tonys Group in the ‘Questions for primary registrant’ section.

It looks like this: https://monosnap.com/file/SbYGsxdaZwiWs4NzEmDA0v2DNWikX8

It’s the top set of question group checkboxes you need to add it.

That’ll add another set of questions only for the ‘first’ ticket.

Let me know when that’s done and I’ll recheck. We can then work through the finer details from there.

—

Side note – your reCaptcha key is invalid: https://monosnap.com/file/kYV5UfdZuvNZNMki1PIuIyj9gSusaD

(You won’t see this if logged in but it prevents me from moving forward from the reg step)

August 13, 2024 at 9:42 am

Clearly, if that’s a two ticket purchase, then no problem, but a six ticket purchase would most likely be seen as unnecessary form filling.

Which part is unnecessary form filling though?

Earlier you mentioned you wanted to collect the users name for the ticket so 6 tickets is 6 names would would want to collect regardless, you have to collect that information somewhere so the additional forms all relate to the specific requirement one exception, email.

Email is the only information being collected that wasn’t set as being part of the requirements but we require an email address for the contact. If that’s an issue you could use some JavaScript to copy the primary registrant’s email value into all other email fields on the page and then hide the additional email fields. Thats getting more into working around EE’s requirements and custom code, but its doable.