Migrating a GravityView Without Losing Fields

Exporting a GravityView and importing it into a different site is easy, and there are official instructions right here.

This process works very smoothly when the GravityForms and GravityViews on both sites are identical. That’s usually not the world I live in, however. I’m a back-end developer in sites that sometimes have multiple teams working on them. I am usually only responsible for some of the GravityForms in the site, and that means the IDs of the forms I import into the site aren’t predictable.

Migrating a GravityView from one site to another is easy as long as the ID of the GravityForm on which the GravityView is built does not change. If the ID of the underlying form changes, the view loses all the fields on the multi, single, and edit lists. This is frustrating because GravityViews take quite a while to configure, and those field lists are the bulk of the work.

If you have the ability to run MySQL queries against the database of your WordPress installation, you can run a couple queries after importing a GravityView to update the view with the ID of the GravityForm on the new site. The most popular tool for database manipulation in WordPress world is phpMyAdmin. Here’s the first query you need:

UPDATE wp_postmeta SET meta_value = 1 WHERE meta_value = 42 AND '_gravityview_form_id' = meta_key;

You need to change the numbers 1 and 42, which are the new GravityForm ID and the old GravityForm ID, respectively. Also, take care to make sure your table prefix is wp_ like this example, or change that, too.

Next, adjust this query and run it:

UPDATE wp_postmeta SET meta_value = REPLACE( meta_value, 's:7:"form_id";s:2:"42";', 's:7:"form_id";s:1:"1";' ) WHERE '_gravityview_directory_fields' = meta_key;

Look for 42 and 1 again. If your form IDs aren’t one and two digits like this example, you’ll also have to change the s:1: and s:2: that precede the values to match.