|
Daniel
|
February 13, 2020 at 2:27 pm
Hi!
I found this thread
https://eventespresso.com/topic/customizing-simple_ticket_selector-template-php-path/
that indicates we can replace the ticket selector template by putting a file in the theme root. I have done this and I am able to see changes I am making.
My problem is, that the site sells tickets for classes that last up to 19 weeks. Each week we prorate the cost of the ticket down so new students can join in later weeks and they pay a little bit less. I have set up tickets with “joined” start and end dates so that the new ticket becomes available the moment the class is over. This works well – I hide the “Goes On Sale” lines with CSS ‘tickets-pending’ class.
However, the tickets available count (we call it “Seats Open”) is taking the “future tickets” into account!
Is there a way to count the spaces left without considering the “future” tickets QTY?
I had thought of managing this using a cron job that would just “delete” the old ticket and create the new one. But, if possible, I want to be able to create these tickets ahead of time and not have to manage them with a cron job.
Thanks in advance for any help / advice / insight!
|
|
Tony
|
February 14, 2020 at 5:26 am
Hi Daniel,
Which ‘tickets available’ count are you referring to?
With mentioning the ticket selector template I’m assuming you mean the details in the ticket details section under access?
If you can include a screenshot that shows section I can look into this further.
|
|
Daniel
|
February 14, 2020 at 10:13 am
Hi Tony!
I think I confused two templates here.
I have overridden the content-espresso_events.php template as well. That is where my issue is.
I am using code that looks like this:
$event->total_available_spaces()
and it is returning all the spaces available for all tickets regardless of whether they are currently available.
I suppose I just need guidance on which method in the Events class to use so that I can count only QTY in the “active/available” tickets.
Thanks!
-
This reply was modified 4 years, 2 months ago by
 Tony. Reason: Code formatting
|
|
Tony
|
February 17, 2020 at 3:04 pm
Yeah the total_available_spaces() method takes into account all tickets on the event, so you’ll need to pull the ‘current’ ticket and output the
$where = array(
'TKT_deleted' => false,
'TKT_start_date' => array('<', time()),
'TKT_end_date' => array('>', time()),
);
$tickets = $event->tickets(array($where));
Which should return an array of available EE_Ticket objects, loop over them (it) and use the remaining() method to return the number of ‘saleable’ spaces left on the ticket.
|
|
Daniel
|
February 25, 2020 at 8:22 am
Thanks! It’s working now.
I believe the over-counting of spaces was caused by the fact that I had not mapped each ticket to every datetime. The over-counting was fixed by simply making sure that all of the tickets applied to all of the datetimes. So, it appears that the total_available_spaces() function returns unexpected results if the ticket-to-datetime mappings are set up incorrectly in the data. I have not debugged that exactly, but the numbers became correct after I corrected that data issue.
Cheers!
|
|
Tony
|
February 27, 2020 at 5:44 am
So you had multiple datetimes, each with their own ticket assigned to the specific datetime and not all?
If that’s the case the calculation is correct and it’s by design.
Datetime 1 : Ticket 1 has 10 spaces.
Datetime 2 : Ticket 2 has 10 spaces.
Datetime 3 : Ticket 3 has 10 spaces.
Each individual ticket has 10 spaces, the total is 30 as each Datetime and Ticket combo has its own limit.
A sale on Ticket 1 (or any sinlge sale on any ticket) leaves 29 places (9 for Datetime 1 and 10 each for Datetime 2 and 3.
Datetime 1 : Ticket 1, Ticket 2, Ticket 3 has 10 spaces.
Datetime 2 : Ticket 1, Ticket 2, Ticket 3 has 10 spaces.
Datetime 3 : Ticket 1, Ticket 2, Ticket 3 has 10 spaces.
The total is 10 as the sales from Ticket 1, 2 and 3 apply to each and every datetime assigned to it.
A sale on any ticket above leaves 9 places total as the sales apply across all applied.
|
|
Daniel
|
February 28, 2020 at 9:54 am
Thanks for the info Tony! This explains the behavior I saw perfectly. I sometimes just need to rubberduck a problem to see the issue. It was the data issue on my side – the EE code was calculating based on the info I gave it.
|
