|
Jason Lee
|
March 21, 2020 at 6:18 pm
Hey! Hope yall are staying safe. I had a quick question about an issue that has recently come up on our website that I am struggling to diagnose.
We are using EE3 (and love it). Our events are all run by outside companies, so we have a cron job that automatically sends attendee lists when an event closes to those companies. This has worked great for years.
It works by searching the database for events that have closed within that hour and then sending the list. If we delete an event, it will still send a list as the event is still in the database. To mitigate this, we just “double delete” or “permanently delete” events so they are completely out of the system. Again, this works great.
The problem is that recently we started getting reservation lists sent for events that have been completely deleted out of the system. I’ve checked the phpmyadmin area and can see that the events are completely deleted in the wp_events_detail area. But lists are still being sent.
I do not think this is an issue with event espresso. Our server (Siteground) recently moved all dedicated servers into a cloud environment. The problem started shortly after this. I’ve checked with SiteGround and there is no caching on the server.
Again, don’t think this an EE issue at all. I am only reaching out to see if you have any ideas of what may be causing this or anywhere the events might be “temporarily stored” after being permanently deleted? I’ve been banging my head against the wall trying to get it figured out but am at a loss.
If you have ideas, I am happy to purchase a support token for some assistance.
|
|
Tony
|
March 22, 2020 at 7:15 am
Hi Jason,
Again, don’t think this an EE issue at all. I am only reaching out to see if you have any ideas of what may be causing this or anywhere the events might be “temporarily stored” after being permanently deleted?
Nope, when an event is permanently deleted it calls DELETE on the database row with no other actions.
HERE is the function that is called when an event is perm deleted, we pass it the event id and it basically all references to it, including the attendees linked to it.
I’ve checked with SiteGround and there is no caching on the server.
To be honest, I’d put money on this being incorrect or they have some form of load balance set up and copy the database/file changes across those but it isn’t quick enough to prevent the above (we’ve seen something like happen previously with another host) as this doesn’t make sense otherwise.
However, what you could do is change your code to exclude events with an event_stats of D, meaning you exclude the ‘soft’ deleted events anyway. That isn’t going to solve the problem of apparently deleted events triggering emails to what should be deleted attendees….. but if your code is excluding them anyway it shouldn’t matter.
If you can share the code you are using on the cron we can advise how to do that.
|
|
Jason Lee
|
March 23, 2020 at 6:09 pm
Absolutely, Tony. Thank you for your help.
I’ll attach the code as a private reply. Feel free to use that however you want. If you want to add it in as a feature to EE3, go for it 🙂 It pulls the emails from the venue manager and sends an hour after registration closes.
I reached out to the server company, and am still trying to figure that all out. It looks like the old server was still active, so it’s possible that may have been the culprit. Running test now to see.
|
|
Jason Lee
|
March 23, 2020 at 6:09 pm
This reply has been marked as private.
|
|
Tony
|
March 24, 2020 at 5:49 am
$rows = $wpdb->get_results("SELECT * FROM $table_name WHERE event_status != 'D'");
Will solve the problem with events that have been soft deleted still sending emails, deleted events can’t send emails as they don’t exist which is why I said above that caching would make sense, but if your old server was/is active that’s a much more likely cause 🙂
However, there is a lot you can do to optimize here and you do some of it already but don’t include it in the main query itself which likely hasn’t been an issue because your perm deleting events and don’t have high numbers of ‘future’ events.
As a quick example, your pulling every event from EE, new, old, expired, upcoming, you name it and then looping over all of them to perform additional queries to pull in the venue details etc then comparing the dates/times and sending emails based on that, right?
So simply moving the date check to happen at the beginning of the $rows loop before you pull in all of the additionla details will reduce the number of ‘unneeded’ queries there. Then just doing something like:
$rows = $wpdb->get_results("SELECT * FROM $table_name WHERE event_status != 'D' AND registration_end = '". date('Y-m-d') . "'");
For the main query means you only pull the events with a registration end date of today as that’s all you are really interested in this script anyway. That would reduce this down even more and would help if you used this on a site with recurring events which could easily have thousands of events both new, old and deleted.
Note I’m not trying to bash your code at all, just simply offering some tips to optimize it.
|
|
Jason Lee
|
March 24, 2020 at 8:09 am
Thanks Tony! And no worries…php is above my skill level set, this was outsourced to someone else who wasn’t super knowledgeable about EE. Would you be open to some outside work/getting me a quote on what it might cost to help clean the code up on it? You can email me directly if need be
|
|
Tony
|
March 26, 2020 at 4:20 am
For the optimizations I mentioned above we could likely add those with a support token and that would reduce the load required by that script a fair amount although it really depends on the number of events if the current load would cause issues.
|
|
Jason Lee
|
March 27, 2020 at 4:46 pm
Absolutely. Purchasing now
|
|
Jason Lee
|
March 27, 2020 at 5:11 pm
Support token redeemed
|
|
Tony
|
March 31, 2020 at 5:45 am
Hi Jason,
Just posting here that I have replied directly to your support token via email.
|
