Category: WordPress

For a ContactForm7 form that has this source:

<div class="wpcf7-lead-widget">[text* contact-name maxlength:50 placeholder "Your Name (required)"]
[email* email maxlength:50 placeholder "Email (required)"]
[text phone maxlength:15 placeholder "Phone"]
[vehicle_form_field]
[textarea comments x3 placeholder "Questions and Comments"]
[submit class:_button class:_button-small "Check Availability"]
[hidden context id:context "contact"]
[hidden do-not-send-mail]</div>

The $posted_data that is passed via the wpcf7_posted_data hook looks like this:

Array
(
[_wpcf7] => 10610
[_wpcf7_version] => 5.1.1
[_wpcf7_locale] => en_US
[_wpcf7_unit_tag] => wpcf7-f10610-p7983-o1
[_wpcf7_container_post] => 7983
[g-recaptcha-response] =>
[contact-name] => Corey
[email] => [email protected]
[phone] => 8005556666
[inventory-post-id] => 7983
[comments] => Super interested in this sandbox
[context] => contact
[do-not-send-mail] =>
)

The first item is the form ID, and all items after g-recaptcha-response are the values of the fields provided by the the user (or the source in the case of the hidden fields). inventory-post-id is the value of a drop down created by the shortcode in our form, [vehicle_form_field].

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 Gravity Forms 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 Gravity Forms 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 Gravity Form 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.

Let’s Run Some Database Queries

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 Gravity Form on the new site.

Query #1

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 Gravity Form ID and the old Gravity Form ID, respectively. The IDs of your Gravity Forms are listed when you click Forms in the dashboard. Also, take care to make sure your table prefix is the default wp_ like this example, or change wp_postmeta to match.

Query #2

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 our form IDs "42" and "1" again. If your form IDs aren’t two and one digits like this example, you’ll also have to change the s:2: and s:1: that precede the values to match. These are pieces of a serialized PHP array, where s means string and the :2 means that the string "42" has a length of two characters. (Likewise for s:7 identifying "form_id" as a string with a length of seven characters.)