|
Affinity
|
October 16, 2017 at 11:06 am
Refer to:
https://eventespresso.com/topic/events-not-sold-out-yet-people-unable-to-register/
I updated the software as Josh suggested but the problem still persists. Can we escallate this? It’s been going on for a really long time.
|
|
Josh
|
October 16, 2017 at 11:10 am
Can you post a link to the event in question so we can take a look?
Also, were you able to find any differences between the dev and production servers? The reason I ask is because you mentioned in the other thread:
Everything still works on the dev server but not on the prod server although now the behaviour is somewhat different.
|
|
Affinity
|
October 16, 2017 at 11:13 am
This is the event: https://www.healthandsafetybc.ca/courses/test-event-3/
I can’t find any differences between the production and devel servers.
I have previously provided ssh and web access to the site if you want to log in.
|
|
Josh
|
October 16, 2017 at 11:56 am
Do you actually have Jetpack activated and connected on the dev site too?
One thing that you should change is the memory limit. Right now it’s set to 40MB which could potentially cause timeouts with number of plugins installed on the site. You can add the following to your wp-config.php file to bump the memory limit:
define( 'WP_MEMORY_LIMIT', '256M' );
|
|
Affinity
|
October 16, 2017 at 12:06 pm
jetpack does appear to be enabled on the dev site.
I pasted that memory_limit in the config.
I also noticed that this was not in the prod wp-config:
define( ‘ALTERNATE_WP_CRON’, true );
The cron seemed to be running but maybe that will make a difference.
I didn’t notice before. That file is in .gitignore.
I’m running another test now.
|
|
Josh
|
October 16, 2017 at 12:12 pm
Please be sure to not have any windows or tabs with the editor of that event open while testing. When the ticket becomes temporarily sold out due to no more available tickets, because of the one available ticket being reserved, and the event editor is open, the auto post save will trigger and the event status will be saved as sold out.
|
|
Affinity
|
October 16, 2017 at 12:29 pm
I’ve got the event edit window closed.
|
|
Affinity
|
October 16, 2017 at 2:40 pm
The test I linked to above seems to have reset itself (no longer sold out) but the second test I ran didn’t. I created it 2.5 hours ago. Did you do something to the first test or did that happen spontaneously?
|
|
Josh
|
October 16, 2017 at 2:50 pm
I reset the ticket reservation count (from the Maintenance page) then ran some tests on the first event and I could not reproduce the issue:
https://www.screencast.com/t/Opp3bL7HE
Before testing the auto-release of reserved tickets it’s really important to make sure that wp_cron() is functional on your site.
|
|
Affinity
|
October 16, 2017 at 2:57 pm
But you didn’t fill in the registration information and then not proceed (i.e. close the browser).
To see the bug: 1. add the only ticket to your cart. 2. close your browser (do not cancel the registration). 3. check back in an hour. 4. the event is still sold out.
As far as I can tell, cron is running.
|
|
Affinity
|
October 16, 2017 at 2:59 pm
you can also go back to the event page once you have closed the browser (i.e. after step 2 above) and see that the event is sold out.
|
|
Affinity
|
October 17, 2017 at 10:48 am
I see I left out step 1.a: fill in your contact info and click “procede to payment” or whatever it says.
|
|
Josh
|
October 17, 2017 at 11:04 am
You can actually skip the part where you fill in the registration form but not proceed from that point. If you simply add the ticket to the cart that will result in reserving the ticket, then you can close the window then.
The thing about your site that’s puzzling is the event’s post_status ends up getting changed from publish to sold_out while the one remaining ticket is reserved. That’s not supposed to happen and suggests an autosave for the event post is getting triggered while the available ticket count == 0.
There is a testing site that’s been set up to limit the session time to 2 minutes and display a countdown timer. On that site you can do the same tests on an event with one ticket remaining and you’ll note that the event does not get switched to a sold out post status and the ticket becomes available after 2 minutes:
https://josh.eventespresso.com/events/multi-event-registration-cart-test/
|
|
Affinity
|
October 18, 2017 at 10:41 am
I think we must have some custom code somewher that is overriding the default functions. I’ll look deeper. Thanks Josh.
|
|
Affinity
|
October 20, 2017 at 6:11 pm
I spent some time exploring the Event Espresso source code and testing with a simplified site. I have been able to reproduce this issue (or at least a precursor), reliably; on a dev site, on the production site, and on your test site. The event you created in your test site is now (incorrectly) sold out and has been for about two hours.
Steps to reproduce:
* In a new session, add all available event tickets to your cart.
* DO NOT view the cart. Exit that session.
* In another session, view the event again and note that it is shown as “sold out”. This will not change.
The event is now sold out, with no tickets sold but many reserved tickets. Note that an EE_Transaction record has not been created and so, naturally, there is no task scheduled to clean up the reserved tickets.
It looks like Event Espresso doesn’t create a transaction record until I view the cart, but it reserves tickets before then. (That is, it increments the “DTT_reserved” property in the related EE_Datetime). A quick and dirty fix may be to create an EE_Transaction as soon as a user adds an event to their cart, or to wait until the user views the cart before changing the counts of reserved tickets.
I’m happy to provide more information. Just let me know if there’s anything we’re missing 🙂
Dylan @ Affinity Bridge
|
|
Josh
|
October 23, 2017 at 11:05 am
Hi Dylan,
Thanks for the detailed report. I’ve made another ticket for the dev team to address this specific issue.
In the meantime, you can add an additional cron event that will automatically reset the reserved counts every hour. Here’s a link to some example code that you can use now, which will add the additional reset to the wp_cron schedule:
https://gist.github.com/joshfeck/19cf49a2a30e939cca6d0a7014f7c183
|
|
Affinity
|
October 23, 2017 at 2:54 pm
Thank you, Josh. If you can subscribe us to that ticket, or keep us posted on when it is fixed, that would be much appreciated 🙂
Your example workaround helps a bunch, and should work for most cases. One thing to note is it will correctly reset the “reserved” count for each datetime, but it doesn’t fix the event status if it has been changed to “sold out”.
|
|
Josh
|
October 23, 2017 at 3:08 pm
I can let you know when there’s a branch available for testing, when the branch has been merged to master, and when the version is released that includes the fixes.
The event’s post_status should not get changed to sold out unless there’s an autosave for that event happening in the background somehow.
|
