|
Al Joly
|
January 7, 2014 at 4:38 pm
We have recently had an event overbooked. I searched through the forums and most cases where people have had this they have not properly set limits.
However in our case our event was set with an attendee limit of 20. When viewing the event it shows “Attendees: 21/20”.
Is there anything we can do to prevent this in the future?
|
|
Josh
|
January 7, 2014 at 6:38 pm
Hi Al,
Event Espresso 3.1.36 added a check for available spaces on registration form submit along with a setting in Event Espresso>General settings that can be adjusted to reduce the Ticket Reservation Time. The ticket reservation time can be shortened to reduce the likelihood of an overbooking.
|
|
Ronald Aoki
|
January 7, 2014 at 8:11 pm
Hey, Josh:
A 60 min. reservation time seems to be recommended according to your instructions. Is that correct? Also, where can I activate “Check for available spaces” on the registration form?
Thanks in advance.
|
|
Josh
|
January 7, 2014 at 9:17 pm
Those are general recommendations and the amount of time your events take to sell out should be taken into consideration. There isn’t an option that you set to check for available spaces, it happens automatically.
|
|
Al Joly
|
January 8, 2014 at 12:29 pm
Hi Josh, would you be able to point me in the direction of the modified code for this change? (registration form submit check). We are running 3.1.34.1 but it is modded so I’d prefer to update the specific code.
I am also just curious why there was not already a check for available spaces when you have an attendee limit? Or was this more of rare occurrence and this fix was just to help?
|
|
Josh
|
January 9, 2014 at 9:19 am
Hi Al,
There was already a check in place (and it’s still there) that displays the registration form only if there are available spaces. This was added as an additional check to help for the rare occurrence that the first check was not enough. So it helps in those cases.
I checked and these were the files that were touched when this feature was added:
espresso.php
gateways/process_payments.php
includes/admin-files/optional_event_settings.php
includes/event-management/update_event.php
includes/functions/cart.php
includes/functions/main.php
includes/organization_config.php
includes/process-registration/add_attendees_to_db.php
templates/multi_registration_page_display.php
|
|
Al Joly
|
January 10, 2014 at 2:15 pm
Hi Josh is there a specific occurrence that you have found this happening?
|
|
Josh
|
January 10, 2014 at 2:30 pm
There were reports from customers, yes, so we added the feature to help out.
|
|
Al Joly
|
January 13, 2014 at 11:51 am
But was there a specific time it was happening? Such as when users registered through to cart, or something like that?
|
|
Josh
|
January 13, 2014 at 1:02 pm
Hi Al,
It was when users registered through the cart or a single registration page. It affected both types of registration.
You can test this out and see how it works by setting up an event with one available space. Then, with one browser view the event’s registration form page (fill out the form but do not pay). Then, in another browser open the same page. In the older version of Event Espresso you’ll see that a registration form displays in the second browser. Then newer version of Event Espresso will not display the second form under these conditions, which can help prevent overbooking.
|
|
Al Joly
|
January 27, 2014 at 3:41 pm
Is there any way we can check this with out upgrading? Some hook or check we can see current attendees then hide the forms?
|
|
Josh
|
January 28, 2014 at 1:09 pm
Hi Al,
No. This is because more than hooks were added, the checks involve new functions that were added in the new version. The older versions did not have the functions that run the checks.
|
|
Al Joly
|
January 29, 2014 at 5:15 pm
Just to confirm, there was multiple files edited to apply this fix? I am curious if we can simply update 1 or 2 files to apply the “fix”
|
|
Josh
|
January 29, 2014 at 6:17 pm
Hi Al,
The files that are listed in the changeset where code was changed/added for this feature are:
espresso.php
gateways/process_payments.php
includes/admin-files/optional_event_settings.php
includes/event-management/update_event.php
includes/functions/cart.php
includes/functions/main.php
includes/organization_config.php
includes/process-registration/add_attendees_to_db.php
templates/multi_registration_page_display.php
|
|
Al Joly
|
February 3, 2014 at 1:52 pm
I guess, I can attempt to simply change those files, and see if it doesn’t break right?
|
|
Sidney Harrell
|
February 3, 2014 at 3:45 pm
Your best long term strategy is to identify what custom modifications you have made and to move those customizations out of EE’s core files. Where there are hooks available, use them. If there are no hooks available, but the function you are changing has a plugable wrapper, copy the function to a file outside of EE core before you modify it. If here is no plugable wrapper and you really need to modify the function, add a plugable wrapper to the function. It would be a lot easier to update and re-add the plugable function wrappers to the updated version than to put yourself on a non-updateable path and continue to suffer from bugs that we have fixed.
|
