|
KBrownlee
|
July 3, 2020 at 5:58 am
We’ve had two customers contact us because the event registrations they placed (using offline payment methods) have disappeared from our site. They were issued with invoices to be paid, but all record of their tickets, registrations and transactions are gone. We have downloaded a database backup from our host (WPEngine) from the day after one of the registrations was made, and can confirm we see the expected data in the wp_esp_registration table. If we check this table today, the rows are missing.
There has been no unauthorised access to the site nor its hosting.
Are there any circumstances under which data would be purged by Event Espresso itself?
|
|
Tony
|
July 7, 2020 at 9:09 am
Hi there,
Apologies for the delayed reply.
We have one method which removes registrations on a cron schedule here:
https://github.com/eventespresso/event-espresso-core/blob/master/core/EE_Cron_Tasks.core.php#L517-L525
EE_Maintenance_Mode::instance()->models_can_query() just confirms that EE isn’t in full maintenance mode.
EED_Ticket_Sales_Monitor::reset_reservation_counts(); as the name suggests resets the ticket reservation count for expired sessions (no registrations etc removed there).
So the start is EEM_Transaction::instance('')->delete_junk_transactions();
Which is shown HERE.
The default query_args (filtered so may well have been changed by other code on the site) checks for transactions with a ‘failed’ status, note this is NOT a failed payment status, but a transaction status of failed which is set when the transaction is first created.
AND no payment objects associated with the transaction at all (invoice wont have any payment objects)
AND are older than 1 week (again 1 week by default, the value is filtered).
Any transactions its finds that match, it removes.
Then we run EEM_Registration::instance('')->delete_registrations_with_no_transaction(); found HERE.
Deletes any registrations in which a transactions doesn’t exist for (every registration within EE should be assigned to a transaction unless the above removed it).
Finally EEM_Line_Item::instance('')->delete_line_items_with_no_transaction(); found HERE. Which removes line items that belong to Transactions in which the ID doesn’t exist.
So for that cleanup job to remove the registration it all starts from the transaction and it needed to have a status of ‘TFL’ in the database (which it should not if the user made it even to the payment options step), so if you have the database saved, check the esp_registration table, find the registration in question and note the TXN_ID linked to it. What value is it?
Then check esp_transaction and check the STS_ID for the row using that TXN_ID, what is it?
|
|
KBrownlee
|
October 30, 2020 at 10:54 pm
Thank you so much for the incredibly detailed response. At the time, I wasn’t able to do anything with this information, because the events in question had occurred long enough ago that our database backups showed nothing particularly useful. However, the scenario I originally described happened again last week.
On October 22, we had someone attempt to register for an event, but abandon their registration at the Payment Options page. In a database backup taken later that day, I can find an entry in esp_registrations with REG_ID=1958 and STS_ID='RPP', and I can find an associated entity in the esp_transactions table with TXN_ID=1093 and STS_ID='TIN'. If I look in our database today, the entry in esp_registrations is gone, but the transaction entity still exists, with STS_ID='TCM'.
Based on the Cron you outlined above, it doesn’t seem like this registration would have qualified for purging. Are there any other circumstances where this might happen? What happens if we disable that cleanup cron completely?
|
|
Tony
|
November 2, 2020 at 4:07 am
If you check the backup and view the entry in esp_registration, is the TXN_ID set on the row?
I’m assuming so based on the fact that you mentioned you can find the associated transaction but the only other reason I can think for a registration to be deleted is TXN_ID being somehow set to 0.
The transaction is obviously still there, so it’s not a line item/transaction which would be where the cleanup starts.
Are there any other circumstances where this might happen?
None that I can find/think of. It’s also very odd that it is just the registration row.
What happens if we disable that cleanup cron completely?
The cron is also used to ‘release’ the reserved tickets (tickets that have been submitted but then not complete) so if you disable it, you’ll end up selling out your event without it actually being sold out.
Have you tried creating a development copy of the site using the database backup you have and seeing if the row is removed if you leave that site for a little? If so then it’s reproduceable and we may be able to debug that further.
|
