Support

June 11, 2019 at 7:34 am

Hi,

The event ID is actually a WordPress post ID, so it shouldn’t follow sequence for events only. In other words, other posts added to your site (posts, pages, post revisions, venues, menu items, attendees, and any other custom post types) also get post IDs.

You might try the transaction ID for your invoicing system instead.

June 11, 2019 at 7:56 am

Is there a way I can begin the transaction ID at a specific number – i.e. 7800 – to avoid issue with my accounting? If not, no worries.

One way to do this would be do a test transaction where you won’t care about some orphaned data, and then go into the database and change its transaction ID to 7799. This will make it so the next transaction ID will be 7800.

It just seems strange that the EVENT ID is missing the sequence too. Any ideas on that?

I actually explained that in my reply above. Here’s that explanation again:

The event ID is actually a WordPress post ID, so it shouldn’t follow sequence for events only. In other words, other posts added to your site (posts, pages, post revisions, venues, menu items, attendees, and any other custom post types) also get post IDs.

Here’s a screenshot of a tiny part of a typical WordPress posts table that shows the types of post types (including espresso_events) that helps illustrate why you’ll see gaps in event IDs:

https://slack-files.com/T02SY781D-FK45WE8EN-8b6d3d63c8

June 12, 2019 at 11:51 am

This code is not showing the corresponding value for the transaction ID

May I ask what is the transaction ID for the transaction, and what is it showing?

June 12, 2019 at 3:14 pm

[REGISTRATION_ID] which can be inserted into the [ATTENDEE_LIST] template section.

June 13, 2019 at 2:08 pm

[TXT_ID] was never available as a shortcode in the invoice. Are you sure you were using [TXT_ID] in the invoice?

Plus I tried the trick with the changing the transaction ID to 7799, so that the next transaction ID would be 7800, but when I tried this the next generated transaction ID was 691 – it has assumed that the 7799 value was 690 (even though I edited it) and followed chronologically from their.
What am I doing wrong Josh.

I think you may have edited the wrong database table.

June 14, 2019 at 3:49 am

[TXN_ID] was/is the shortcode on my invoice template , sorry. Was there an update at the end of March ’19 that prevented this from working, or a known issue with another plugin that has caused it to slip out of order?

There has been no update to how the TXN ID is generated, nor are we are of any plugin conflict.

However, TXN_ID’s are generated (and have always been generated) very early on. They are generated when a registration is created and that happens as soon as the user selects a ticket and submits the ticket selector (before they have entered anything else on the site). Its not ‘per visit’ but it is ‘per ticket selector submission’.

To see what I mean, open up your registrations list table (Event Espresso -> Registrations).

Click on the ‘Incomplete’ view and take note of the number of registrations, my example has 27 – https://monosnap.com/file/MgrRL3SOlK9WbRqkbh1vUbS8jdBCZL

In another tab, go to an event and select at least 1 ticket on the ticket selector, then submit – https://monosnap.com/file/dE56VPDA5PUo9bycfLrafMolLX7Cb6

Now stop, don’t go any further on that tab. Switch back to the other tab with the incomplete registration list and refresh it. Now you’ll have another Incomplete registration assigned to a ‘Failed’ transaction – https://monosnap.com/file/yuJpkHWw4TxdwbGgUtUgbK8Itko8RQ

(See I now have 28 regs in the list and TXN Date (and time) is a couple of minutes ago for me, UK time)

Every registration (and group registration) must be assigned to a transaction, so when a single (or group) registration is created, a TXN is created and assigned to it, even this early.

If you click on the TXN Date you’ll see it has a Transaction # value, why? Because that ID is the auto incrementing row ID in the DB table, when a row is added, it gets an ID. That’s the TXN ID and it means it is NOT chronological in the way you are expected, again note that it has always worked this way, this is not new.

It jumped from [TXN_ID] 661 to [TXN_ID] 1001. It then continues 1004, 1005, 1162, 1444, 1796.

So in short, this means the ticket selector was submitted X number of times and then nothing happened with those registrations, but the auto incremented ID was incremented when the TXN row was created.

I have checked for ‘incomplete’ or ‘trashed’ registrations, in an attempt to locate the missing values, but they are know-where to be found – not even in the database.

‘Incomplete’ registrations (like the ones shown in my screenshots) are registrations that do not have a ‘contact’ assigned to them, meaning the ‘Attendee information’ step was not completed during that session.

EE will automatically remove those registrations (and their transactions) after 1 week (by default), which is likely why you can’t find them.

—-

The fact that the TXN_ID worked chronologically for your previously means either your site didn’t get much traffic and the majority (if not all) traffic was valid and now your getting bots, users or both, submitting the ticket selector and not completing the registrations.

June 14, 2019 at 9:26 am

That could be a bot. When bots find a form, they’ll submit it. In this case a bot may have found the page with the ticket selector form. Event Espresso 4 will trash any transactions that didn’t submit the registration form later, so that’s why you’re not seeing them in the incomplete or trash tabs.

What you could do is activate reCAPTCHA for the ticket selector only (this is set in the Event Espresso > Registration Form > Settings page.

If you’re comfortable with editing .htaccess, you can also follow this guide to identify and block the bot:
https://perishablepress.com/block-bad-bots/#bbb04

June 14, 2019 at 11:24 am

Two things:

1) You’ll need to set the reCAPTCHA option to protect the ticket selector, not the registration form

2) event-espresso-core-master-backup sounds like a GitHub build. You might find that if you switch to the current production build of Event Espresso 4 ( download from your account page and install that one ) the error will go away.

June 17, 2019 at 7:53 am

Hi,

If you deactivate the Event Espresso plugin for a few minutes do the additional TXN records continue to add on or do they stop?

June 17, 2019 at 10:50 am

Thanks for checking. Can you also try deactivating the Multi Event Registration add-on for a few minutes, and check to see if additional TFL transactions are being added while that add-on is deactivated? (with Event Espresso 4 core plugin activated).

June 17, 2019 at 3:49 pm

Thanks for checking. Do you have another site that’s hosted on the same server where we could do some troubleshooting to find out what’s initiating new transactions?

June 18, 2019 at 4:03 am

The first thing I would do is set up a clean test site and install only EE and the matching add-ons that you have on the live site.

Add some events and some registration and then watch to see if transactions are created like on the live site.

I suspect it is some form of caching on the live site that is causing this although we already set no-cache headers and jump through various hoops to try and make sure the requests are not cached. So try with all caching disabled on the new site, then test again with caching enabled (note you’ll need to run some registrations whilst NOT logged in to initiate caching but even then you may not cause the same issue).