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.

Broken Form -- Not related to Theme/Plugin Conflict.

  1. I'm having an issue with Gravity Forms working, I've exported these settings to a different domain and it works fine.

    Here is the link to the form:

    In Preview mode when I submit the form it 404's to this URL:

    When I do it on the page, it simply redirects back to the form and does not send an email nor record an entry. I've tried it both with and without AJAX.

    I've also tried to disable all plugins on our site, same exact problems.

    Everything is up to the newest version as far as gravity requirements are concerned.

    I have disabled pretty permalinks -- same issue
    I reenabled them -- same issue.
    I disabled my theme and enabled twentyeleven -- same issue.

    Nothing seems to fix this, and the configuration has been shown to work on other domains…

    Without out this it's putting a halt on our business.



    Posted 10 years ago on Wednesday September 14, 2011 | Permalink
  2. This page on your site returns a 404:

    That is unrelated to Gravity Forms but it is related to your problem.

    Posted 10 years ago on Wednesday September 14, 2011 | Permalink
  3. Nah -- It shouldn't.

    The .htacess and index.php are both moved to the root of public_html, this is something built into the wordpress codex and we've had gravity function fine on other sites we set up this way.

    It's most useful when having an old site up while you are working on another one, then you just move the .htaccess and index and edit a few lines and it works fine, are you sure that's an issue?


    Posted 10 years ago on Wednesday September 14, 2011 | Permalink
  4. This is a URL rewriting problem most likely related to .htaccess but possibly a web server related configuration issue.

    If this page:

    Returns a 404 error then something on your web server isn't functioning properly because if you browse the server file system you will see that the file exists. Your server is acting like it does not. So this is a server related issue involving URL rewriting and permalink handling.

    Posted 10 years ago on Wednesday September 14, 2011 | Permalink
  5. That's odd -- We host tons of Wordpress sites on our dedicated and they don't share this issue with gravity forms, but I will go ahead and submit a ticket with my provider.


    Posted 10 years ago on Wednesday September 14, 2011 | Permalink
  6. I have run into this exact issue. Viewing the preview of any form in our site displays a 404.

    This is happening because of the way gravity forms bootstraps wordpress in preview.php.

    require_once (preg_replace("/wp-content.*/","wp-blog-header.php",__FILE__));

    Loading wp-blog-header.php causes wordpress to instantiate the WP object, which on initialization parses the request and returns a 404 HTTP Status since the preview.php uri does not match any permalink, page or post known to wordpress. You can observe this by attaching a filter to 'status_header' and printing out what wordpress returns:

    add_filter('status_header', 'print_header');
    function print_header($status_header) {
        echo $status_header;
        return $status_header;

    Prints: 'HTTP/1.1 404 Not Found' for any gravity form preview.

    We are running nginx as our web server, and it is configured to handle 404 errors. So, as soon as it gets a 404 response from php/wordpress, it ignores anything else and returns its built in 404 page. The original submitter may have Apache configured similarly.

    A simple solution for this is to bootstrap wordpress differently in preview.php.

    require_once (preg_replace("/wp-content.*/","wp-load.php",__FILE__));

    This bypasses initiating the WP object and fully loads wordpress. WE have implemented this solution and haven't experienced any issues.

    A second solution would be to set the response header in preview.php to '200' before sending any content, thus overriding the header that wordpress had set.

    status_header('200'); //wordpress specific

    Hope this helps others.


    Posted 10 years ago on Wednesday November 2, 2011 | Permalink
  7. Hi Guys,

    You should see v1.6.1 available by automatic upgrade. This version should resolve this issue. Let me know if anyone is still having trouble. :)

    Posted 10 years ago on Tuesday November 8, 2011 | Permalink