|
tbex
|
November 16, 2021 at 2:08 pm
Hi guys,
So we are having this problem again with another event. Here is the earlier thread:
https://eventespresso.com/topic/attendees-receiving-incorrect-confirmation-data-emails-sent-to-wrong-attendees/
Tony should recall the situation well. I have read his previous emails to me and his notes in the earlier thread but I still cannot figure out how to fix this myself.
I deleted all of our events on our subsite for the event and recreated them. The problem is still happening.
What I think I need to do is delete the tables somewhere that are causing this problem?
But I have no idea how to do that.
Please help.
|
|
Tony
|
November 17, 2021 at 6:17 am
Hi Rick,
I do remember this issue well, it was an interesting issue very different from the normal so sticks out 🙂
We ended last time with the events being on the main site rather than subsites, has that now changed?
Are you back to using the same site you originally had this issue on?
|
|
tbex
|
November 17, 2021 at 8:43 am
So we have two different events that we register our attendees for. The conference which has a charge, and the our tours which are free.
We moved all of our conferences to the main site, but we are trying to keep our tours on each individual event site.
Also with the fix you helped with last, we were able to make registration work on an event sub-site of our WP Multi-site install. I think we accomplished this when you deleted some tables.
We have just opened tours for a new event on a different sub site on our multi-site. That is when we noticed the problem.
|
|
Tony
|
November 17, 2021 at 3:41 pm
Was that subsite created a while back? Meaning before I fixed the previous issue?
To fix this all EE4 data needs to be removed from the site, we have an option to do that from within Event Espresso 4 itself which IIRC is what I did on the subsite.
(Note you lose all your current EE4 data on the site that you do this on)
However, before moving forward, please create a database backup of not just the individual subsite we are about to reset, but a full database backup. If something goes wrong you’ll need it to get back up and running (EE is DROPPING tables, its best not to skip this just to be safe).
|
|
tbex
|
November 17, 2021 at 6:03 pm
Yes it was created before you fixed the previous issue. Our site is backed up every 24 hours so im good to go on the DB back up.
How do I do this part? “To fix this all EE4 data needs to be removed from the site, we have an option to do that from within Event Espresso 4 itself which IIRC is what I did on the subsite.”
|
|
Tony
|
November 18, 2021 at 2:37 am
On the subsite, go to Event Espresso -> Maintenance.
On the tabs at the top of that page go to ‘Reset/Delete Data’.
Click the ‘Permanently Delete ALL Event Espresso Data’
That will drop all EE tables from the current DB and should remove the EE_Attendee ‘posts’ from your site (which is part of this problem).
Again just to be really clear, you’ll lost everything regarding EE on that site and need to set it up from scratch.
|
|
tbex
|
November 18, 2021 at 8:00 am
Thank you Tony, just to be clear as well. You mean, we need to recreate all events and reenter all attendee data correct?
|
|
Tony
|
November 18, 2021 at 8:15 am
Yep, on that specific subsite everything for Event Espresso will be deleted.
The problem is due to site migrations and only half the data being moved, which then breaks the relationships used in Event Espresso. So the options are to go through and manually correct those (or pragmatically but this is a pretty bespoke issue so would likely take longer than fixing it) or reset and start again on that site with EE.
|
|
tbex
|
November 18, 2021 at 8:48 am
I think I just realized something here that will fix this . When we create new events / subsites in the future which are clones from our master event template, I can repeat the process you listed above before I create the EE events. This should prevent this from happening. I will report back after testing it for the next event.
|
|
Tony
|
November 18, 2021 at 8:53 am
If the subsites are clones of another site, would it not be best to fix the ‘original’ (the site you are cloning)?
That way you fix it once and future sites are fixed by default.
|
|
tbex
|
November 18, 2021 at 8:54 am
I am actually going to do both to be double sure 8)
|
|
Tony
|
November 18, 2021 at 9:13 am
Lol, good stuff.
Let me know if I can help at all 🙂
|
