|
Peter
|
June 17, 2015 at 2:51 am
Latest EE (4.7.1.p) & WP. Have tested without other plugins and in 2015 theme.
I have an exhibition held over 5 days for which customers can purchase a ticket for one day (each ticket is valid only for that day). I have set up my event, added the 2 ticket types and added the 5 datetimes.
When I view the event on the front-end, I am presented with the 2 available tickets to select and a list of the dates beneath, but I am not able to select which day I am purchasing tickets for.
|
|
Tony
|
June 17, 2015 at 3:18 am
Hi Peter,
You will need to create separate tickets for each datetime, so if you have 5 datetimes and would like to offer 2 tickets for each you need to create 10 tickets. Like so – http://take.ms/jg9Og
Make sure each datetime only has the relevant tickets assigned to the datetime – http://take.ms/ud9aQ
The user then selects which tickets they would like to purchase from the ticket selector – http://take.ms/dw8fy
If each datetime only has the correct tickets assigned the sales of those tickets will only apply to that datetimes sold limits.
|
|
Peter
|
June 17, 2015 at 3:25 am
Well, I must say that is a completely stupid and confusing way of doing things. It also goes against every other event sales system that I have tried out over the years.
|
|
Tony
|
June 17, 2015 at 4:32 am
Thank you for the feedback, Peter.
I will pass this onto the rest of the team and open an internal discussion regarding this.
|
|
Peter
|
June 17, 2015 at 5:01 am
Thank you.
I have used many different ticketing systems – apps and websites – over the years, including EE3 with the recurring events add-on, and every single one has presented the event construction as create event, add common ticket types, add dates. None of them require you to create individual ticket types for each date. This, to me, is nonsensical.
Whilst you’re considering things, I’d also like to point out that every website that I’ve ever bought tickets for has the following flow:
1. Select event
2. Select date
3. Select ticket type
Not
1. Select event
2. Get a whole raft of tickets and dates all in one confusing list.
Finally, because I was basing my recommendation to my client on my experience with EE3, I would like to request a refund.
|
|
Tony
|
June 17, 2015 at 5:34 am
The reason EE4 requires you to create individual tickets per datetime is to allow you to set limits per datetime and per ticket(s) associated to the datetime, as this allows for the most flexibility for the limits.
For example if you do not have limits within your tickets, you can use the datetime limit as the sell out point. So selling 10 Adult tickets and 10 Child tickets with a datetime limit of 20, sells out the event. (Or any combination of those 2 ticket types)
The same can also apply with ticket limits, you can sell up to 8 child tickets, 8 adult tickets and 4 spectator tickets (you can also combine this with the datetime limits) once all of the tickets associated with a datetime are sold out, that datetime sells out.
However what if you only have a specific amount of ‘Child’ tickets that differ per datetime? You can only do this if you create individual tickets that are associated with the datetimes.
You can still create individual events for each instance if you prefer (rather than multiple datetimes within a single event) which would work in a similar way to EE3 although currently EE4 does not have a Recurring Events Add-on to create multiple instances of an event automatically based on a date formula like EE3.
|
|
Tony
|
June 17, 2015 at 5:50 am
Also, I do see your point with the front-end ticket selector displaying all the tickets available and have added your additional feedback to the discussion.
You can view our refunds policy here:
https://eventespresso.com/support/terms-conditions/#refunds
Which includes a link to request a refund.
|
|
Peter
|
June 17, 2015 at 6:04 am
Actually, that’s another example of how your method is more confusing.
Most other systems define a capacity at either event or (preferably) venue level.
You can then set maximums for each ticket type that won’t, collectively, go above the capacity level.
Eg. Venue has a capacity of 100.
Adult tickets has a maximum of 100 and Student tickets has a maximum of 100. Total sales of both ticket types will never go beyond 100 in total.
or
Adult tickets has a maximum of 100 and Student tickets has a maximum of 50. Total sales will never go above 100, but student sales will never go above 50 (thus, once they’ve sold out, leaving 50 still available to Adult).
That is kind of how you work now, but doing it like you do is more confusing for the event manager and the customer.
While I concede that your method is more flexible if you wanted to limit ticket types on a particular day, it would not be difficult to have daily over-ride rules and, like I said before, the presentation to the customer (as well as the admin for the event manager) would be considerably simpler!
|
|
Josh
|
June 17, 2015 at 11:56 am
Hi Peter,
I have a potential solution for you when it comes to reducing the number of ticket options displayed at one time for the ticket buyer, but first I’d like to share another reason why Event Espresso 4 allows (but does not require) a ticket for each datetime. This might help you understand the method to our madness.
Allowing, but not requiring, a ticket for each datetime makes it possible for one ticket to grant access to more than one datetime. For example, there are many use cases where someone wants to offer a 2 or 3 day access pass. The current system allows for this, but the feature would cease to exist if we changed it so one ticket could allow admittance to a number of datetimes, but based on a selection in the registration process, it then restricts it to one datetime.
We recognize that the ticket selector options can get out of hand in cases where there are multiple datetimes + multiple ticket options all for event. We do in fact want to streamline the front end ticket selection process where multiple datetimes are available and we’ve come up with a few options we’re weighing. Please feel free to check those options out and leave any feedback you might have in these notes.
While we work that out, here’s the solution I can advise for now: You set up an event for each datetime, then you can use something like the Events table template add-on to display a table of all the exhibition dates that have tickets available for purchase. This way there will be a step 1 (select datetime for event), then step 2 (select ticket options for that datetime).
I hope this helps.
|
|
Peter
|
June 18, 2015 at 3:46 am
Your problem, I think, is that you seem to think it has to be one way or another. There’s no reason that you can’t give the customer the choice in how they want their purchase flow to work. In fact, I would argue that that is exactly what you should be doing.
I am going to try the multiple events workaround, although that is still far from perfect – in fact, it’s arguably worse as I will have to maintain not only 10 different ticket definitions, but now also 5 different event entries! At least, though, there is less clutter and confusion on the front end for the customer.
|
|
Josh
|
June 18, 2015 at 2:21 pm
If you’re interested in leaving feedback on what we really think, you can comment on our proposed options for selecting a date before selecting tickets.
|
|
victoria bang
|
July 1, 2015 at 7:19 am
question regarding your proposed solution with the events table addon. How do I make a shortcode so it automatically filters to only show the new separately datetimed “child” events? i.e. is there a way to set a search parameter or similar in the shortcode table_search does not seem to do this
|
|
Josh
|
July 1, 2015 at 11:51 am
Hi Victoria,
It turns out that each datetime within an event does not make for a child event. The Events table add-on is designed to only display one datetime per event, and the datetime it displays is the next upcoming datetime.
|
|
victoria bang
|
July 2, 2015 at 3:49 am
I realize that each datetime doesn’t make a child event. That’s what the quotation marks were for. I meant “child” events in teh sense that they were duplicates of the “master” event created in accordance with your proposed solution.
While we work that out, here’s the solution I can advise for now: You set up an event for each datetime, then you can use something like the Events table template add-on to display a table of all the exhibition dates that have tickets available for purchase. This way there will be a step 1 (select datetime for event), then step 2 (select ticket options for that datetime).
Basically you’re saying that your proposed solution does not work. We have multiple events like this where it would look ridiculous for us to have 30+ ticket types for the user to choose from.
Do you have anything else to propose?
|
|
victoria bang
|
July 2, 2015 at 6:02 am
Oh, and can you say anything about when you’ll have a fix for the front end ticket selection to make this possible? It would be great for me to be able to tell my client when we can make this work like it should.
|
|
Josh
|
July 2, 2015 at 7:57 am
Hi Victoria,
I think there’s a misunderstanding here. The solution I proposed does work because when there’s a 1 to 1 relationship between events and datetimes, people can select a date to purchase tickets for. Have you tried that?
|
|
victoria bang
|
July 3, 2015 at 4:51 am
Yeah, no, since we have multiple concurrent events with multiple datetimes for each event with multiple tickets for each datetime, the event table will show a jumble of different events and not only a list of datetimes for the specific event they are interested in purchasing a ticket for. I think we found another solution though. But it is still frustrating that this is an issue.
|
|
Josh
|
July 3, 2015 at 8:11 am
Hi Victoria,
I’m sorry for the frustration. We welcome your feedback on the solutions proposed in this Github issue:
https://github.com/eventespresso/event-espresso-core/issues/92
|
