How To Populate Data Based on the Current User

Overview

Populating user data is a common need in Gravity Forms. You need to collect the current user’s e-mail and mailing address in an order form, you’d like to populate data from a different form’s entry, or you want to pull in a custom field from the current user’s most recent post. No matter the need, this tutorial will walk you through the different ways you can populate fields with data specific to the current user.

---

1. User Meta
   1. User Merge Tag
   2. Populate Anything
2. Populate Any Data Related to the Current User
3. Populating From Tables Without the User ID

---

User Meta

User Merge Tag

Gravity Forms supports populating user metadata into a form’s fields with the {user} merge tag. Its usage is simple:

{user:META_FIELD_NAME}

Replace META_FIELD_NAME with any metadata field’s name and it will automatically turn the merge tag into the appropriate data. For example, {user:user_email} will populate the current user’s email into a field.

Any user meta field is supported, including custom fields. A non-exhaustive list of supported user meta fields is available in Gravity Forms documentation. For a more exhaustive list, you can look at the users and usermeta tables in your WordPress database. Most of the fields there can be used with the {user} merge tag, minus some obvious ones like user_pass.

This is a powerful feature, but it is limited to populating user meta. What if you want to populate something that isn’t user meta that is still specific to the current user? Populate Anything has you covered.

Populate Anything

GF Populate Anything makes it simple to dynamically filter and populate field choices (such as checkboxes) and values with pretty much anything that exists in the WordPress database. Using the population and filter options, we can populate all kinds of data from various data sources that is pertinent to the current user.

Let’s take the example above, say you want to populate information about the current user (such as their email) into a field. To do this, set the Type to User, apply a filter where the User ID is the Current User ID, and set the Value Template to User Email.

Hold up, this seems complicated.

Don’t be overwhelmed by the number of options in Populate Anything. It’s actually quite simple once you break down the different sections.

Type

Populate Anything can populate from five sources called Objects. Supported Object types are Post, Taxonomy Term, User, Gravity Forms Entry, and Database. Each Object tells Populate Anything where the data originates from i.e. its data source.

For example, if you want to populate user meta into a field, you select User. If you want to populate Post meta, select Post.

Filters

Filters do exactly what they say on the tin: filter the data. When data is populated from the data source, it’s very likely there’s going to be multiple matches for whatever Populate Anything finds. Filters let you narrow down that data into something more specific.

For example, if you select the User object, Populate Anything is going to find every user on the site. To narrow down which user specifically is populated into the field, apply filters to narrow down the results.

Value Template

The value template is the thing you’re actually populating into the field. Once you set the Object, the Value Template drop down will populate with all of the available values you can populate. Whatever you select here is what is going into the field.

For example, if you select the User Object, the possible Value Templates are all of the user meta fields including personal data: Display Name, Email, User ID, etc.

Populate Any Data Related to the Current User

If you need to auto-populate data from another part of the WordPress database (the data source), fear not. Much of the WP database structure includes the user ID or some other data type to create relationships, and Populate Anything can use those relationships to find and populate the right data. For example, if I want to populate some data from the most recent post by the current user I would use these settings.

This doesn’t look much different than populating from the User object and that’s because the Current User ID option is always available for filtering in Populate Anything. Let’s try something more complicated. Let’s say we want to populate the most recent WooCommerce order for the current user.

First, we need to populate WooCommerce orders that are completed. WooCommerce stores orders as a Custom Post Type called “Orders”. Populating that is easy enough.

Filtering on order status requires a little more finesse. WooCommerce uses custom post statuses for orders. To filter on the custom status, select Add Custom Value in the rightmost drop down, then enter wc-completed to filter for completed orders.

Now we can add the current user to the mix. We’ll target another WooCommerce meta key, this time _customer_user, and once again we’ll filter it to the Current User ID. The settings here will populate the most recent order total for the current user.

Populating From Tables Without the User ID

In some cases, you might need to populate from a location in the WP database where the user ID isn’t available for filtering. For example, you could have a custom table of employees that uses employee IDs that are different from the WordPress user IDs, but it also includes the user’s email address.

No sweat, this just adds another step. First, populate the current user’s email into a Text field on the form.

Then, populate from your custom database and filter the results to the Email field you populated above.

And here’s what it looks like on the front end when the user views my form.

Wrapping Up

As you can see there’s more to unpack with populating data based on the current user. Using Populate Anything’s powerful filters, you can pull in specific data from all over the WordPress database with ease.

Send Us Your Ideas

If there’s some data you’re longing to populate into a form, let us know. If it can currently be done with Populate Anything, we’ll point you in the right direction. If not, we’ll consider it a feature request and it might show up as new functionality in a future release!