Support

May 11, 2022 at 8:48 am

Hi there,

We’re running into a situation where Incompletes are locking up registration spaces and it seems that simply looking at the Registration form without completing a single field shows up as Incomplete and a ticket gets locked for that Incomplete transaction.

Sort of, the ticket is placed in reserve for the duration of the session (which by default is 1 hour) and then released again if the registrant did not complete.

This is to prevent overselling and race conditions causing further issues for your users and to explain I’ll give an example of what happens without the reservation system in place:

User A selects the last available ticket on the event, clicks to proceed and takes a few minutes to input their registrant data, then take a little longer to find their card and input the details.

Meanwhile User B comes along and selects that same ticket and can quickly add their details to the registration form, have their card details already saved in their browser and it loads on the payment form.

At that point both Users are at the same point in the registration.

Lets say User B submitted their details slightly quicker, than User A a couple of seconds later…. should User A just be rejected now? How when submitting their card details will initiate the request to process payment?

If User A and User B actually submit their details at the same time, who gets that last ticket? Both may well have initiated a payment call but now one gets rejected after the payments have gone through.

In short, without the reservation system you either oversell or end up in an awkward situation of having to refund one of them (if payments are involved).

Is it possible to configure EE so that a ticket isn’t considered sold until they ‘Finalize’ the registration while keeping Default Registration Status as Approved? This seems like a more logical approach.

No, because of the above.

All Events are currently set to Approved and we don’t want to change to Pending as this would require us to approve every registration and it would lead to situation where potential registrants believe tickets might still be available but are not because some registrations have not yet been approved.

Changing the Default Registration Status (DRS for short) wouldn’t change the above behaviour as the DRS is applied on the finalize registration step, the reservation system happens on ticket submission.

May 13, 2022 at 4:17 am

You’re most welcome 🙂

Any further questions just let me know.

May 17, 2022 at 2:17 pm

Hi there!

Thanks for getting back to us.
Since our feature relies on WP-Cron to schedule this ticket’s unlocking, you need to check (ask help from your hosting company if necessary) if your WP-Cron is running fine; you can try this plugin as well: https://wordpress.org/plugins/wp-cron-status-checker/

Let me know about your findings!

May 20, 2022 at 8:50 am

When you go to Tools -> Cron Events, does it show a notice regarding DISABLE_WP_CRON at all?

Like this: https://monosnap.com/file/98zjOeHhPoOSS6hsG1RHw32K1zecjW

Where is the cron located in the file system and how can we configure it manually?

EE hooks into the WordPress core WP_CRON functionality, I don’t recommend you start digging into core files to change this.

What some hosts do, is disable the core WP_CRON functionality and then replace it with a ‘real’ server cron to do the same thing, an example of doing that can be found here:

https://kinsta.com/knowledgebase/disable-wp-cron/

However, that may not be what is happening here so we need some more details first.

As a quick test, go to Tools -> Site Health.

Wait around 30-40 seconds for all of the tests to complete, does it show any errors regarding Cron or loopback requests?