Huge Attendee List

[Jason]

My attendee list for an event is 1700 and climbing. Great news, except the attendee list is one massive 1700 ticket page in the admin area of wordpress and it’s getting unruly to say the least! Is there a way to paginate these like the orders screen or am I stuck with this massive list that wants to crash my browser if I try to filter it?

Thanks.
Jason

[Jason]

Any chance of getting a reply to this? It’s been two days.

I need a solution to this even more now. The attendee list size is causing VERY slow checkins for the people outside scanning tickets. It’s getting to the point where they have to wait a long time and in some cases, the browser just crashes.

Please advise ASAP.

[Jason]

To update a little further, I have implemented a hack that disables the ticket table from being shown, but still allows for check-ins. The file is

/wp-content/plugins/event-tickets/src/admin-views/attendees.php

I have added this, but it only speeds things up a little. There must still be things happening on that page that are causing an iteration over all attendees or something:

<div>
	<h2>Ticket list temporarily unavailable</h2>
	<p>We are currently troubleshooting an issue where all tickets are displayed, causing very slow site behaviour. We hope to have this portion back up and running soon. Ticket checkins will still work normally.</p>
</div>

<?php
	// We're going to hide this for now since it's slowing down the site drastically. 
	/*
<form id="topics-filter" method="post">
	<input type="hidden" name="<?php echo esc_attr( is_admin() ? 'page' : 'tribe[page]' ); ?>" value="<?php echo esc_attr( isset( $_GET['page'] ) ? $_GET['page'] : '' ); ?>" />
	<input type="hidden" name="<?php echo esc_attr( is_admin() ? 'event_id' : 'tribe[event_id]' ); ?>" id="event_id" value="<?php echo esc_attr( $event_id ); ?>" />
	<input type="hidden" name="<?php echo esc_attr( is_admin() ? 'post_type' : 'tribe[post_type]' ); ?>" value="<?php echo esc_attr( $event->post_type ); ?>" />
	<?php $this->attendees_table->display() ?>
</form>
<?php */ ?>

I think a paginated list on this page is a must, but I don’t want to hack it any further, and I would consider this a flaw/bug in the design. Would you agree?

[Jason]

Another update (sorry for all the updates… I’m talking to myself here):

I’ve commented out most of that page since this section at the top of the page seems to be where the real bottleneck is:

$this->attendees_table->prepare_items();

$event_id = $this->attendees_table->event->ID;
$event = $this->attendees_table->event;
$tickets = Tribe__Tickets__Tickets::get_event_tickets( $event_id );
$post_type_object = get_post_type_object( $event->post_type );

The browser crash happens when I let the ticket list actually load per my previous reply.

So right now my client can’t do a ticket lookup at all unless I build some sort of custom solution. If I let them do that, your event class grinds everything to a halt, presumably because the attendee list is so large.

Any help here would be very much appreciated.

[Nico]

HI Jason,

Thanks for getting in touch and sorry to hear about this issue 🙁

I’ve actually replied here but for some reason it seems my reply didn’t came though, and I didnt’t double check on that. I’m pasting the original reply below and adding some more information after:

This is surely something we could do better, but unfortunately there seems to be no workaround this limitation. I’ve created an improvement ticket covering pagination for attendees + sales reports in the backend, noting that the filter should be reworked.

Can you please let me know if there’s an specific task you are trying to accomplish? Maybe it’s possible to create a special snippet or JS hack to help you out in the meantime.

Taking a look at the new information you sent, it seems that actually preventing the tickets lookup in the database is the way to go for now.

Can you please send a database dump of the site? I’ll try to load it in my local install and see if I can find a better workaround for this while we move forward with the pagination issue (which as we have already scoped our next maintenance releases I don’t think it will come very soon). Also, I would like to help you out finding a way for your customer to browse / filter this list in the meantime, if you have any ideas of how this might work please let me know and I’ll help out.

Please let me know about it,
Nico

[Nico]

This reply is private.

[Jason]

Thanks for your help, Nico.

I’m not sure a database dump is possible since a) it’s pretty huge, and b) it has customer’s personal information stored in it. I might get in trouble for that. If there’s a way I can omit the customer info (usermeta maybe?) from woocommerce then that would probably work.

I think we really do have 2 main problems:

1. All attendees with a huge list on one page with javascript to filter is too much stress on the browser
2. Your class that handles the preparation and display of the list so too much stress on the server. Either that or there are memory leaks in the script.

I’d love to help in whatever way I can. My thought is that you/we create an admin page that simply displays the tickets the way a normal plugin would display data, instead of loading the entire list of attendees. I’d have to dig into your code more to see how they’re being pulled from the database, but that’s probably done much more quickly by your techs 😉

There should be a way for you to test this without my ticket/database info. Everything technically “works” as intended at this point except for the few items in the other tickets I’ve created.

Let me know what we can do!

[Jason]

Any word on this, Nico?

I have a new problem. People are showing up to the event and staff aren’t able to scan the QRs on some of the people’s device screens. This means they have to check people in manually. Only… they can’t because I had to turn off that ability on the attendee list to prevent the system being brought to its knees.

What can I offer my client to check these people in? They’re in the thick of it now, and I need a solution badly.

Thanks.

[Geoff]

Hey Jason,

Just wanted to follow up with you here while Nico is out today.

We were able to create a quick little plugin that will simplify the checkin process for you. Once the code has been scanned, it will redirect you to much simpler screen rather than the enormous list you’re dealing with now.

Please download, install and activate this ZIP file as you would any other WordPress Plugin.

I do want to note that we tested this on a clean install of The Events Calendar and Event Tickets. I know you have some additional customizations in place, so just wanted to mention it in case a customization happens to prevent this from working.

Worst case, you can craft a URL to check a specific person in and see that same screen using this as an example:

[your-site]//?event_qr_code=1&ticket_id=159&event_id=20

I have a new problem. People are showing up to the event and staff aren’t able to scan the QRs on some of the people’s device screens.

I’ve actually run into this same problem using other check-in apps and increasing the brightness of the device screens seems to make a huge difference. If not in this case, then that URL example above can be used instead.

Cheers!
Geoff

[Jason]

Hi Geoff.

I really appreciate you guys trying this for me. Unfortunately, every ticket comes up as “ticket could not be checked in (may not be valid)”. The Event name comes up correctly, and I presume the ticket number does as well. Just tested with brand new tickets. When I witch back to my old way of disabling the attendee table and class (my hack), it works fine for the exact same ticket.

If I give the staff your URL example, how do they find the ticket ID? I thought of that idea earlier today, but it’s not in the ticket email. It’s not even in the massive ticket list if I were to enable it again. Can you clarify where the staff would get this ID from?

Back to the drawing board. If you were able to create an alternate attendee list (and check-in page since it’s the same page) with paginated results I think you’d have this problem licked. I tried to create a little plugin with a separate attendee list using the wordpress WP_List_Table, but I had too hard a time trying to figure out how to display the ticket list. And I’m not getting paid for it, so there’s that 😉

Your continued help is appreciated.

• This reply was modified 9 years, 9 months ago by Jason.

[Barry]

Hi Jason,

Apologies for the continued problems and thanks for your patience while we work through this.

To continue from where Geoff left off, you’re right: staff would generally be unable to find the ticket ID needed to manually craft that URL. There was a miscommunication there and we shouldn’t have suggested you try to do that on your side.

Unfortunately, every ticket comes up as “ticket could not be checked in (may not be valid)”.

That’s really puzzling: on our side it does seem to work as expected so I’m not quite sure what’s going wrong in your case. To confirm – are you scanning an actual QR code from an emailed ticket when you test this (and can you let me know the URL you are being sent to if so – if you wish to redact the domain name that’s not a problem).

If you were able to create an alternate attendee list (and check-in page since it’s the same page) with paginated results I think you’d have this problem licked.

That’s definitely another way to go and it may well be we need to move toward something like that in the near future. In terms of an immediate solution, I’d much rather we look at and do further troubleshooting on the solution we already proposed before trying something more involved: would you be able to get back to me on the above in case anything obvious jumps out?

[Barry]

This reply is private.

[Jason]

This reply is private.

[Barry]

Thanks for the update (re visibility of both types of ticket ID) – let me chew that over a little and see if I can figure out why that might happen and why I might be missing it.

In terms of admin credentials, our policy is generally not to accept them and not to log into client sites – in some cases we make exceptions, but it’s definitely our preference to solve things without taking that step, wherever possible.

Where appropriate we do indeed ask for and use db dumps to aid troubleshooting: if you need to remove various pieces of information, or can only provide a subset of records, that is often fine (depending on the nature of the problem). That said, I don’t know if we’re quite ready to take that step.

On the private reply front – totally up to you. I didn’t want to share my own last reply publicly simply to limit access to the revised plugin (since if further adjustments are required, we probably don’t want others to start using it just yet). In general I’d suggest it’s best to make replies open for everyone to see, but we also appreciate your right to communicate in confidence and private replies are definitely the right choice should you share anything private.

To sum up where we currently are:

• The weekend is almost upon us so I’d like to highlight that though we’ll do our best to keep this moving, team members generally stop working and so communication is likely to slow down at the very least until working hours Monday morning
• Based on your feedback with the revised plugin I’ll do a little more research on my end and we’ll see what that yields
• Should you discover anything else we need to know, definitely post an update 🙂

Thanks again!

[Barry]

This reply is private.

[Author]

Posts