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.

[BUG] double qoutes in confirmation message and redirect cause migration to fail

Gravity Support Forums » Plugin Support » Gravity Forms

  1. m4change
    Member

    I came across two bugs in migrating forms to production. My local environment uses a made up tld, .loc, so really all I have to replace is sitename.loc with sitename.com or what have you.

    The migration process involves dumping the database, replacing the references with sed, then rsync to server and import the database. I've been doing this for a while without any issues. I realize there is an export function built into gravity forms but 1) it changes form ids 2) it's not nearly as quick and easy as calling a bash script.

    With that said. I noticed two things that cause form migration to fail and they even disrupt the xml exporting under some conditions, I thought you would like to know

    The following bugs result in the "oops unable to locate form" message.

    Bug 1) Using double quotes in the confirmation message even using single qoutes on an <a href="#">my link</a> breaks the migration

    The workaround here is to use single quotes.

    The workaround is the same as below.

    Bug 2) This one boggles my mind, having a link in the redirection field under "advanced" form options.

    The workaround for me here is to remove the link, migrate to production and manually add the URL on the live site.

    Posted 13 years ago on Wednesday December 15, 2010 | Permalink

  2. Carl Hancock
    Administrator

    We'll look into these issues. So you are aware, form id's are not carried over when doing an import/export because form id's are database specific and you could be importing a form into a site that already has forms.

    Posted 13 years ago on Wednesday December 15, 2010 | Permalink

  3. m4change
    Member

    Can't there be a check for if the id already exists or perhaps an option to reference forms by an english name? This becomes an issue when hooking into forms because the functions are then separated from a form if they are imported with a new id.

    Posted 13 years ago on Wednesday December 15, 2010 | Permalink

  4. Carl Hancock
    Administrator

    id's are database specific. The import/export tool isn't designed to be a database clone tool. It's just a simple way to import/export form settings. It's an export of the form setup, not the specific form data.

    If you need to keep the id's intact then you would have to do a manual import/export using SQL database tools to maintain the exact database setup.

    Posted 13 years ago on Wednesday December 15, 2010 | Permalink

  5. m4change
    Member

    Alright, I understand. Hopefully we can work through the bugs in the current SQL migration.

    Posted 13 years ago on Wednesday December 15, 2010 | Permalink

  6. m4change
    Member

    Again, I experienced this issue in migration in a different way but it helped me get closer to understanding the cause of this issue.

    The table that breaks during migration is 'rg_form_meta'. The way it breaks is interesting and illusive. My migration process is as follows:

    1. Dump local database
    2. use sed to replace the url for the production site
    3. rsync the sql dump to the server
    4. drop old database, import the new one

    For some reason, when I change the value of the url in the gravity forms rg_form_meta table, it's auto-incrementing the ID of that field and causing the 'oops form not found' error.

    Here is a screenshot of the diff of the database after the aforementioned process takes place:

    http://i.imgur.com/3Lx7k.png

    This baffles my mind. Please any advice about this is appreciated, it's an extremely annoying bug to work around.

    The basic code I use:

    1. mysqldump -u USER -pPASSWORD DB > db-dump.sql
    2. sed -i 's#http://www.site.loc#http://www.site.com#g' db-dump.sql
    3. rsync -avzh db-dump.sql RUSER@RSERVER:RDIR
    4. mysql -u USER -pPASSWORD

    xml test form:
    http://pastebin.com/2CqDVChP

    Posted 13 years ago on Wednesday January 5, 2011 | Permalink

  7. m4change
    Member

    okay... so this number appears to be a length indicator of sorts and that's where the confusion seems to be happening when the urls are different lengths.

    Found this out when trying the name:

    s:17:\"http://unique.com\"
    echo "http://unique.com" |wc -c
    18

    Other than making the local domain the same exact length or using maths to calculate the new length during the sed process... is there anyway I can compensate for a difference in length?

    Posted 13 years ago on Wednesday January 5, 2011 | Permalink

  8. Carl Hancock
    Administrator

    The issue isn't a bug in Gravity Forms, it's an issue with the migration process itself. We have seen this occur with export and imports in PHPMyAdmin. If the data was exact, you wouldn't be encountering errors. But things get changed. I'll have Alex respond with more information, however he is currently traveling so there may be a slight delay in his response.

    Posted 13 years ago on Wednesday January 5, 2011 | Permalink

  9. Chris Hajer
    Key Master

    I've had this happen before with WordPress serialized data. After the first time it happened, I was careful to use domain names with the same number of characters in them for dev and production, so I could do the simple search and replace and not corrupt the serialized data.

    So, now I use ww2.example.com for development and www.example.com for production (or example.org and example.com). With the same length domain names, the length of the values in the serialized database entries does not get corrupted.

    I think maybe the BackupBuddy plugin took care of this as well, but I never tried it to confirm.

    Migrate

    • Develop on one server & launch on another in minutes.
    • Easily change your site’s domain name.
    • Rapid deployment of your favorite default environment.
    Posted 13 years ago on Wednesday January 5, 2011 | Permalink

  10. m4change
    Member

    Thanks for the link to BackupBuddy, I'll look into it. I'm also looking into the following library:

    http://spectacu.la/search-and-replace-for-wordpress-databases/

    Posted 13 years ago on Wednesday January 5, 2011 | Permalink

  11. Alex Cancado
    Administrator

    I have created a plugin that helps fixing the serialized meta when the lengths get out of sync (which seems to be your problem). Shoot me an email to alex@rocketgenius.com and I will send it your way.

    Posted 13 years ago on Thursday January 6, 2011 | Permalink