Strange Bug with Ticket Cap and Booking in PRO

[Brian Hanna]

So I tried my best to put this into words, but had a difficult time doing it, so I created a video instead. The bug I’ve found is when people try and make a booking on an event and are not logged in, when they load the event page they can see some of the ticket types that are actually currently full, and then then they try to add a quantity for one that is full, the system glitches out and does prevent them from booking, but the number stays in the total.

Here’s a link to the screencast, should explain it pretty clearly but happy to clarify if you need: https://youtu.be/3Vq2jgOmakY

[Stephen Harris]

Hi Brian,

Thanks for the video. It didn’t look like it (judging by the admin menu) but do you have any caching plugin installed? The reason being is that there is otherwise no reason why a logged-out user would see a ticket when a logged-in user does not. (The plug-in treats the two users the same in so far as tickets are displayed). However, a caching plug-in will typically not cache content for logged-in users, or certainly not admins.

At a guess when submitting the booking the plug-in is working being the $_POST payload means that the cache is bypassed. When the booking form reloads, it populates with the data of the failed booking (to prevent users having to renter values), but this means a ticket quantity is set for a ticket that is no longer visible (and therefore cannot be deselected). I’ll looking into addressing that bug – but it’s a consequence of the bug that precedes it, i.e. that a ticket is appearing when it should not.

If you could let me know if any caching solution is in place that could be responsible, and if not we can investigate this a bit further.

[Brian Hanna]

Ah that seems to make a lot of sense. I have reached out to the host (WP Engine) as I know they use fairly aggressive caching and asked for an exclusion for any event pages. I’ll report back if the issue persists. Appreciate the speedy response.

[Author]

Posts