Form not displaying after update to v1.6.4.1.1

Gravity Support Forums » Plugin Support » Gravity Forms

oustcat
Member

I have one form (of 10) that does not display after the most recent update, which uses datepicker, signature, page breaks and conditional logic.

Things to note:
1. The theme loads the latest jQuery from code.jquery.com
2. Deregistering all other scripts does not resolve the problem (nor does deactivating the respective plugins - Orbit Slider, Simple Lightbox, Ubermenu, SuperSignature)
3. Deactivating plugins that adds JS to the page produces the following error: Uncaught TypeError: Object [object Object] has no method 'datepicker'
4. Inline CSS (display: none;) is added to div#gform_wrapper.
5. The form does not display in the formbuilder Preview.

The form is located here:
http://dev.habitatforhorses.org/adoption/

Any help would be appreciated. Thank you.

Posted 12 years ago on Wednesday May 2, 2012 | Permalink
David Peralty

Hi, can you send me an admin account login so I can take a look? My e-mail is peralty@rocketgenius.com and please make sure to reference this post in your e-mail.

Posted 12 years ago on Wednesday May 2, 2012 | Permalink
oustcat
Member

Done and with a follow-up email from oustcat.com.

Posted 12 years ago on Wednesday May 2, 2012 | Permalink
David Peralty

oustcat - So after looking through your form, I've sent it up to the developers to take a look at. It looks like your issue might be due to just how complex your form is and as soon as I know more, I'll respond here to help both you and anyone else with the exact same issue.

Posted 12 years ago on Wednesday May 2, 2012 | Permalink
oustcat
Member

Thank you.

Posted 12 years ago on Wednesday May 2, 2012 | Permalink
oustcat
Member

Hmm...having a problem submitting post. Blocked by FireHost.

Posted 12 years ago on Thursday May 3, 2012 | Permalink
oustcat
Member

Hi, I removed the code altogether to which you refer in the email, however, the form still does not display. I'll keep the code disabled until the display issue is resolved. Thoughts?

Reference:

So the lead developer got back to me and said that the problem is that there is code being written to the page referencing jQuery before the jquery library is included in the page. That is causing a jQuery not defined error (http://grab.by/dphi), which causes the form to not show up.

By looking at the code, it seems to be a Gravity Forms customization. I am not sure how you are including this Javascript code to the page, but what I suggest is that you move this code to an HTML field in that form. That will ensure that it is printed after the jQuery is included in the page. Following is the custom code I am talking about.

[Re: http://www.pastie.org/3854064

Posted 12 years ago on Thursday May 3, 2012 | Permalink
Alex Cancado
Administrator

The root of the problem is that there are javascript errors on the page. When that happens, the browser stops executing the Javascript code and does not run the proper routine that displays the form. So what we need to do is fix all the javascript errors that are on that page. The next error is related to the signature field. The super_signature/ss.js file needs to be printed before the form, but it is getting printed in the footer. Normally, the scripts would be printed that way, but you have an unique setup and things are a little out of order. I tried to find where the scripts are being printed in your theme, but I couldn't.
Try moving that ss.js file up so that it is printed just under jquery.js and see if that error goes away.

Posted 12 years ago on Thursday May 3, 2012 | Permalink
oustcat
Member

Thanks, Alex. I'll look into it.

Posted 12 years ago on Thursday May 3, 2012 | Permalink
webdogs
Member

I'm having the same problem on my website: http://webdogs.com/contact

It seems the issue is with the conditional logic processing. I tested displaying a form without conditional logic, and had no problems. However, adding conditional logic breaks it.

Here's also the error I'm seeing in IE:

Message: Object doesn't support this property or method
Line: 199
Char: 9
Code: 0
URI: http://webdogs.com/wp-content/plugins/gravityforms/js/conditional_logic.js?ver=1.6.4.1.1

Please help! Thanks!

Posted 12 years ago on Thursday May 3, 2012 | Permalink
David Peralty

We would really like everyone to make their own forum threads because the same effects can be caused by different things.

webdogs - Your issue is that you need to use JQuery 1.7.1 and your theme is outputting 1.5.

Posted 12 years ago on Thursday May 3, 2012 | Permalink
webdogs
Member

Thanks David! That solved the issue. I will make sure to open a separate forum thread next time :)

Posted 12 years ago on Thursday May 3, 2012 | Permalink
David Peralty

Glad it worked out for you, and thanks again for taking that to heart. You wouldn't imagine how complex it gets to help people when every is talking in the same thread. :)

oustcat - let me know when you had a chance to sort out those JavaScript issues. I'm looking forward to helping you get your issue resolved.

Posted 12 years ago on Thursday May 3, 2012 | Permalink
oustcat
Member

Alex, I'm a little confused by your answer especially in regards to your reference of order. wp_footer() is included just before the closing </body> tag. Are you saying that the Gravity Forms Javascript needs to be included in the header and not before </body>?

Posted 12 years ago on Thursday May 3, 2012 | Permalink
oustcat
Member

Also, I disabled the Signature plugin, which did not resolve the issue. The javascript errors are now the following:

Uncaught TypeError: Object [object Object] has no method 'textareaCount'
Uncaught TypeError: Object [object Object] has no method 'orbit'

Posted 12 years ago on Thursday May 3, 2012 | Permalink
oustcat
Member

Alex, can you help clarify by answering my question?

Posted 12 years ago on Friday May 4, 2012 | Permalink
Alex Cancado
Administrator

Some of Gravity Forms scripts can't be added in the footer. jquery.js, ss.js and a few others have to be included in the header (or anywhere before the actual form). The reason is that some scripts are initialized inline with the form markup and those initialization scripts require their correspondent libraries (js files) to be included before they can execute.
What I would suggest is that you move your scripts to the header and see how that goes.
Note the "orbit" error above is not a Gravity Forms related error, but it is probably being caused by the same problem. I would move that script to the header as well.

Posted 12 years ago on Friday May 4, 2012 | Permalink
oustcat
Member

Thank you. I'll work on this and keep you posted.

Posted 12 years ago on Friday May 4, 2012 | Permalink
oustcat
Member

Hello,

I removed the max character inclusion from the form which removed textareaCounter.js, and the form displayed. Keep in mind the following:

1. The signature plugin has been disabled at this point.
2. Enabling the signature plugin (ss.js) causes conflicts from this point forward, and seems to be one underlying issue (after having removed textareaCounter.js).
3. The orbit Javascript is still included via wp_footer() - with no issues.
4. I have also re-enabled the placeholder Javascript (http://www.pastie.org/3854064) with no issues.

I had attempted to relocate ss.js from the footer to the header, however, wp_deregister_script is ineffective, even though it appears that the plugin Javascript was registered correctly via wp_enqueue_script. Actually, I had difficulties deregistering any of GF's Javascript.

Here is the function I used to deregister ss.js from the footer:

http://www.pastie.org/3874903

There were no issues with adding ss.js to wp_head(), which you can see in the source code now.

How may I go about moving ss.js to the header to determine if doing so will resolve any conflicts?

Posted 12 years ago on Monday May 7, 2012 | Permalink
oustcat
Member

I've upgraded to 1.6.4.2, and the conflict with ss.js continues. My question still stands. How may I go about moving ss.js to the header to determine if doing so will resolve any conflicts?

Posted 12 years ago on Tuesday May 8, 2012 | Permalink
Alex Cancado
Administrator

My recommendation is to use the shortcode in the post content instead of calling the do_shortcode() in the template file. Gravity Forms has a script enqueuing processor that reads shortcodes and includes the proper scripts in the right places. Using the do_shortcode() is preventing Gravity Forms from enqueuing the scripts that way.
The second option is to use the gravity_form_enqueue_scripts() function (http://www.gravityhelp.com/documentation/page/Gravity_form_enqueue_scripts).

Posted 12 years ago on Thursday May 10, 2012 | Permalink
oustcat
Member
The form *is* being included into a post using the shortcode.

I don't think this addresses my question, nor my issue which seems to be a conflict when the Signature plugin is enabled.

As described from an earlier entry:
I removed the max character inclusion from the form which removed textareaCounter.js, and the form displayed. Keep in mind the following:

The signature plugin has been disabled at this point.

Enabling the signature plugin (ss.js) causes conflicts from this point forward, and seems to be one underlying issue (after having removed textareaCounter.js).

The orbit Javascript is still included via wp_footer() - with no issues.

I have also re-enabled the placeholder Javascript (http://www.pastie.org/3854064) with no issues.
My scripts seem to be in the right places. If they are not, can you list how and where they should appear? This has been very confusing as it's been mentioned but not specified. I did notice today that gravityforms.js is inserted into the footer of this particular form, and not into the header as it is for my other forms. Is this the order to which you refer?

Also, if it is the Signature Javascript that needs to be in the header, be aware that I had attempted to relocate ss.js from the footer to the header. However, wp_deregister_script is ineffective, even though it appears that the plugin's Javascript was registered correctly via wp_enqueue_script. Actually, I had difficulties deregistering any of GF's Javascript, which also includes gravityforms.js.

Here is the function I used in an attempt to deregister ss.js from the footer:
http://www.pastie.org/3874903

The above was my next attempt at a resolution. So, how may I go about moving ss.js (and possibly gravityforms.js) to the header, given that wp_deregister_script is not working, to determine if doing so will resolve any conflicts?

Alex, if you need access to the site, I'd be happy to provide it. Thank you.
Posted 12 years ago on Friday May 11, 2012 | Permalink
Alex Cancado
Administrator

It would probably be easier if I can take a closer look and see how things are setup. Please email them to alex@rocketgenius.com. I will need an FTP and WP admin login.

Posted 12 years ago on Friday May 11, 2012 | Permalink
oustcat
Member

Done.

Posted 12 years ago on Friday May 11, 2012 | Permalink
Alex Cancado
Administrator

I just wanted to let you know that I am looking at your site. I have made a modification to the custom placeholder script that was throwing a javascript error and I was able to see the conflict with the signature field. I am working on getting it resolved and I will let you know when I do.

Posted 12 years ago on Tuesday May 15, 2012 | Permalink
oustcat
Member

Thank you, Alex.

Posted 12 years ago on Wednesday May 16, 2012 | Permalink
Alex Cancado
Administrator

I think I have it all worked out. Let me know if not.
To summarize what I did:
1- The custom placeholder script was being included too far up on the page (before jQuery). I have made the change on your site and I will be looking at updating our documentation to include some tricks to avoid this problem.
2- There was a problem with the Signature Add-On, which was causing some of the other javascript errors. I have updated the version on your site and have also updated my dev version so that the next release will have the fix as well.

Posted 12 years ago on Wednesday May 16, 2012 | Permalink
oustcat
Member

Thank you, Alex! I'll take a look.

Posted 12 years ago on Thursday May 17, 2012 | Permalink
oustcat
Member

Alex, it's working nicely. Thank you so much for your help. Feel free to close this topic.

Posted 12 years ago on Friday May 18, 2012 | Permalink
Rob Harrell
Member

Awesome, glad you are up and running. Thanks for letting us know!

Posted 12 years ago on Friday May 18, 2012 | Permalink

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