Corey Salzano

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.)

When using register_rest_field() to add fields to terms in the WordPress REST API, the $object sent to your get_callback function will be an array instead of an object like the documentation describes.

An object will still be passed, sometimes, too. Here is an example of how I work around this problem:

	function add_api_term_fields() {

		//location-phone-hours
		register_rest_field( 'location', 'location-phone-hours', array(
			'get_callback'    => array( $this, 'get_term_meta_via_rest' ),
			'update_callback' => array( $this, 'set_term_meta_via_rest' ),
			'schema'          => array(
				'description' => __( 'An array of phone numbers and hours of operation for this location.', 'inventory-portal' ),
				'type'        => 'string',
				'context'     => array( 'view', 'edit' ),
			),
		) );
	}

	static function get_term_meta_via_rest( $term, $attr, $request, $object_type ) {
		$term_id = 0;

		if(  is_array( $term ) ) {
			$term_id = $term['id']
		} else {
			$term_id = $term->term_id;
		}

		return maybe_serialize( get_term_meta( $term_id, $attr, true ) );
	}

Why is this happening? See the definition of prepare_item_for_response() method on line 683 of wp-includes/rest-api/endpoints/class-wp-rest-terms-controller.php. The call to add_additional_fields_to_object() on line 725 is the method that passes an array to your get_callback.

Perhaps this is an acceptable design. I believe the only reference to the data type of $object in the documentation is this comment. It certainly feels like a bug.

Elementor Pro includes a form builder widget, complete with a webhook to which all form data can be sent and a redirect URL to send users after successful submissions. I have been tasked with adding a second webhook to a form because the first was being used for an integration with Zapier.

We need to use the elementor_pro/forms/new_record hook to make this work, and it is possible to prevent the form from submitting if our additional webhook fails. Here is a simple plugin that adds a webhook to all Elementor Forms sitewide:

https://gist.github.com/csalzano/dfd754e0fe8b6ac10731fad8f257c0bf

If you need to target a specific form, access the form name or ID using the $record object.

//Get the Elementor form ID
$form_id = $record->get_form_settings( 'id' );

//Get the Elementor form name
$form_name = $record->get_form_settings( 'form_name' );

Take care when updating posts via the WordPress REST API to not send unchanged serialized meta values. The entire update will fail and return a 500 error. The JSON response looks like this:

{
	"code": "rest_meta_database_error",
	"message": "Could not update meta value in database.",
	"data": {
		"key": "meta_key_name",
		"status": 500
	}
}

This error comes from line 300 of wp-includes/rest-api/fields/class-wp-rest-meta-fields.php, and to understand why calls to update_metadata() return false for unchanged and serialized meta values, read on.

Let us look at like 196 of wp-includes/meta.php. We learn that if a previous value is not passed to update_metadata(), that function looks it up for a comparison and returns false if they match. During REST API calls, the previous value is not provided.

So why doesn’t the REST API return an error for updates to any post meta values?

The REST API tries to short-circuit and avoid calling update_metadata() on line 293 of class-wp-rest-meta-fields.php when the incoming value has not changed, but the conditions were not designed for serialized data:

		if ( 1 === count( $old_value ) ) {
			if ( $old_value[0] === $meta_value ) {
				return true;
			}
		}

By this time, the meta value in $old_value has been run through maybe_unserialize(), but the new value in $meta_value has not. This short circuit fails, update_metadata() is called & returns false instead of true, and the API responds with a 500 error as a result.

WordPress 4.9.4 does not support the post_parent attribute in the REST API, so I wrote a plugin that does.

Download here: https://github.com/csalzano/wp-api-add-post-parent

Someday, WordPress core will allow the manipulation of the post_parent attribute, and I look forward to deleting this plugin and this blog post when they become obsolete. Until then, I believe this implementation resembles how core will handle this.

WooCommerce is a big plugin that ships with several JavaScript loading animations. There is no reason to roll your own when you need one.

This week, I am hacking on WooCommerce to convert “Add to Cart” buttons to prevent redirecting users to different pages. Here’s a great tutorial I used to accomplish this goal. Without page loads, users benefit from loading animations in understanding that something is happening that they otherwise cannot see.

Buttons

Adding a loading class to buttons dims the button and shows a white spinning gear inside the button to the right of its label.

Usage

jQuery('button.single_add_to_cart_button').addClass('loading');
jQuery('button.single_add_to_cart_button').removeClass('loading');

Containers

WooCommerce also provides JavaScript to block and dim a whole content container because it ships with BlockUI. BlockUI is a jQuery plugin that WooCommerce uses to obscure the user interface while executing synchronous JavaScript. You can see how it’s used by WooCommerce core when removing an item from the shopping cart on the cart page.

Usage

jQuery.blockUI();
jQuery('.product').block();
jQuery('.product').unblock();

The default message is “Please Wait…” but you can provide your own text in the options array.

jQuery('.product').block({message:'Updating cart...'});

There are more examples on the plugin’s demos page.

Yesterday, I needed to create a modal, but I didn’t want to create a modal.

“Surely, this is already in WordPress.”Corey Salzano

So, I went looking for a modal in WordPress core, and I was delighted when I found one. Thickbox is JavaScript library that was created more than one decade ago and began shipping with WordPress in 2008.

Why Thickbox in WordPress is great

1. It’s a modal API built into core
2. It’s a simple white box with an optional title, close button, and no offensive styling
3. You don’t have to build it

Perhaps Also Not Great

I quickly noticed one shortcoming of the implementation. There is no way to specify the height and width of the modal using percentages. The values are required to be supplied in pixels, unless you use this JavaScript that enables the use of percentages:

Thickbox’s fate as a part of WordPress core is questionable. Here’s a six year discussion of whether it should still be included, and WordPress core also bundles jQuery UI Dialog via the ‘jquery-ui-dialog’ script handle.

Even if WordPress core drops this library in a future version, a plugin could be written to maintain compatibility. Today, I prefer thickbox because its implementation is so simple.