Cannot edit any forms - stalls at Saving form. Please wait...

Gravity Support Forums » Plugin Support » Gravity Forms

Nick
Member

I am trying to edit 4 forms that I already created. When I make my changes and click Update Form the Ajax wheel spins forever and it will only display "Saving form. Please wait..."

When I close the browser window on this spinning wheel, I get a popup that states:

Ajax error while setting post template

I have deactivated all my plugins, and set my theme back to default... we are using Thesis 1.8 normally. I still have this problem even with the default theme, and no plugins.

Any ideas?

Thank you so much,
Nick

Posted 14 years ago on Saturday September 4, 2010 | Permalink
Carl Hancock
Administrator

If you are positive it isn't a plugin or theme conflict by deactivating all plugins and activating the default theme, the only way for us to look into this is for you to send us a WordPress admin login for this site via our Contact Us form.

Posted 14 years ago on Saturday September 4, 2010 | Permalink
Nick
Member

Ok thanks. I'll do that.

Posted 14 years ago on Saturday September 4, 2010 | Permalink
loulynch
Member

I am having the same problem. Tried deactivating all plugins as well as different themes. Still stalls at save.

Posted 14 years ago on Tuesday September 7, 2010 | Permalink
Studionine
Member

I am having the same problem also! I followed the advice available in the forum but it still will not save. So I cannot edit a form once I have made it. I have deinstalled all plugins and change to the default theme. Still just hangs there.

Posted 14 years ago on Tuesday September 7, 2010 | Permalink
Carl Hancock
Administrator

Another reason why a form will not save is due to Firewall settings on certain web hosts. If they are using ModSecurity and have set the firewall settings too strict this can cause the AJAX not to function properly because the firewall rejects the request.

If you want to see if this is the case for your situation, create a new form WITHOUT a drop down/radio button/checkbox field. Use just a couple simple fields such as Name, Email and Address and then save. Then edit that form again, add another text field and then Save again.

If it works... now edit the same form and add a radio button field with Yes/No values or a drop down. If it then quits saving, it's because of a server firewall setting is rejecting the AJAX call because we check for values of these fields using an isSelected keyword that ModSecurity may be rejecting because it thinks something malicious is going on despite the fact there is not.

Try the above. If this looks like what is causing your issue you may need to contact your web host about your firewall security settings.

Posted 14 years ago on Tuesday September 7, 2010 | Permalink
Studionine
Member

I doubt my webhost is going to change the Firewall settings just for one single site!

There's no problem CREATING forms with all these elements (drop down/radio button/checkbox field) so I don't understand why there should be a problem when editing.

Doesn't the plugin make AJAX calls when creating the elements in the first place?

Posted 14 years ago on Tuesday September 7, 2010 | Permalink
Carl Hancock
Administrator

@studionine We just had another user who hosts with LiquidWeb and they contacted their host and the host had it resolved within a couple minutes. So yes, a good host will make adjustments for your site.

Creating a New Form does not use AJAX. Saving an existing form after making changes does use AJAX so that it keeps you on the edit screen so you can continue or choose to go elsewhere.

I'm waiting on the user who's host just made a change for them to get back with me with details on what the host changed to make it work.

Posted 14 years ago on Tuesday September 7, 2010 | Permalink
Carl Hancock
Administrator

Here is how LiquidWeb researched and changed settings for the user experiencing the ModSecurity related firewall issue that prevented forms from saving:

I searched the apache error logs located at:
/usr/local/apache/logs/error_log for any modsec issues and found these

[Tue Sep 07 14:06:31 2010] [error] [client 74.95.42.29] ModSecurity: Access
denied with code 500 (phase 2). Pattern match
"(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\(.*from)"
at ARGS:form. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "355"]
[id "300016"] [rev "2"] [msg "Generic SQL injection protection"] [severity
"CRITICAL"] [hostname "www.offmarketassets.com"] [uri
"/main/wp-admin/admin-ajax.php"] [unique_id "TIapVkWnpGEAACYPiV0AAAAC"]

I added the following to the whitelist for modsec which is located at
/usr/local/apache/conf/modsec2/whitelist.conf

This whitelist covers the most common WP errors with modsec. Your site was only tripping rule 300016, which is a mysql injection protection.

<LocationMatch "/main/wp-admin/*">
SecRuleRemoveById 300015 300016 300017
</LocationMatch>

Please note the paths, etc. in the above information will be different from host to host. But what it outlines is what modsec changes were necessary to stop it from blocking the AJAX call.

If you encounter the same issue, this information should help your host change the modsec rules for your site.

Posted 14 years ago on Tuesday September 7, 2010 | Permalink
loulynch
Member

OK, I had my web host turn off mod_security completely. Form is still hanging up.

http://blog.hudsonvalleysportsman.com/hvs-ad-submission-form/

What should I try next?

Thanks for your help

- Lou

Posted 14 years ago on Thursday September 9, 2010 | Permalink
Carl Hancock
Administrator

@loulynch Hard to tell, the only thing issues we've ever encountered that cause the form save not to work are 1) Theme conflict 2) Plugin conflict and 3) mod_security settings.

If you are 100% sure it's not 1, 2, or 3 then what you are going to need to do is try re-installing the plugin from scratch to make sure all the files are there, double check file permissions (try CHMOD 777 on the plugin folder and all sub-folders and files to test) and if it doesn't save you will need to log the date/time and check your Apache log files for any errors. If you aren't familiar with how to access Apache log files you may need to get your hosts help on this part.

Posted 14 years ago on Thursday September 9, 2010 | Permalink
tdiaz1
Member

I'm having this problem now, and nuking the plugin, reinstalling the release instead of the beta works properly.

..and I see that another beta was posted today, I tried that one too. Same thing. 1.4.5 works, 1.5b3 does not.

The error log has no entries in it. The only thing that happens is in the access log:

[22/Nov/2010:15:46:45 -0800] "GET /wp-admin/admin.php?page=gf_new_form HTTP/1.1" 200 45624 "http://evilair.com/wp-admin/admin.php?page=gf_edit_forms" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7"

Posted 14 years ago on Monday November 22, 2010 | Permalink
Zack Katz
Member

Check your dubug console, such as Firebug. There may be helpful information regarding the ajax that takes place when saving.

Posted 14 years ago on Tuesday November 23, 2010 | Permalink
tdiaz1
Member
Well.. d'oh, sorta. Never thought to check the "dubug" ;-) console .. even though there was mention of Firebug earlier, being of the usual opinion that "it works with the release, the issue must be a beta", however:

TypeError: Result of expression 'form.title.trim' [undefined] is not a function. admin.php:2318
```
function ValidateForm(){
    var error = "";
2318:    if(form.title.trim().length == 0){
TypeError: Result of expression 'form.title.trim' [undefined] is not a function.
        error = "Please enter a Title for this form. When adding the form to a page or post, you will have the option to hide the title.";
    }
    else{
        var last_page_break = -1;
        for(var i=0; i<form["fields"].length; i++){
            var field = form["fields"][i];
            switch(field["type"]){
                case "page" :
                    if(i == last_page_break + 1 || i == form["fields"].length-1)
```
1.4.5 works, 1.5b(x) does not, so far. Across three different sites, I had b1, and b2, and tried b3 on a third. No dice. Put 1.4.5 back everywhere and it works. All the sites are on the same host, so thats not surprising. At least it's consistent. Quite a variety of plugins/themes from none to lots. No difference.
Posted 14 years ago on Tuesday November 23, 2010 | Permalink
urmedia
Member

It might be a really dumb observation, but...does your form have a name?

if(form.title.trim().length == 0)

that just checks if there are any characters in the form title. Straight forward. Here are the things, in order, I would check for:

1) string variable to be used with trim()
2) does the form have a name

If that is where the error truly is, then my assumption would be lazy coding. PHP function trim() requires a variable string. ie:

trim($string)

if it recieves no string the function doesn't work as expected and an exception will be thrown.

A good way to test would be to find the code area (lines) this relates to and set up a basic conditional using something like:

try {title_function($str){if(!$str == ''){do this}; }
catch ( Exception $e ) { err, do something else or report $e }

Posted 14 years ago on Tuesday November 23, 2010 | Permalink
Carl Hancock
Administrator

@urmedia This isn't a dumb question, it's probably the issue.

Gravity Forms v1.5 requires forms have a Form Title. For some reason a lot of people are creating forms without a Form Title, they purposely make it blank. This isn't good. The Form needs a name so that it can be presented in the admin, etc.

Rather than choosing not to display the Form Title when a form is displayed (which is a setting on the shortcode and function call to display a form), people are making it blank. This is unnecessary and causes problems in the admin.

I'm guessing this has something to do with the change in v1.5 that requires a Form Title. Previous versions allowed you to have a blank Form Title.

@tdiaz1 Does your form have a Form Title or is it blank?

Posted 14 years ago on Tuesday November 23, 2010 | Permalink
tdiaz1
Member

Well, just simply creating a new one from the side button, and then clicking Update Form is where it fails.

If "Untitled Form" is only added if a title does not exist, then why not just make it actually be the default title?

Although, my first encounter with this issue was loading the already "just saved" form from 1.4.5, and actually changing the title to "Contact Us".

Posted 14 years ago on Tuesday November 23, 2010 | Permalink
Carl Hancock
Administrator

Untitled Form is the default and clicking on New Form and then immediately Save Form should work. It should append a number to the end of Untitled Form if another form with that name exists.

This sounds like some sort of conflict.

If you send us a WordPress admin login for this site via our Contact Us form and reference this forum post we can take a look and see what is going on.

Posted 14 years ago on Tuesday November 23, 2010 | Permalink
urmedia
Member

Hey Carl,

Set up conditional, or 'try/catch' if you can recreate the error. If you can recreate it then it is likely others face similar issue.

To save you a headache in the future, add that try/catch to your next update where you can use the 'catch' to input a default form name if one doesn't exist for whatever reason (as well as write to the log file the error)

Posted 14 years ago on Tuesday November 23, 2010 | Permalink
cowiefox
Member

Hey guys, I had the same issue (Ajax broken) and it turned out to be a php memory limit. First I found my log files and there the error clearly showed as php running low on memory at 32M (we have a ton of plugins) and after I changed it to 64M and restarted the server it worked fine.

Posted 13 years ago on Tuesday January 25, 2011 | Permalink
genesis
Member

i've deleted the 1.5 beta version, uploaded the 1.4.5 (older version), i've also deactivated Akismet plugin, changed the php memory to 128, but we haven't restarted the server yet, so i'm not sure if that's what fixed it, but my form is now working. (after i got the Ajax error message whenever saving/editing the form.)

Posted 13 years ago on Friday January 28, 2011 | Permalink
erikajurney
Member

Wow, did the modsec whitelisting ( http://forum.gravityhelp.com/topic/cannot-edit-any-forms-stalls-at-saving-form-please-wait#post-9534 ) and it worked. I've been struggling with this for a long time ( http://forum.gravityhelp.com/topic/cannot-edit-any-forms-stalls-at-saving-form-please-wait#post-9534 ). Phew, thanks very much!

Posted 13 years ago on Monday January 31, 2011 | Permalink
Cronin
Member

Went down this path ourselves and bumping up the php memory from 32 to 64 solved the problem. Just a note for future people with this issue.

Posted 13 years ago on Monday May 16, 2011 | Permalink
vtisix
Member

After having spent too many hours on this issue, I want to list a possible solution here too. This applies if you're running a Multisite with WordPress SEO plugin from Yoast, particularly in private mode. After creating a site, you must make a change -- any change -- to the SEO settings page. I'm not sure how this is related to gform, but after having done this, I was able to get rid of the "Huge SEO Issue: You're blocking access to robots." error and, miraculously, gform works after that.

Hope this will help somebody in the future.

Posted 13 years ago on Monday August 15, 2011 | Permalink
ASMBS IT
Member

I am having the issues mentioned above. I cannot create a new form, add a form, edit an existing form...nothing. However, the issue is specific to my machine as others in the office can. All of the remedies I have been seeing are for server side yet I am lost as to why 2 others in my office same network have no issues yet I do. Any ideas? BTW the error is "Ajax error on saving form"

Posted 13 years ago on Thursday September 1, 2011 | Permalink