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.

Errors after moving domain

  1. I have just recently developed a Wordpress site with multiple forms using Gravity Forms. It was developed on a demo domain, and everything worked beautifully there. When I launched it, it was simply moved to a new domain on the same server, so the database did not move. I did change the url in the database, as I would do moving any Wordpress site.
    Everything seemed ok until we tested submitting the forms. We have a general contact form in our footer. When you submit it, the footer disappears and the homepage banner breaks (because the javascript is in the footer). When you submit our newsletter sign up form from the side bar, the rest of the page content doesn't appear after the form. When submitting our quote inquiry form on our contact page or our file upload form, it shows an "internal server error" and, oddly, doesn't break the rest of the content.
    Strangely, the forms actually submits the data, but to the user, it doesn't look successful....or make us look good.
    I've tried deactivating and reactivating the plugin. I queried the database for the old url but found nothing that would affect the submission of forms. I tried re-saving the url info from the general settings page for the site. I've tried saving the forms again from within the admin with the hopes that it would flush the cache or replace any bad data. I tried creating a new form and placing it on a new test page, and it still broke, even though it was created in the new environment. Not sure what else to do. I'd rather not have to reinstall and recreate all of these forms...any suggestions?

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  2. Also, I'm on Wordpress 3.2.1
    And this is happening in all browsers.

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  3. gwc_wd
    Member

    This may be a dumb question, but you didn't say directly -- when you moved your forms, did you Export the forms from the Gravity admin and then reimport them to the newly moved site?

    I've done this a number of times successfully move from a dev site to a production site. Being on the same server doesn't necessarily mean everything will react the same so the export-import process was necessary but really quite painless.

    My breakages occurred when I had urls embedded in the forms themselves - they continued to work but just were not pointing where I needed them to <smile>.

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  4. That's interesting (did not do this), but would that work at this point? Would I export and re-import from the current (live) site? The dev site files are still on the server, but the url in the database has changed so the dev site isn't functioning anymore.

    I don't know where the url would be embedded in the form. Our footer form just has a name, email, and message field...very simple. I can't find anything in which the url would be set. And I don't understand why when I create a absolutely new form and put it on a new page on the live site, it still doesn't work.

    ...

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  5. Sounds like the change in domain name messed up the serialized values. (Do the two domain names differ in length?) Give this plugin a shot: Meta Recovery Tool (at the bottom of this page)

    http://www.gravityhelp.com/downloads/

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  6. gwc_wd
    Member

    Regarding:

    The dev site files are still on the server, but the url in the database has changed so the dev site isn't functioning anymore.

    A general tip: I find it very helpful to maintain a completely separate installation of wordpress under a subdomain of my main site: dev.example.com. I actually have three dev. sites testing different things like how a plugin is going to work before putting it on my main site.

    This ensures that if you need to re-export or recover any piece of a site you've got working the way you want on the dev.site you can always just go ahead and get it.

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  7. @ Chris Hajer ... I installed the meta recovery tool and used the meta recovery utility for each of my forms ("Meta recovered successfully."). Still no luck. The two domain names were different in length. Live site: http://www.envision-creative.com

    @ gwc_wd ... thanks for the tip. I do usually keep a side site, though not necessarily in a subdomain. In this case, since it was moving from a different domain within the same server space, I just used the same database (I assume you are maintaining different databases for your dev sites), so restoring the old site has a bit more complexity. Should I do so, and try the export/import process? It seems like the process of re-setting up the dev site might result in the same issues as the move to the live site. I do have a backup of the dev site database before the move was made. I tried exporting the forms from the current live site, and without deleting the current forms, imported the new ones. I was hoping they would be overwritten, but were not. If I were to remove the old forms and import the xml file, would the forms keep the original ID or will that data change, so that I will need to change the page template functions for the forms?

    Please help. :-/ Thanks again.

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  8. I don't think this has anything to do with the meta at this point. Your page did not completely load after I submitted the contact form in the footer. If you look at the source, it stopped after this:

    [html]
    <li id="recentposts">
        <h3>Recent Blog Posts</h3>
            <ul>
                <li>
                <a href="http://www.envision-creative.com/social-media-marketing-the-best-outlets-for-business-and-why-you-should-be-involved">Social Media Marketing: The best outlets for business and why you should be involved.</a>
                </li>
                <li>
                <a href="http://www.envision-creative.com/how-to-create-a-successful-campaign">How to Create a Successful Campaign</a>
                </li>
            </ul>
        <a href="http://www.envisiondemo.com/envision/blog#banner_div_bot" id="subscribe">subscribe to our Blog</a>
    </li><!--recentposts-->

    It's possible a template part or something is erroring out. Do you have access to error logs so you can check for errors? Maybe a file is missing or function is missing on this server?

    Also, you can check to see what is the last part of this page being processed, and sort of assume that whatever was supposed to come next is creating the trouble.

    It could also be a plain old plugin or theme conflict. I noticed you are enqueuing jQuery from googleapis.com. I'm not sure if that's going to be a problem with a simple form like this on your home page.

    I think if you have access to error logs, or if you can tell what should come after <!--recentposts--> we'll have a better shot at pinpointing the problem. With the errors on all these different pages with different forms (including the 500 Internal Server Error) something should be logged somewhere.

    Posted 13 years ago on Friday September 2, 2011 | Permalink
  9. So the error logs mention this:
    "...EACCELERATOR: PHP crashed on opline 3 of main() at ... /plugins/gravityformscampaignmonitor/api/class/serialisation.php:3..."

    I'm guessing the campaign monitor add on also has meta serialization issues?

    I deactivated it, and my forms started working again.

    What can I do to fix this add on? I've tried deactivating and reactivating. I tried deleting files and re-uploading for fun. Next would be eradicating the database data. Is there a better way?

    Thanks.
    -Steph

    Posted 13 years ago on Saturday September 3, 2011 | Permalink
  10. Don't do anything to the database and don't reupload/reinstall, anything like that. I have not seen an EACCELERATOR problem in a really long time. There was a fix to disable it for your WordPress site but adding a couple lines to your .htaccess

    php_flag eaccelerator.enable 0
    php_flag eaccelerator.optimizer 0

    Here is an old description of a very similar problem:
    http://mu.wordpress.org/forums/topic/1407

    If you don't want to turn off eaccelerator for your site, you're going to have to get with the host and see what's going on. Could be a problem with the versions of PHP/Apache/eaccelerator or something.

    Or, you could be the first to report a problem with the Campaign Monitor Add-on and eaccelerator.

    Do you have access to phpinfo() for your site?

    Posted 13 years ago on Saturday September 3, 2011 | Permalink
  11. So I tried adding the suggested lines of code to the .htaccess file and it returned a 500 Internal Server Error on the site.

    I am running PHP 5.2.17 and MySQL 5.0.77, which are supposed to be compatible with the plugins.

    What should I ask my host? I am not familiar with eaccelerator.

    Thanks.

    Posted 13 years ago on Tuesday September 6, 2011 | Permalink
  12. I contacted the host about the issue. The support guy tried disabling eaccelerator and the forms still produced this error:
    PHP Fatal error: Cannot redeclare class Services_JSON in ....wp-content/plugins/gravityformscampaignmonitor/api/class/services_json.php on line 115, referer: http://www.envision-creative.com/contact-us/

    Ideas?

    Posted 13 years ago on Thursday September 8, 2011 | Permalink
  13. This issue has been resolved with the release of the Campaign Monitor Add-on version 1.8.1

    :-)

    Posted 13 years ago on Thursday September 8, 2011 | Permalink
  14. Great, I'm happy that resolved the issue for you.

    Posted 13 years ago on Friday September 9, 2011 | Permalink

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