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.

Debugging client submission problems

Gravity Support Forums » Plugin Support » Gravity Forms

  1. dnb
    Member

    Hi-
    I'm curious what you'd recommend for debugging issues with individual client form submission problems. I've got a form that has been happily collecting data and notifying us when it does so, but there is one person who recently sent the following in email:

    "I have sent in our form three times, did it come through?"

    and indeed, I haven't seen anything from this person. Unfortunately I don't have any access to the server error logs (oh GoDaddy, we love you so). Does or can GF write out any debugging information to a log that might help get to the bottom of this? Is there anything else you could recommend I could do or ask of this person to help get to the bottom of things?

    Thanks for any help you can offer.

    -- dNb

    P.S. If it is of any interest, the form in question is using the AJAX "Thanks for the form" setting, which as I mentioned, is working for everyone else. Is there a chance that if their browser can't handle things, submissions would also fail?

    Posted 13 years ago on Friday September 24, 2010 | Permalink

  2. Carl Hancock
    Administrator

    It's possible about highly unlikely it's a browser issue, although AJAX does use Javascript and if they had Javascript turned off than this could be an issue. We can look into how to detect JS and disable AJAX if it's JS can't be used.

    Another possibility is a caching issue. If the site is running any kind of database caching plugin for performance and it isn't configured to allow Gravity Forms to read/write to the database properly... this can cause a problem. W3 Total Cache, for instance, has database caching and unless you add the Gravity Forms database tables to it's database caching whitelist... you will encounter strange issues of entries not being recorded depending on when the cache was last cleared.

    Posted 13 years ago on Friday September 24, 2010 | Permalink

  3. dnb
    Member

    Hi Carl-

    Thanks, that's useful advice (especially re: W3 Cache, is that documented some place?) on what could be going wrong. Do you have any advice on how to begin to determine what is going on (i.e. how to debug)? Does GF write any logs (or can it) that I can look at?

    -- dNb

    Posted 13 years ago on Friday September 24, 2010 | Permalink

  4. dnb
    Member

    And sorry, just so I get the advice on W3 Cache, are you recommending I add something to the "Ignored query stems:" box or is the whitelist some place else?

    Actually, scratch the question, just saw your posting in:

    http://forum.gravityhelp.com/topic/not-getting-all-of-the-entries-when-exporting-form-as-a-csv-file#post-8919

    (but still interested in general advice on how to debug problems like this)

    -- dNb

    Posted 13 years ago on Friday September 24, 2010 | Permalink

  5. dnb
    Member

    Sorry, last followup to myself here. The user managed to submit the form finally (my current guess is he got tripped up on a field validation and didn't manage to read the error message).

    Still kind of curious about debugging support within GF, but I'm happy to call this case closed if you'd like.

    -- dNb

    Posted 13 years ago on Friday September 24, 2010 | Permalink

  6. Carl Hancock
    Administrator

    You are correct as far as the query stems issue with W3 Total Cache. Caching, especially database caching, can cause problems with any plugins that need to read and write to the database as caching can interfere with this.

    As far as debugging goes there isn't any single way that works best. Typically it's easiest to start with theme and plugin conflicts by deactivating other plugins and activating the default theme.

    You can certainly scour log files, but this is certainly time consuming and unless you know how to interpret the information it's probably going to take a lot more time vs. checking for plugin/theme conflicts. But some people prefer to go this route.

    Posted 13 years ago on Friday September 24, 2010 | Permalink

  7. dnb
    Member

    Ok, so that seems like a good thing to check. Would you expect theme/plugin conflicts to cause some intermittent failures, like in this case (which turned out to be pilot error), or an "always broken" sort of situation?

    Oh, and sorry, are there GF-specific debug logs I could scour if I was so inclined?

    -- dNb

    Posted 13 years ago on Sunday September 26, 2010 | Permalink

  8. Carl Hancock
    Administrator

    There are no GF specific debug logs. You'd have to look in your Apache log files for PHP errors.

    Theme/plugin conflicts can cause intermittent failures as well as "always broken" failures. It really depends on what the theme/plugin is doing. Database caching plugins for instance may work sometimes, but then you may experience issues when forms are submitted close together so the cache wasn't cleared before the next form submission. Theme/plugins also don't always do things on every page so it may only happen on pages where the theme/plugin is doing whatever is causing the problem. So it's possible for it to always be broken or for the functionality to appear intermittent.

    Posted 13 years ago on Monday September 27, 2010 | Permalink