Support

February 24, 2025 at 4:51 am

Hi there,

So there’s a lot going on this post and I’m more than happy to help troubleshoot this, but I’m going to start by answering your questions directly and then work from there. My answers will be direct and short to simply not add any additional noise and are not intended to be dismissive to any issue/queston.

1. Customers unknowingly check out with incorrect registrations
Users add camps to their cart, but when they return to the site, they do not see their previous cart contents.
However, during checkout, the backend still processes old cart items that were not visible to the user.

Return to the site? Return from where?

How long between the visit and the return?

So in an EE Transaction you can see both the new Registrations and the old ones?

What shows up in the line_items section?

Top section here: https://monosnap.com/file/OkGW6goOc5qCqZMdzXiOxL48pZs9gO

2. Hidden registrations suddenly appear after issuing a refund
Initially, I saw (2/5) registrations in the backend, but in the confirmation email, I discovered there were actually (5/5) registrations.
The extra registrations were not visible in the cart before checkout but were processed in the transaction.
After issuing a refund for two camps, the missing three registrations suddenly appeared in the backend.
Why did these registrations remain hidden until a refund was processed?

This one I can’t answer as it’s not at all expected and not something I’ve seen before.

Where did you see the 2/5 registrations? Which specific output?

When you issued the refund, did you apply it to all registrations within the transaction? What did you set the Change Registration Status to?

These: https://monosnap.com/file/ERncmf7rV45D0zwgzWoPbJnuHBL3fd

3. Incomplete registrations and lost registrations
Some registrations do not get recorded properly and are missing from the backend.
We have had to manually re-register users and apply their payment to a new registration.

Usually, when I see reports like this, it’s caching. I have no idea on your site setup so I’m not saying it is but missing registrations happen when the request for a previous session essentially overwrites the next.

You mention caching further down so ask for details there.

4. Payment system & refund issue
When we manually corrected an incomplete registration:
We re-registered the customer and added their payment to the new registration.
When we went back to delete the original payment, it wouldn’t let us.
When we issued a refund for both camps, the hidden registrations suddenly appeared.
Could there be a database issue where old registrations are linked to transactions incorrectly?

When you say it wouldn’t let ou delete the original payment, what happened? Did it show any messages?

Payments are directly related to registrations, they are related to the Transacton so issues with a payment in relation to a transaction should change linked registrations. In short, everything you’ve put in this point sounds unexpected so I can’t tell you why currently.

5. Old, canceled registrations will not delete because they are “locked”
Some registrations remain stuck in the system and cannot be deleted.
How can we safely unlock and remove these registrations?

If I understand correct then Registrations are locked when there are payment objects assigned to the EE_Transaction the regs are linked to, you can’t delete registrations until the payment objects have been deleted (note a refund is still a ‘payment object’ linked to the transaction, they all need to be removed prior to deleting).

6. Interest in Archiving Older Registrations & Resetting the System
If archiving older registrations would help resolve these issues, we are interested in archiving past data to clean up the system.
We would also like guidance on whether a system-wide reset of Event Espresso would be beneficial in resolving these recurring problems.

I can’t give you a definitive answer to this; there are too many variables and too many unknowns.

Key Questions for Troubleshooting

How does Event Espresso handle cart session persistence?

We use the PHP Session ID and save the data to the EE Transaction line items (esp_line_items) as they are added/removed from the cart.

Where is cart data stored (session, database, cookies)?

The only thing we use the PHP Session for is the ID, everything is stored in the DB.

How can we prevent old cart data from being processed at checkout?

Define ‘old’?

In terms of Event Espresso the default session lifespan is 1 Hour, EE should be keeping the session data active for that timeframe but after that a new session should start. So ‘old’ data by default would be cart data over an hour old but I’m not sure what you timeframe is with the issues above.

If a user leaves the site and returns, how do we ensure they do not unknowingly submit an old, invisible cart?

Simply having an old, invisible cart is unexpected so I can’t answer this as they shouldn’t have one to begin with.

Are there specific hooks or settings to prevent stale cart items from carrying over to checkout?
Is there a recommended way to integrate cart session expiration?

EE already has session/cart session management built into it, so the question here is what would you do on those hooks? I ask becuase I’m 99% certain EE will already be doing this anyway

‘Something’ is going wrong somewhere here, but the point is that EE already manages the cart/session, so ‘something’ on the site is breaking ‘something’; otherwise, we’d have these issues everywhere. Yes I know that’s vague as this isn’t expected and not something I’ve seen at this scale.

If a user leaves the site for more than 10 minutes, how can we automatically clear their cart when they return? Is there a setting to expire the cart session and force a fresh start?

EE allows you to set the session lifespan in:

Event Espresso -> Registration Form -> Reg Form Session -> Session Settings

There is an option for 5, 15, 30mins (plugs higher), the lowest I recommend using is 15.

Could caching be affecting cart visibility?
Should we exclude any specific URLs from caching in our server settings?

Caching will affect everything related to E-commerce. You can’t cache e-commerce requests as Visitor A’s request will always be different to Vistor B+ etc.

We already set headers, use query string params etc but you can add the EE critical pages and your /events/ endpoint to the do not cache section of which caching you are using:

https://eventespresso.com/wiki/setup-nocache-exclusion-rules-event-espresso/

The issue seems to occur even when users refresh the page, but could cached session data be interfering?

If the user refreshes the page but the server has a cached response, they’ll get that cached response, but yes, cached data can and will cause problems like this (although some of what you’ve posted I’ve never seen).

What debugging steps do you recommend to track what is happening in cart sessions?

The first step here is to make sure caching is disabled on the above URI’s.

Which caching plugin are you using?

Server-side caching?

Until we can narrow this down a little any steps I can give you are total guesses on trying to narrow it down.

Are there logs or debugging tools within Event Espresso that can show how cart data is being stored and retrieved?

Nothing that is intended to be used publicly, these debug output within some sections of EE, which we use to troubleshoot but a lot of this won’t make sense without seeing the request/response/log and comparing them all together, so there’s nothing you can send over for us to work through to troubleshoot this.

How can we permanently delete canceled or locked registrations?
Why are some registrations “locked,” and how can we remove them?

Cancelled registration you can trash but not delete (only as part of the whole group).

To completely remove registrations, trash the payment object linked to the transaction, and the registrations should unlock.

The intention of the lock was/is to prevent users from deleting registrations that have payments assigned to the transaction.

Why did hidden registrations suddenly appear when issuing a refund?
Could this indicate hidden database records linked to payments that are not visible in normal transactions?

I’ve never seen either of those events, so I can’t answer ‘why’ (I’d love to, but it’s just not something I’ve seen/expected).

With regards to hidden database records, issuing the refund would just change the Reg status of the registration to whatever was set at the time of issuing the refund, so, I wouldn’t expect doing so to suddenly show some ‘hidden’ record but again, this is completely unexpected so it’s possible… although very strange!

Again, I am willing to purchase a support token if that is necessary to resolve this issue quickly.

I need to note in case it isn’t clear from the above and to manage the expectation of a support token here.

Support tokens are intended to cover issues we don’t cover under our support license, they give 30 mins of time to address a pain point for a customer. For example, a plugin conflict or working through an issue the user is having and wants 1-on-1 support (we are generally flexible on what we work on with them, but it’s a balance we assess on a case-by-case basis).

A lot of what you’ve posted above is not expected to happen, and we already have code within EE that would manage sessions (which seems to be the biggest cause of issues based on the post) so I can’t guarantee that purchasing a token will fix this ‘quickly’ as right there’s no clear indication of ‘what’ is wrong. If it were consistently reproducible, then maybe so, but intermittent issues with totally unexpected/unseen issues could be hours and hours of debugging not only from me but others on the team.