PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Wrong auto-reply notification & not all submissions being recorded.

  1. I set up a form for an event-registration for a client. Here's a scenario outlining a problem we've been having (using "Dave" and "Larry")

    Dave came to the site and registered for the event. He received an auto-reply notification saying, "Thank you Larry". The form submission details were all listed in his notification, but they were different from what he submitted.

    At first this looked like simply a matter of Dave receiving the wrong notification. BUT, when I login to the admin area there is absolutely no record of anyone named Larry ever submitting the form.

    I've submitted the form myself and it seems to be working, so I haven't been able to reproduce the problem. So far 16 people have signed up for the event - two of them have written in to complain that they've received the wrong notification.

    HELP!

    UPDATE: Here's 2 more things that seem to be related...

    1. I've marked all entries as "read", but the dashboard widget still says there is one unread entry. Could this be Larry, and he's being hidden somehow?

    2. When I use the Search filed on the entry listing page to search for "Larry", Dave's entry is listed in the results. I've triple-checked and Dave's entry does NOT contain the word "larry" anywhere (addresses, etc...). It doesn't make any sense at all that his listing would be in this search result.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  2. Paul, you would have to provide us with a WordPress admin login for your site so we can try and reproduce the issue. Use our Contact Us form to do so.

    Nobody else has reported this issue which leads me to believe it is something specific to your web server as something like this would certainly be widely reported if others were experiencing it.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  3. OK Carl, I'll send the details using your contact form. Thanks.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  4. I don't know if this is related or not, but I've just had another case of a record disappearing - sort of. I received 2 different admin notification emails for the form. The contents of the form were identical, but they came from 2 different email addresses (Joe@abc and Darryl@abc). When I logged into the site there was only 1 entry.

    At first I though maybe Darryl submitted the form, hit his back button, and submitted it again, only changing the address and not changing the name. But, doing this myself I'm unable to reproduce the problem.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  5. I dug around in the database. In rg_lead_detail there are indeed 4 individual records for Larry, Dave, Joe, and Darryl. But, the admin page only shows a record for Dave and Darryl.

    Also, I exported the entries as a csv file, and it also does not show the missing entries. Somehow they're being hidden.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  6. After a little more digging I realized that both Dave and Larry have the same lead_id, and both Joe and Darryl have the same lead_id.

    I believe this is the cause of everything. Although it's possible, I don't see how this would be related to my specific WP install. This seems like an actual bug.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  7. Nobody else is reporting the issue and we have thousands of users across many more sites which points to it being something specific with your site or database setup. If it was a major bug we would have many users reporting it, but we only have one.

    It could be an issue with your MySQL setup, which would explain why record ids are not incrementing properly.

    We received your WordPress admin login and will look into it, however it may require FTP and Database access in order to fully determine what is going on.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  8. OK, any help you could give would be appreciated.

    Since 1.3.10 is relatively new, I'm wondering if this is an actual bug, and I'm just the first person to notice.

    I manually changed the lead_id and all the entries show on the admin page now. It also corrected the unread count issue.

    Also, just so you know... the 2 sets of entries that were assigned the same id were submitted at almost the same time. Maybe that's part of the problem?

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  9. Nothing was changed in 1.3.10 that would introduce a bug like this. so the code that handles this wasn't updated with that release so if there was a bug, it would have to have already existed prior to the 1.3.10 release.

    Do you know if they were assigned the same id at the exact same time or almost the same time? Can you look at the timestamp and post back what the timestamps were?

    Are you able to recreate the issue yourself by submitting forms at the same time, etc.?

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  10. Joe - March 8, 2010 at 5:56 pm
    Darryl - March 8, 2010 at 5:54 pm

    Larry - March 8, 2010 at 4:08 pm
    Dave - March 8, 2010 at 4:09 pm

    I've been unable to reproduce the issue. :(

    Admin notifications work, in that a unique email was generated for each entry - even though they weren't showing up in the admin page due to the conflicting lead_id.

    It was actually a fluke that we discovered this. My client was having email troubles and they weren't receiving the notifications (not related to Gravity Forms). It was because of this that I went into the admin area to check things out. If email notifications had been working we may have never noticed.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  11. Here is the issue that is troublesome, the lead id isn't generated by Gravity Forms. It is generated by your MySQL database. It auto increments when a new row is added to that table, so it isn't something we create.

    If two rows were given the same lead id it points to an issue with the MySQL database. Given that the entries were submitted at the exact same time (which shouldn't be an issue anyway), it appears your MySQL database did not auto-increment when it should have. This is built in MySQL functionality, we don't generate the id on our end.

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  12. hmmm.... that is troubling. Just so I make sure I'm understanding, and we're talking about the same thing, see this screenshot:

    http://paulburddesign.com/table.jpg

    - The "id" is working normally. Each one is getting a unique value. No problem here.

    - The "lead_id" should have the SAME value for each FIELD within a single entry, but a UNIQUE value for each entry. This is not generated by Gravity Forms. It's generated by MySQL and is malfunctioning.

    Is this correct? If so, do you have any recommendations?

    Posted 14 years ago on Tuesday March 9, 2010 | Permalink
  13. It happened again this afternoon. Two people who signed up within a minute of each other got assigned the same lead_id. But, the system did appear to keep track somehow of what it had done.

    Stephen 2:49pm - assigned lead_id 48
    Mike 2:50pm - Assigned lead_id 48
    Jennifer 2:53pm - Assigned lead_id 50

    As you can see, it skipped a number where it used the same id twice.

    Posted 14 years ago on Wednesday March 10, 2010 | Permalink
  14. I'm not sure, the id is generated by MySQL and not Gravity Forms and it doesn't appear to be generating correctly. One thing to keep in mind is when you change an id that is generated automatically like you did, it can throw off MySQL's id generation. It can lose track of what the current id is, etc.

    We haven't encountered this before, it appears to be a MySQL issue specific to your MySQL setup.

    Posted 14 years ago on Wednesday March 10, 2010 | Permalink
  15. I solved it! The problem was the W3 Total Cache plugin.

    I wasn't able to replicate the problem initially because I forgot that pages don't get cached for me (as a logged-in admin). As soon as I rapidly submitted forms while logged out, the same thing happened to me, where the records were being combined. Disabling the database caching option fixed the problem.

    I'm glad that's solved! :) Thanks!

    Posted 14 years ago on Wednesday March 10, 2010 | Permalink
  16. bakbek
    Member

    Hi,

    I reported something similar today using the 'contact us' form... I currently have in a form 3 unread entries that can't be seen in the list or in the exported file for that list... and yet the total amount of entries does account for those 3 missing unread entries...

    So... were these entries actually made and are now missing - which is bad, since i now have to find out who posted them.

    Or is it just ghost entries not actually made by anyone.. just a bug?

    22 sent a form so far, 3 are unread and missing and i have 140 more users that are going to post soon...

    Any help is highly appreciated at this stage

    [EDIT]

    As i use W3 Total Cache too... I disabled the Database caching to see if this solves the issue... Is this a confirmed conflict? if so it's best if Frederick Towens get's a report about this so this can be solved.

    Posted 14 years ago on Monday March 15, 2010 | Permalink
  17. This is a confirmed conflict. It isn't a conflict in the traditional sense, W3 Total Cache is doing what it's told to do... cache. The problem is the fact that cache is being returned causes problems with Gravity Forms which causes the data to get out of synch.

    We have already been in touch with Frederick via Joost de Valk and they will be updating W3 Total Cache so that Gravity Forms related tables are not included in the database cache functionality. I don't have a date on when this will be implemented, but they are aware of the issue and will be implementing a fix.

    What they need to do is implement a filter that plugin developers can use to tell W3 Total Cache NOT to cache certain data.

    Posted 14 years ago on Monday March 15, 2010 | Permalink
  18. bakbek
    Member

    Great news!!! What can i do with my form now with those 3 missing unread entries? are those real entries by users after all? can i access them by looking into the actual table using phpmyadmin or something like that? just to get the names and contact them to resubmit

    Posted 14 years ago on Monday March 15, 2010 | Permalink
  19. I'm not sure if those entries will be recoverable. The form data associated with them would have been stored using the incorrect lead id. So if you look at the data in the database you can find multiple entries with the same lead id and then decipher it from there.

    Posted 14 years ago on Tuesday March 16, 2010 | Permalink
  20. bakbek
    Member

    I actually can't see any gravity forms related tables in my database?!?! but it works... how is that possible?

    Posted 14 years ago on Tuesday March 16, 2010 | Permalink
  21. If you have Gravity Forms working, they have to be there.

    The tables are names as such:

    YOURDBPREFIX_rg_*

    For example wp_rg_lead, wp_rg_lead_detail, wp_rg_lead_notes, etc.

    Posted 14 years ago on Tuesday March 16, 2010 | Permalink
  22. What does the "rg" stand for? Did Gravity Forms have a different name at some point?

    Posted 14 years ago on Tuesday March 16, 2010 | Permalink
  23. duplicate post

    Posted 14 years ago on Tuesday March 16, 2010 | Permalink
  24. The rg stands for rocketgenius, which is our company name. http://www.rocketgenius.com

    Posted 14 years ago on Wednesday March 17, 2010 | Permalink
  25. Duh. :redfaced:

    Posted 14 years ago on Wednesday March 17, 2010 | Permalink

This topic has been resolved and has been closed to new replies.