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.

Forms not saving

  1. m2mannix
    Member

    We have an install of GV where the client has created a rather large form, about 400 fields with roughly 95% of them drop downs. Each drop down has 10 - 15 options, and they is also conditional logic with most of the fields that allow other fields to display based on sections.

    We are seeing issues now when the client is adding new additional fields. Looking at the network view in Chrome Dev Tools we are seeing that the /wp-admin/admin-ajax.php if returning EndUpdateForm(1); so this appears to be working.

    Additionally, we have seen it return a simply -1 of which we assume is an error.

    You can see the JSON that is being created here, http://www.adirondackdreamhomes.net/json.txt

    Is there a finite about of data that can be passed? Are we attempting to do something that is just to complicated for the GV system? Any help or direction would be appreciated.

    Thanks!

    Posted 13 years ago on Thursday July 7, 2011 | Permalink
  2. Yes you are limited, but not by Gravity Forms. You are going to be limited by the available PHP memory on your web server. If the amount of data being passed in the AJAX request is too great, the AJAX request will fail.

    I would suggest testing the form with the ajax option turned off by either removing the ajax=true from the shortcode, or setting it to false.

    Posted 13 years ago on Thursday July 7, 2011 | Permalink
  3. m2mannix
    Member

    This was actually meant to refer to saving in the admin area when creating and editing the form, sorry!

    The memory available to the site is 128MB and we are only seeing about 30MB being used, so I'm not thinking that is the issue.

    Ideas?

    Posted 13 years ago on Friday July 8, 2011 | Permalink
  4. My answer above is the same, with one additional caveat which i'll add below. While only 30MB is being used, it could be spiking when the AJAX request happens and could exceed your available memory.

    There are 2 issues which typically cause a form not to be able to be saved in the form editor...

    - Running out of available PHP memory so the AJAX request is unable to complete. On a very large form, and 400 fields is a very large form, this is the most likely culprit.

    - MOD_SECURITY Firewall settings blocking the AJAX request.

    Typically if it's the MOD_SECURITY firewall issue you can test for this by creating a New form, adding a Single Input field to that form and saving. It should save fine. Not edit the same form, add a Checkbox, Radio Button and Drop Down field to the form. If it's a MOD_SECURITY issue the form probably won't save at this point, because of markup in those fields it's going to reject the AJAX request.

    If it's a MOD_SECURITY firewall settings issue this can be resolved by changing/updating the settings. You may need to contact your host for assistance with this. If it's a PHP memory issue then you'd have to increase your available PHP memory. 400 fields on a single form is fairly extreme so I could definitely see it being a PHP memory issue.

    Those are the only 2 issues we encounter that cause a form not to save in the form editor.

    Posted 13 years ago on Friday July 8, 2011 | Permalink
  5. m2mannix
    Member

    Just a followup as we've solved the issue. It was ultimately traced back to the max_allowed_packet setting in MySQL being too low to accept the large query that was being generated.

    We ended up turning on WP_DEBUG and WP_DEBUG_LOG on the wp-config.php file, which not only told us that the MySQL server was going away, but also logged the MySQL query that was failing. Running the query directly against the DB gave us a "packet too large" error. Adding "max_allowed_packet=32M" to our my.cnf allowed the query to complete.

    Again, just to outline the exact issue we were having.

    Attempting to create a (very, very large) form. Saving the form would initially work, but after adding additional elements, at some point saving the form would no longer work.
    Clicking the "Update Form" button to save would bring up the spinner and nothing else would happen. It would just sit and spin.
    We tracked down that admin-ajax.php was throwing an error code back (-1) and we started tracing from there. Perhaps the form can display an error to the user when admin-ajax.php returns an error?

    Posted 13 years ago on Friday July 8, 2011 | Permalink
  6. Nicholas
    Member

    My form edits are not saving either. I'll try turning off AJAX and see if it fixes it.

    Is there a way you can fix the plugin to notify when form edits are not saving? Unfortunately, I went several hours working on my form (nowhere near 400 fields, though) with no clue it wasn't saving.

    Posted 13 years ago on Saturday July 30, 2011 | Permalink
  7. @Nicholas Typically forms not saving are due to a lack of PHP memory. Although sometimes stranger causes such as the user directly above can popup. Every server is different. The first thing I would do is increase your available PHP memory. Here is information on how to do that:

    http://www.nerdgrind.com/increase-wordpress-and-php-memory-limit/

    How you can tell your form isn't saving when editing them is if you don't see the confirmation message when you save the form... then it didn't save. A yellow confirmation will appear when the form has saved.

    Posted 13 years ago on Monday August 1, 2011 | Permalink
  8. Nicholas
    Member

    Thanks Carl. I contacted support about this with some more details, and we concluded that I probably accidentally saved a prior version over top on a different tab in the browser (I was always getting the yellow confirmation message). Although I don't remember re-saving old data, I DO remember closing the tab I was working on and then deciding to re-open it in firefox by going to History>>Recently Closed Tabs. From what I remember it was immediately the old version of the form when I re-opened it, but I'm going off hazy memory here.
    Perhaps it opened an older version? Perhaps it immediately "sent" the old data again when I opened it?

    I installed the plugin recommended on the link you posted. I will monitor memory usage using the plugin and if memory usage is high I'll set the limit higher.

    Posted 13 years ago on Monday August 1, 2011 | Permalink
  9. laba05
    Member

    m2mannix solution is dead on. PHP memory was not our issue but max packets was.
    You should most definitely work in a solution and warning message for this in gravityforms.

    Posted 12 years ago on Monday February 13, 2012 | Permalink
  10. As laba05 says, I could fix this problem by changing the max_allowed_packet of mysql.

    If we got the message "Got a packet bigger than ‘max_allowed_packet’ bytes" on debug mode, max_allowed_packet size will be required to be increased as follows.

    /etc/my.cnf
    set-variable = max_allowed_packet=8M

    Posted 12 years ago on Monday March 19, 2012 | Permalink