Support

Home Forums Event Espresso Premium Wait List Manager – Reopen Registration Slot for Anyone Including Waitlist

Wait List Manager – Reopen Registration Slot for Anyone Including Waitlist

Posted: February 25, 2021 at 2:04 pm

Viewing 12 reply threads


tfkcc

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:
– Reopen that spot online for anyone to book
– Still send an email to people on waitlist so they are notified

Is this already possible and we’re just using the plugin incorrectly?


Tony

  • Support Staff

March 1, 2021 at 3:05 am

Hi there,

When a spot reopens, people on the waitlist receive an email

Only the ‘next’ waitlist registration should receive an email here, are all of your waitlist registrations getting an email?

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.

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.

This means that if we have no one on waitlist or if no one takes that spot, no one can actually sign up.

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.


tfkcc

March 2, 2021 at 12:15 pm

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?


Tony

  • Support Staff

March 2, 2021 at 3:11 pm

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.


tfkcc

March 3, 2021 at 4:37 pm

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.


tfkcc

March 3, 2021 at 8:46 pm

I changed CalculateEventSpacesAvailableCommandHandler and commented out this line:

// $spaces_available -= $this->eventMeta()->getPromotedRegIdsArrayCount($event);

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:

// plus consider wait list registrations as taking available spaces
        $spaces_available -= $this->eventMeta()->getRegCount($event);

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 UpdateRegistrationWaitListMetaDataCommandHandler code is called…


Tony

  • Support Staff

March 5, 2021 at 7:37 am

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.

Now promoted registrations from the waitlist won’t be counted towards the number of sold tickets, correct?

Yes, but only promoted waitlist promotions.

How do I prevent promoted registrations from counting as sold tickets and prevent EE from keeping a reserved spot for that promoted registration?

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 FHEE_EE_Event__spaces_remaining and FHEE_EE_Event__total_available_spaces__spaces_available

Did I do it correctly?

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.

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)?

This isn’t something I can walk you through as you’re essentially making your own version of the waitlist add-on.

I can’t seem to figure out how UpdateRegistrationWaitListMetaDataCommandHandler code is called…

Take a look in \eea-wait-lists\domain\services\event\WaitListMonitor.php

Line 254 is the registrationStatusUpdate() is hooked into AHEE__EE_Registration__set_status__after_update.

If you mean what calls the command handler itself when you call a command EE core calls its handler.


tfkcc

March 5, 2021 at 12:44 pm

So in EED_Wait_Lists.module.php:

I just need to comment out the following:

/*
        add_filter(
            'FHEE_EE_Event__spaces_remaining',
            array('EED_Wait_Lists', 'event_spaces_available'),
            10,
            2
        );
        add_filter(
            'FHEE_EE_Event__total_available_spaces__spaces_available',
            array('EED_Wait_Lists', 'event_spaces_available'),
            10,
            2
        );
        */

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?


Tony

  • Support Staff

March 5, 2021 at 1:01 pm

I just need to comment out the following

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.

This should make the waitlist manager work as we’d like, correct?

Sounds like, but I haven’t tested it as it’s not how the waitlist add-on was designed.

I believe removing these calculations will cause…

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.


tfkcc

March 5, 2021 at 2:02 pm

Again, rather than commenting out core code, remove the callback function from the action.

Can you provide an example? And where should I put this code?


Tony

  • Support Staff

March 5, 2021 at 2:52 pm

Can you provide an example?

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.

And where should I put this code?

We recommend using your own custom functions plugin:

https://eventespresso.com/wiki/create-site-specific-plugin-wordpress-site/


tfkcc

March 5, 2021 at 8:32 pm

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:

       // verify that everything has been setup correctly
            if (! ($this->_verify_transaction_and_get_registrations() && $this->_final_verifications())) {
                EED_Single_Page_Checkout::$_initialized = true;
                return;
            }
            // lock the transaction
            $this->checkout->transaction->lock();
            // make sure all of our cached objects are added to their respective model entity mappers
            $this->checkout->refresh_all_entities();
            // set amount owing
            $this->checkout->amount_owing = $this->checkout->transaction->remaining();
            // initialize each reg step, which gives them the chance to potentially alter the process

I added:


$registrations = $this->checkout->transaction->registrations($this->checkout->reg_cache_where_params, false);
			if (!empty($registrations)) {
				$firstReg = reset($registrations);
				$spacesLeft = $firstReg->event()->spaces_remaining_for_sale();
				if($spacesLeft < 1 && !$this->checkout->admin_request) {
					throw new EE_Error('<p style="color: red; font-weight: bold;">This class is sold out.&nbsp; Please <a href="' . $firstReg->event()->get_permalink() . '?join_waitlist=true" target="_blank" style="text-decoration: underline;">rejoin the waitlist</a> so you will be notified if another spot reopens!</p>', 0, null, true);
				}
			}

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…


tfkcc

March 12, 2021 at 12:30 pm

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:


  $new_reg_status = $new_reg_status !== EEM_Registration::status_id_not_approved
                              && $registration->transaction()->is_free()
                ? EEM_Registration::status_id_approved
                : $new_reg_status; 

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


public static function promote_wait_list_registrants(
        EE_Event $event,
        $sold_out = false,
        $spaces_remaining = 0
    ) {
		if(!$sold_out){
			try {
				EED_Wait_Lists::getWaitListMonitor()->promoteWaitListRegistrants(
					$event,
					$spaces_remaining
				);
			} catch (Exception $e) {
				EED_Wait_Lists::handleException($e, __FILE__, __FUNCTION__, __LINE__);
			}
		}
    }

Our EED_Single_Page_Checkout.module.php _initialize() looks like this now:

if(!$this->checkout->admin_request){
				$registrations = $this->checkout->transaction->registrations($this->checkout->reg_cache_where_params, false);
				if (!empty($registrations)) {
					$firstReg = reset($registrations);
					$spacesLeft = $firstReg->event()->spaces_remaining_for_sale();
					
					$ticket = null;
					$tickets = $firstReg->event()->tickets(
						array(
							array('TKT_deleted' => false),
							'order_by' => array('TKT_qty' => 'ASC'),
						)
					);
					
					if(count($tickets)){
						$ticket = reset($tickets);
						// echo "count is " . count($tickets) . " and reserved count is " . $ticket->reserved();
					}
					
					if($spacesLeft < 0 || ( $spacesLeft < 1 && $ticket != null && $ticket->reserved() == 0 ) ) {
						throw new EE_Error('<p style="color: red; font-weight: bold;">This class is sold out.&nbsp; Please <a href="' . $firstReg->event()->get_permalink() . '?join_waitlist=true" target="_blank" style="text-decoration: underline;">rejoin the waitlist</a> so you will be notified if another spot reopens!</p>', 0, null, true);
						return;
					}
				}
			}

Ugh…

Viewing 12 reply threads

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.

Event Espresso