Posted: February 25, 2021 at 2:04 pm
When a spot reopens, people on the waitlist receive an email, which I good. BUT, it does NOT appear to reopen the spot to anyone else that may be wanting to sign up online that is not signed up on the waitlist. This means that if we have no one on waitlist or if no one takes that spot, no one can actually sign up. Is there a way that every time a spot opens, it does actually: Is this already possible and we’re just using the plugin incorrectly? |
|
Hi there,
Only the ‘next’ waitlist registration should receive an email here, are all of your waitlist registrations getting an email?
The waitlist add-on was originally designed to allow users to reserve/show interest in spaces that may become available on the event and give them a chance to book onto them if/when available. If we opened up the tickets to allow anyone to then book that available space there wouldn’t be any use for the waitlist add-on as User A, B, C could all registration on the waitlist but if we then open up registrations User X can take the space without them having any opportunity to register.
Maybe I’m misunderstanding here, but if you have no-one on the waitlist the event should be open. How are you testing this? I’ll try the same steps on a test site to see what happens. |
|
When a spot opens, we would prefer if everyone on the waitlist got a message stating that a slot is available. We would also like to open it up to other users not on the waitlist. Basically, whoever grabs the open spot first gets it. It doesn’t matter if they’re on the waitlist. The first person to pay and take the slot should get it. However, the waitlist would serve as a notification system for those waiting. Is there a way to make this happen? |
|
Not with the current version of the waitlist add-on. You could use something like this: https://gist.github.com/Pebblo/c48f75894b232f405727cf5ebfa4f119 Which adds a link to a Ninja Forms form on an event when a ticket is sold out which is used as a waitlist. Then when a ticket is available you can manually alter the users on that form submission list and add an additional space onto the ticket qty. |
|
Where in the code should I look to modify the plugin to fit our needs? I really don’t want to have to hunt it down, but can if not pointed in the right direction. Essentially, wherever it sends an email out I’d modify it to send an email to everyone on the waitlist, and also there, I could re-open a registration slot for anyone for that event. Loop and sql query to reopen a slot… doesn’t sound too difficult, but I could use help finding where I need to make the modifications. EE4 code is not very straight-forward or easily readable compared to EE3. |
|
I changed CalculateEventSpacesAvailableCommandHandler and commented out this line:
Now promoted registrations from the waitlist won’t be counted towards the number of sold tickets, correct? How do I prevent promoted registrations from counting as sold tickets and prevent EE from keeping a reserved spot for that promoted registration? Did I do it correctly? I tried commenting out this code as well:
But it seemed to mess up everything, so I re-added that to the spaces remaining calculation. Now, what do I need to change so that everyone on the waitlist is promoted and gets an email when a spot opens (and doesn’t count towards the sale)? I can’t seem to figure out how |
|
Whilst I’m more than happy to answer the questions you’ve asked above, it’s important to note that we can’t provide support for changing core files within EE or it’s add-ons and we can’t walk you through modifying the add-on to suit here.
Yes, but only promoted waitlist promotions.
It’s not just the promoted waitlist add-on that you need to focus on, the calculation takes into account all waitlist registrations, that’s what the getRegCount() is doing above. Rather than modifying the method, I’d look into removing it as a callback on the
Whenever a core file has been modified without a hook my answer to this is always no. There are hooks available to work around this, like the above.
This isn’t something I can walk you through as you’re essentially making your own version of the waitlist add-on.
Take a look in Line 254 is the If you mean what calls the command handler itself when you call a command EE core calls its handler. |
|
So in EED_Wait_Lists.module.php: I just need to comment out the following:
This should make the waitlist manager work as we’d like, correct? I believe removing these calculations will cause everyone in the waitlist to be promoted when a spot opens, a notification will be sent to each, and a spot will be open for anyone to take including waitlist users. If a promoted waitlist user attempts to buy the spot and it’s been taken by someone else, they should be informed a spot is no longer available, and they can be placed on the waitlist again. Correct? |
|
Again, rather than commenting out core code, remove the callback function from the action. Commenting out the code will be lost each time the add-on updates, hooking in to remove the callback, will not. Hacking up core files is considered the wrong method.
Sounds like, but I haven’t tested it as it’s not how the waitlist add-on was designed.
As much as I’d like to give you an answer, I can’t as your asking for something the waitlist add-on wasn’t intended for, there may well be logic outside of both of those callbacks for this. You’ll need to test these changes fully to confirm if the above is correct. |
|
Can you provide an example? And where should I put this code? |
|
You use add_filter() to add a callback to an action and use remove_filter() to remove one. I can’t really provide you with a different example without writing the code to do it but there’s lot of details on remove actions/filters around, for example HERE. The above isn’t EE specific but rather WP core functions. The ‘hardest’ part is getting your code to run at the right point, so after EE has added the hook but before it actually run.
We recommend using your own custom functions plugin: https://eventespresso.com/wiki/create-site-specific-plugin-wordpress-site/ |
|
Commenting out those 2 filters as mentioned above, adding the following code to core\modules\single_page_checkout\EED_Single_Page_Checkout.module.php, and extending EE_Error class to not fade-away seems to have made everything work the way we want. EED_Single_Page_Checkout.module.php _initialize(): After these lines:
I added:
This is a check to make sure the event isn’t sold out when someone on the waitlist attempts to complete their registration and the slot has already been sold to someone else. I added a new optional property in the EE_Error.core.php code so that the error message doesn’t fade away (no fade-away class is applied to the html). I feel like this could be a configurable option to make your waitlist plugin that much more valuable. I always seem to be doing the dev work for EE for free anyways by sharing my plugins / modifications… |
|
We ended up having to make more changes in order for this to work properly. It looks like Event Espresso is not consistent. Once a wait list registration has been promoted, when the user is finishing his registration process for his wait list entry, it does not create a reserved ticket like it would a regular user signing up. This creates problems… Also, this line of code seems buggy:
Transaction total is 0.00 since the user didn’t pay, so it promotes to approved rather than pending payment as it should. Thus, I had to comment out that check too. Also, with my changes, waitlist registrants should not be promoted if the event is sold out. I had to change this function in EED_Wait_Lists.module.php
Our EED_Single_Page_Checkout.module.php _initialize() looks like this now:
Ugh… |
|
The support post ‘Wait List Manager – Reopen Registration Slot for Anyone Including Waitlist’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.