|
wmnf
|
September 10, 2015 at 9:11 pm
I was the original poster of this thread…..
https://eventespresso.com/topic/multiple-warning-of-invalid-table-data-2/
I was told to ignore and dismissed the warnings received the other day. We have not had any reported issues, but found something today that is a bit troubling. I noticed the transaction ID’s skipping a lot of numbers and could not find anywhere in EE4 transactions under any status. So, I did a query of the database and find lots of records in the wp_esp_transactions table with a STS_CODE of FAILED and no matching record in wp_esp_registrations. I also found these large numbers of FAILED transactions started exactly the same night the upgrade was done, 9/4. Since that time, there are hundreds of FAILED transactions where they are very rare prior to that time. Can you help determine the issue?
Again, no issues reported and we are receiving registrations every day, but I really need to find out why there are so many FAILED transactions without a registration record.
|
|
wmnf
|
September 10, 2015 at 9:44 pm
I see the advice to dismiss warnings in the original post came from another user. Nonetheless, we didn’t receive the warnings for a couple of days after the upgrade, a user noticed in the dashboard. I tested the system after all the upgrades the one night, all worked fine and it seems to work fine now. Again, from my original post, I updated all plugins including EE4 as well as WordPress to version 4.3 from 4.2.4 on the one night of 9/4 without any warnings or errors. The EE4 database upgrade was done after the plugin updated and was successful.
|
|
wmnf
|
September 10, 2015 at 9:48 pm
Also, I do have daily backups of the database since the night of the upgrades and could examine, but it would be a difficult restore with all the registrations since. We have a dev site that all of the upgrades were tested on prior to doing on the production server where the issue exists (wouldn’t you know it? :-/)
|
|
Tony
|
September 11, 2015 at 4:44 am
I’m going to explain a little about those messages to hopefully help you understand where they come from.
EE stores a history of you database updates within espresso_db_update as a serialized array. When EE updates the database it checks this value and compares your current EE tables with what you should have.
Lets say your site had 4.6.X installed last and your installing 4.8.9 now. EE looks at espresso_db_update, sees you have 4.6.X installed and compares your database tables, so then if you have (for example) wp_esp_promotions already available (which wasn’t released with 4.6.X) its likely that table should not actually be there it could have been from using a beta version or restoring tables from a backup without wiping others.
Make sense?
Now the problem appears to be that somehow, something is hooking in and removing the espresso_db_update values. So EE looks within espresso_db_update, finds nothing, but then finds all of these EE tables that you are currently using and assumes they shouldn’t exist, so throws the warnings.
I’ll double check with the developers to make sure nothing with this has changed (or I’m missing something important out) but that’s an overview if where the messages are coming from. We have an open ticket to track down how this happens and try to prevent it.
Now the failed transactions.
Failed transactions are not an indication of a problem. A failed transaction is created as soon as you start a registration, you can test this by selecting some tickets within an event and clicking to register.
Don’t input details but in a new tab look within Event Espresso -> Registrations. Click the Incomplete view – http://take.ms/nh8VD
You’ll find a new registration there. Take note of the ID.
Registrations always need a transaction, so a ‘Failed’ transaction is created. (Click the TXN date for that registration to view it) again take not of the transaction ID.
Now back in your old tab, input user details and click through, stop when selecting payment options.
Back to viewing your Registration/Transactions. You’ll notice they have updated and are no longer Incomplete/Faild (Registration/Transaction) but Pending Payment/Abandoned. (You’ll need to now view the main registration list for these, use the ID to identify the correct reg/txn)
Select a payment method and finalize. Again the Status will update.
So failed transactions can be from selecting a ticket then closing the browser.
So, I did a query of the database and find lots of records in the wp_esp_transactions table with a STS_CODE of FAILED and no matching record in wp_esp_registrations.
The incomplete registrations are removed using a cron after a certain amount of time, the same should happen with the transactions for those registrations, it sounds like registrations are being removed but not the transactions.
I have requested some feedback from our developers on this.
|
|
wmnf
|
September 11, 2015 at 5:52 am
Yes, all of what you are saying makes sense. But these FAILED transactions I see by running a query of the database do not show up in EE4 as you mentioned, the ID’s are not found in registrations or transactions. If I pull up a transaction and manually change its TXN_ID in query string to one of those unfound FAILED transactions that I find in the wp_esp_transactions, I get this error….
Fatal error: Call to a member function get() on a non-object in /wp-content/plugins/event-espresso-core-reg/admin_pages/transactions/Transactions_Admin_Page.core.php on line 620
And all of these transactions I find in the database do not have a registration associated with them, for instance, the last transactions/registration I can find this morning in EE4 was TXN_ID 33870. I don’t show any Incomplete transactions since yesterday. This query selects all transactions since that TXN_ID with matching registrations, take a look at the results:
MariaDB [wmnf_www]> SELECT 'wp_esp_transaction'.'TXN_ID','wp_esp_transaction'.'TXN_timestamp','wp_esp_transaction'.'TXN_total','wp_esp_transaction'.'TXN_paid','wp_esp_status'.'STS_type','wp_esp_status'.'STS_code','wp_esp_registration'.'EVT_ID','wp_posts'.'post_title'FROM'wp_esp_transaction'LEFT OUTER JOIN'wp_esp_status'ON ('wp_esp_transaction'.'STS_ID'='wp_esp_status'.'STS_ID') LEFT OUTER JOIN'wp_esp_registration'ON ('wp_esp_transaction'.'TXN_ID'='wp_esp_registration'.'TXN_ID') LEFT OUTER JOIN'wp_posts'ON ('wp_esp_registration'.'EVT_ID'='wp_posts'.'ID') WHERE'wp_esp_transaction'.'TXN_ID'>= 33870 ORDER BY'wp_esp_transaction'.'TXN_ID'DESC;'
+——–+———————+———–+———-+————-+———-+——–+———————————————+
| TXN_ID | TXN_timestamp | TXN_total | TXN_paid | STS_type | STS_code | EVT_ID | post_title |
+——–+———————+———–+———-+————-+———-+——–+———————————————+
| 33903 | 2015-09-11 11:47:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33902 | 2015-09-11 11:41:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33901 | 2015-09-11 11:41:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33900 | 2015-09-11 11:40:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33899 | 2015-09-11 11:33:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33898 | 2015-09-11 11:27:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33897 | 2015-09-11 11:27:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33896 | 2015-09-11 11:26:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33895 | 2015-09-11 11:20:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33894 | 2015-09-11 11:16:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33893 | 2015-09-11 11:16:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33892 | 2015-09-11 11:16:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33891 | 2015-09-11 11:15:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33890 | 2015-09-11 11:11:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33889 | 2015-09-11 11:10:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33888 | 2015-09-11 10:57:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33887 | 2015-09-11 10:57:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33886 | 2015-09-11 10:47:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33885 | 2015-09-11 10:42:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33884 | 2015-09-11 10:28:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33883 | 2015-09-11 10:24:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33882 | 2015-09-11 10:16:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33881 | 2015-09-11 10:16:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33880 | 2015-09-11 10:15:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33879 | 2015-09-11 10:14:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33878 | 2015-09-11 10:13:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33877 | 2015-09-11 10:10:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33876 | 2015-09-11 10:03:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33875 | 2015-09-11 10:00:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33874 | 2015-09-11 09:59:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33873 | 2015-09-11 09:57:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33872 | 2015-09-11 09:57:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33871 | 2015-09-11 09:45:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33870 | 2015-09-11 09:43:00 | 36.000 | 36.000 | transaction | COMPLETE | 64865 | WMNF 36th Birthday: Suenalo plus Resinated |
| 33870 | 2015-09-11 09:43:00 | 36.000 | 36.000 | transaction | COMPLETE | 64865 | WMNF 36th Birthday: Suenalo plus Resinated |
| 33870 | 2015-09-11 09:43:00 | 36.000 | 36.000 | transaction | COMPLETE | 64865 | WMNF 36th Birthday: Suenalo plus Resinated |
+——–+———————+———–+———-+————-+———-+——–+———————————————+
36 rows in set (0.00 sec)
Again, I have a lot of FAILED transactions in between each known transactions that I can see in EE4. At first I thought this might be spammers hitting the form, but it all started after the upgrade, rarely a FAILED transaction in the database prior to the upgrades last week.
-
This reply was modified 9 years, 2 months ago by
 Tony. Reason: code format
|
|
wmnf
|
September 11, 2015 at 6:01 am
So, if I try to pull up this transaction using the last TXN_ID shown above…
/wp-admin/admin.php?page=espresso_transactions&action=view_transaction&TXN_ID=33903
I get the error mentioned before….
Fatal error: Call to a member function get() on a non-object in /var/www/html/wmnf/www/wp-content/plugins/event-espresso-core-reg/admin_pages/transactions/Transactions_Admin_Page.core.php on line 620
|
|
wmnf
|
September 11, 2015 at 6:15 am
And now, just a few minutes since I ran my query, there have been several more FAILED transactions created in the database and find no additional transactions in EE4 Incomplete or otherwise….
+--------+---------------------+-----------+----------+-------------+----------+--------+---------------------------------------------+
| TXN_ID | TXN_timestamp | TXN_total | TXN_paid | STS_type | STS_code | EVT_ID | post_title |
+--------+---------------------+-----------+----------+-------------+----------+--------+---------------------------------------------+
| 33908 | 2015-09-11 12:10:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33907 | 2015-09-11 12:09:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33906 | 2015-09-11 12:08:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33905 | 2015-09-11 11:56:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33904 | 2015-09-11 11:54:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 33903 | 2015-09-11 11:47:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL
|
|
Tony
|
September 11, 2015 at 6:21 am
Hmm, strange.
I have requested some developer feedback on this and will get back to your as soon as I can.
(Due to time differences it may take a little but we are investigating)
|
|
wmnf
|
September 20, 2015 at 5:16 pm
Any feedback from developers yet? I continue to build up these transactions and it would be nice if I could resolve to get sequential numbering back again.
|
|
Lorenzo Orlando Caum
|
September 21, 2015 at 2:05 pm
Hi, I asked a developer to look at this and he shared that you may be experiencing junk transactions caused by bots. Could you upgrade to Event Espresso 4.8.10 (released today)?
It includes a stronger feature to reduce bot registrations.
—
Lorenzo
|
|
wmnf
|
September 25, 2015 at 9:26 am
We are running 4.8.10p, is there no where these bot registrations will show up in the admin area? The only place I can find these transactions are in the database with a custom query. We have been running 4.8.10 all week and still receiving many of these transactions.
|
|
Lorenzo Orlando Caum
|
September 25, 2015 at 10:46 am
Hello, you should see see incomplete registrations which are registrations that have not been completed since they do not have any contact information in the Incomplete area of the registrations overview screen. The link appears next to the Trash link on that screen.
—
Lorenzo
|
|
wmnf
|
September 25, 2015 at 2:07 pm
Again, I do not find these ID’s in the Incomplete list. That list shows a total of 72 Incomplete registrations, but all of those records have an associated event. The records I am finding in the database do not show any association with an event and do not show up in the Incomplete list. For example….
| TXN_ID | TXN_timestamp | TXN_total | TXN_paid | STS_type | STS_code | EVT_ID | post_title |
+--------+---------------------+-----------+----------+-------------+----------+--------+-----------------------------------------+
| 41114 | 2015-09-25 19:20:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 41115 | 2015-09-25 19:35:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 41116 | 2015-09-25 19:38:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 41117 | 2015-09-25 19:41:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 41118 | 2015-09-25 19:43:00 | 17.000 | 17.000 | transaction | COMPLETE | 64795 | MarchFourth! plus UNRB, plus Sepiatonic |
| 41119 | 2015-09-25 19:43:00 | 17.000 | 17.000 | transaction | COMPLETE | 64795 | MarchFourth! plus UNRB, plus Sepiatonic |
| 41120 | 2015-09-25 19:44:00 | 34.000 | 34.000 | transaction | COMPLETE | 64795 | MarchFourth! plus UNRB, plus Sepiatonic |
| 41120 | 2015-09-25 19:44:00 | 34.000 | 34.000 | transaction | COMPLETE | 64795 | MarchFourth! plus UNRB, plus Sepiatonic |
| 41121 | 2015-09-25 19:50:00 | 0.000 | 0.000 | transaction | FAILED | NULL | NULL |
| 41122 | 2015-09-25 19:57:00 | 17.000 | 0.000 | transaction | FAILED | 64795 | MarchFourth! plus UNRB, plus Sepiatonic |
I only find ID 41118. 41119, 41120 and 41122 in the Incomplete list from the records above. None of the others with NULL EVT_ID are showing up.
|
|
wmnf
|
September 25, 2015 at 2:08 pm
There are hundreds of these records in the database, adding up everyday day more and more.
|
|
Josh
|
September 25, 2015 at 4:01 pm
Hi there,
Do you have a plugin on your site such as Block Bad Queries to help with blocking spam form submissions? If not, do you have a staging server where you can test out a spam blocking solution?
|
|
wmnf
|
September 26, 2015 at 7:38 am
Yes, I have a staging server. Should I install that specific plugin and how would I test that it is working well on a dev server?
|
|
Josh
|
September 28, 2015 at 1:34 pm
That’s a good one to try when there’s potentially an issue with bots hitting your site. The thing you’ll want to verify on staging is to make sure things like contact forms and registration forms, and payment notifications all continue working as expected with the plugin activated.
|
|
wmnf
|
September 29, 2015 at 9:59 am
I have tested on the dev site and enabled BBQ on our production site, but the transactions continue to build up. Any other ideas?
|
|
wmnf
|
September 29, 2015 at 10:01 am
Again, never had this issue prior to the upgrade. It started happening that very week we did the upgrade.
|
|
Lorenzo Orlando Caum
|
September 29, 2015 at 10:16 am
Hi, I replied to your other support post earlier today.
Did you update to a current release from this week?
—
Lorenzo
|
|
wmnf
|
September 30, 2015 at 8:03 am
Thanks for trying, but still have the issue. I updated to 4.8.13.p 30 minutes ago on our production server and have received 5 more of these failed transactions with no associated event since. This is with BBQ plugin active.
|
|
Michael Nelson
|
September 30, 2015 at 2:39 pm
hi @wmnf, our transaction cleanup code runs every hour, however it conservatively only deletes transactions which appear to be from bots or users who abandoned early after they’ve sat in the database for a week.
Are any of the transactions you find in your database which have no associated registrations MORE than a week old?
|
|
wmnf
|
October 1, 2015 at 8:39 am
Thanks, yes, that looks to be true, the oldest of these types of transactions are a week ago. I’ve tried BBQ, do you have any suggestions as to how we can stop the bots? We’d really like to get sequential numbering of the orders working. Can there be a way to require a registration to be associated with an event? All of these transactions have no event associated with them.
|
|
Michael Nelson
|
October 1, 2015 at 12:37 pm
Thanks, yes, that looks to be true, the oldest of these types of transactions are a week ago.
Good so the spam bot cleanup process is working, but yes it looks like you will continue to have a week’s worth of spam transactions in your system, until we manage to fix that too.
We recently added a bot trap which should be preventing spam registrations altogether, but obviously somehow it’s not doing the trick for you. Are you using the Multi-Event Registration addon? That might affect the efficacy of bot trap.
|
|
wmnf
|
October 1, 2015 at 2:08 pm
No, but we plan to add that add-on soon. It was added to our new year budget which started today. Guess we can call this ticket resolved hoping for a fix for the bots in a later version.
|
