Having an issue with a multipage form with conditions. gf_apply_rules contains >
http://dreamwhisperdesigns.com/contact/
I give up on the backticks & gt;
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.
XHTML Validation gf_apply_rules
-
What exactly is the issue? You didn't provide much detail and I was able to browse your form and submit a test without a problem. Can you provide more details and explain what the issue is and how to reproduce it so we can see it first hand?
Posted 13 years ago on Friday December 2, 2011 | Permalink -
dreamwhisper
MemberYeah, sorry, I was having problems with the backticks and trimmed down significantly. The problems start here:
[js] <script type='text/javascript'>//<![CDATA[ if(window['jQuery']){jQuery(document).ready(function(){gf_apply_rules(1,That particular piece of code ends in
[js] //]]></script>so, the script isn't recognized as closed and the errors cascade after that. Note: my & gt; gets converted even with the backticks.
oddly, I saw found this, which seems this may be related (only in that a CDATA block is mentioned, though I can't see it): http://www.gravityhelp.com/forums/topic/xhtml-validation
Posted 13 years ago on Friday December 2, 2011 | Permalink -
Are you currently using CloudFlare (http://www.cloudflare.com) on that site?
Posted 13 years ago on Friday December 2, 2011 | Permalink -
We encountered this issue earlier today but it was caused by CloudFlare changing the markup when outputting the page content. It's the same issue you are having.
This issue isn't happening on our local tests and we are unable to reproduce it. It's simply not what Gravity Forms is configured to output.
Something on your site is manipulating the Gravity Forms code output. The issue is directly related to whatever is causing the > output instead of the > character which is what it should be.
The first thing I would have to suggest is test for theme and plugin conflicts to determine if something in your theme or another plugin is manipulating the output of the Gravity Forms code or shortcode. Here is instructions on how to do so:
http://www.gravityhelp.com/documentation/page/Testing_for_a_Theme/Plugin_Conflict
Let me know how it goes. We need to narrow it down so we know where the code output manipulation is coming from before we can determine how to fix it. The fix would occur in whatever is causing the problem, not Gravity Forms itself.
Posted 13 years ago on Friday December 2, 2011 | Permalink -
dreamwhisper
MemberOh, I'm such a typical bad forum poster. I had actually been through all that already. So, it appears to be Genesis conflicting with the latest version of GF. I imported the form to a dev site running GF 1.5.2.8 running Genesis 1.7.1 with a Child theme and no plugin with no errors. Upgraded to the latest version of GF - the errors appeared. Switched to Twenty Eleven, with no errors. The other thread is also a Genesis theme.
Posted 13 years ago on Saturday December 3, 2011 | Permalink -
That narrows it down then. Exactly what we needed to be able to get it resolved. We'll take a look and see what Genesis is doing.
It's extremely odd that this issue does not occur with Gravity Forms v1.5.2.8 but does with v1.6.2 I appreciate you sticking with things in trying to debug the issue, narrowing it down to Genesis v1.7.1 is very helpful.
I was able to replicate this issue with Genesis v1.7.1 and Gravity Forms v1.6.2 on my local test site. So this does indeed appear to be where the issue is.
Keep an eye on this post, we'll update it as soon as we determine the cause. I will try to narrow down the problem myself, but if i'm unable to find the specific issue i'll need to have our Lead Developer take a look. Because it's the weekend there ay not be a resolution on this until sometime on Monday.
Posted 13 years ago on Saturday December 3, 2011 | Permalink -
Yea, i've been trying to narrow it down myself but i've been unable to pinpoint the problem. I have forwarded it to our lead developer so he can take a look at it and pinpoint the cause.
Posted 13 years ago on Saturday December 3, 2011 | Permalink -
We've determined the issue is not Genesis. It's a WordPress core function that is making this change. There isn't anything we can do to prevent it from happening. It's applying this change to all content output by the_content() function.
You can actually see the line of code yourself by opening wp-includes/post-template.php and going to line 168.
Here is the line of code that is causing the validation problem:
$content = str_replace(']]>', '& g t ;>', $content);So the built in the_content() function is replacing all instances of ]]> with ]]> which doesn't make a whole lot of sense. There has to be a valid reason why this code is in place, although I couldn't tell you what it is.
The end result is code where this change exists, the code that is output won't validate.
So Gravity Forms code is correct, but it's being changed by WordPress core so it won't validate. Right now we don't have a solution because when you embed a form into page or post content and display it using the_content() function our code is run before this happens.
I've been trying to determine why this code is in core but no luck yet.
The only solution right now is either..
1) Ignore the validation errors, invalid code is not "broken". It will still work and function, it just means it hasn't passed validation. At a time when many sites are now mixing XHTML and HTML5 that isn't as big a deal.
2) Display the form using the function call rather than the shortcode. This issue only happens when the form is embeded in a page or post that is then output using the_content() function. If the form is displayed via the function call in a theme template file itself, this doesn't happen. If a form is displayed via a widget, this also won't happen. It's only when the_content() comes into play.
We'll continue to look into this but right now it looks like a core WordPress feature that is manipulating the output negatively.
Posted 13 years ago on Monday December 5, 2011 | Permalink
This topic has been resolved and has been closed to new replies.