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

  1. Hi guys
    Hoping you can help a girl out with a dumb question. I have read your responses to similar questions, however, I don't understand what I am doing with PHP so not really sure what the answer was.
    I have 2 forms running on my contact us page one of which is within a widget area and I assume its this one thats causing the 15 WC3 validation errors after reading other threads (www.basecamp101.com/contact).
    Can you please take a look, and explain in laymans terms what I have done wrong and what I need to do. I get the bit about disabling script outputs on the form. Just not the next bit about enqueuing scripts.
    BTW, I am on Genesis latest version and Gravity Forms latest version.
    Cheers!

    Posted 7 years ago on Wednesday November 30, 2011 | Permalink
  2. Can you try removing the reCAPTCHA and see if the errors go away? Looks like something is missing from the CDATA block:

    [js]
    //<![CDATA[
     var RecaptchaOptions = {theme : 'clean', lang : 'en'}; if(parseInt('5') > 0) {RecaptchaOptions.tabindex = 5;}
    //]]

    Should have two opening braces as well, like this:

    [js]
    [[//<![CDATA[
     var RecaptchaOptions = {theme : 'clean', lang : 'en'}; if(parseInt('5') > 0) {RecaptchaOptions.tabindex = 5;}
    //]]
    Posted 7 years ago on Thursday December 1, 2011 | Permalink
  3. Cheers mate. Thanks without the reCAPTCHA I validate. If I want to include the reCAPTCHA, what should I do ( in laymans terms).

    Posted 7 years ago on Thursday December 1, 2011 | Permalink
  4. We'll take a look and see if this is something we can change in Gravity Forms, or if this is coming from reCAPTCHA itself. If it's coming from reCAPTCHA itself, it's a 3rd party service and there is nothing we'll be able to do about it.

    If you want to use captcha then you could use Really Simple Captcha, which is another WordPress plugin. Install and activate the Really Simple Captcha plugin and it will add additional options to the Captcha field in Gravity Forms.

    Posted 7 years ago on Thursday December 1, 2011 | Permalink
  5. My forms validate OK with the reCaptcha field in them. Can you add the reCaptcha field to your form so that I can take a look and see where the problem is?

    Posted 7 years ago on Thursday December 1, 2011 | Permalink
  6. Hi Alex
    I have put the reCaptcha field back into the form http://www.basecamp101.com/contact
    Thanks.

    Posted 7 years ago on Friday December 2, 2011 | Permalink
  7. Are you currently using CloudFlare (http://www.cloudflare.com) on that site?

    Posted 7 years ago on Friday December 2, 2011 | Permalink
  8. Hi Carl. No, not using Cloudflare.
    Does it look like a plugin conflict?

    Posted 7 years ago on Saturday December 3, 2011 | Permalink
  9. The problem is something is manipulating the Gravity Forms code output and changing it before it's rendered on the screen. This is what is breaking things.

    I asked about Cloudflare because we had another user earlier today who had similar symptoms and it was due to Cloudflare's CDN and a beta feature that was manipulating javascript output as part of their CDN solution.

    So you are experiencing the same issue, but since you aren't using Cloudflare then there is something else on your site that is causing the issue.

    It could be a plugin conflict, or it could be your theme. The first thing to do is run a complete plugin and theme conflict test by following these instructions:

    http://www.gravityhelp.com/documentation/page/Testing_for_a_Theme/Plugin_Conflict

    Let me know how it goes and if you are able to narrow down what is causing the problem. All we would need to know is where the code is coming from, such as which plugin or your theme. We can then do some debugging on it and determine what it is doing wrong.

    Posted 7 years ago on Saturday December 3, 2011 | Permalink
  10. Related discussion here:
    http://www.gravityhelp.com/forums/topic/xhtml-validation-gf_apply_rules

    Posted 7 years ago on Sunday December 4, 2011 | Permalink
  11. 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 7 years ago on Monday December 5, 2011 | Permalink