Extending well-built WordPress plugins and themes is something I do almost daily. Gravity Forms is a popular form-building plugin for WordPress that I integrate and customize quite frequently. Custom form fields, form settings, and third-party integrations are common requests.

Recently, I had to find a way to handle custom, dynamic redirects on form submission.  The redirect would be dependent on query string parameters provided by an inbound affiliate link.  I was able to quickly create a solution due, in no small part, to the fact that Gravity Forms is a “well-built” plugin.¹A “well-built” third-party plugin/theme means that it adheres to WordPress Coding Standards and makes APIs/hooks available to other developers for extending the base functionality, among other things.

The Challenge

To solve the challenge summarized above, the client’s original solution was to simply create separate forms for each incoming affiliate URL and set a static redirect confirmation for each of those forms.

However, that can get nasty in a hurry.  Imagine many unique affiliate links with each one requiring a separate form.   That isn’t fun for admins to manage, and it would violate a sacred tenet of good development: “DRY”²”DRY” – Don’t Repeat Yourself.  A big no-no in development or even general process efficiency. code.

Instead, it would be nice if we could have a single form that has a dynamic redirect confirmation based on the incoming URL’s query string.  We’d get bonus points for being able to define, from the admin, query string parameter keys, values, and associated redirects for each combination.

Gravity Forms Gets A Smiley For Its Hooks

As it turns out, we can create the dynamic confirmation redirects.  Gravity Forms makes available a hook named gform_confirmation that allows us to filter, or change, the default confirmation settings for a form on submission.

The gform_confirmation hook provides four arguments.  The $confirmation variable is the incoming, default redirect, $form is the current form object, $entry is the submitted form data, and $is_ajax tells us if this form is sent via AJAX.

The $confirmation variable is the one we’ll return from our filter function. If you’re familiar with the Gravity Forms form builder in the admin, you’ll know that there are three types of confirmations: text, page, and redirect. For the text type, the $confirmation variable comes to us as a string, and page and redirect come as an array. Ergo, as a redirect, we’ll need to return an array.

Putting all of this together, we can update the confirmation with a small snippet in our theme’s functions.php file.

<?php
function de_gforms_confirmation_dynamic_redirect( $confirmation, $form, $entry, $ajax ) {
    $confirmation = array( 'redirect' => 'https://redirect.com' );

    return $confirmation;
}

add_filter( 'gform_confirmation', 'de_gforms_confirmation_dynamic_redirect', 10, 4 );
?>

The code here is pretty straightforward. We’re simply overriding the confirmation settings for the form to redirect the user to “https://redirect.com”. However, this function is now attached to every Gravity Forms form submission. What if we only want to apply this change to a specific form?

<?php
function de_gforms_confirmation_dynamic_redirect( $confirmation, $form, $entry, $ajax ) {
    if ( $form['id'] == '1229' ) {
        $confirmation = array( 'redirect' => 'https://redirect.com' );
    }

    return $confirmation;
}

add_filter( 'gform_confirmation', 'de_gforms_confirmation_dynamic_redirect', 10, 4 );
?>

Above we’ve added a conditional check on the $form variable passed to our filter. Now, our filter only applies to form ID 1229. The “id” is just one form property we can check for in the object. See the documentation for a complete list of all form properties available.

Next, we can check the $entry object. We can choose to filter the confirmation based on the submitted form data:

<?php
function de_gforms_confirmation_dynamic_redirect( $confirmation, $form, $entry, $ajax ) {
    if ( $form['id'] == '1229' ) {
        if ( $entry['2'] == 'Own' ) {
            $confirmation = array( 'redirect' => 'https://redirect.com/owners' );
        } else if ( $entry['2'] == 'Lease' ) {
            $confirmation = array( 'redirect' => 'https://redirect.com/leasees' );
        } else if ( $entry['2'] == 'Rent' ) {
            $confirmation = array( 'redirect' => 'https://redirect.com/renters' );
        }
    }

    return $confirmation;
}

add_filter( 'gform_confirmation', 'de_gforms_confirmation_dynamic_redirect', 10, 4 );
?>

In this example, we have a form ID 1229 with a select/radio field for the user to select their housing type. If the user owns their home, we send them to one page, and if they rent or lease, we send them somewhere else. Fields are numbered keys in the $entry object, and there are many other values available to you with the object. See the documentation for more information.

In our last example, we’ll accomplish our original objective of redirecting a user based on a query string parameter. The parameter key is static, but there are several possible values. Using $_GET, we can get the parameter and check it in our filter.

<?php
function de_gforms_confirmation_dynamic_redirect( $confirmation, $form, $entry, $ajax ) {
    $query_string_redirects = array(
        'own' => 'https://redirect.com/owners',
        'lease' => 'https://redirect.com/leasees',
        'rent' => 'https://redirect.com/renters'
    );

    if ( $form['id'] == '1229' ) {
        if ( isset( $_GET['parameter'] ) && ! empty( $_GET['parameter'] ) && in_array( $_GET['parameter'], $query_string_redirects ) ) {
            $parameter = filter_var( $_GET['parameter'], FILTER_SANITIZE_STRING );

            $confirmation = array( 'redirect' => $query_string_redirects[$parameter] );
        }
    }

    return $confirmation;
}

add_filter( 'gform_confirmation', 'de_gforms_confirmation_dynamic_redirect', 10, 4 );
?>

A $query_string_redirects array is setup to map our expected values for $_GET['parameter']. The code then checks to ensure $_GET['parameter'] is set, has a value, and the value is one of the options in our mapping array. If those conditions are met, we sanitize the value and set the $confirmation to its associated redirect URL.

However, the parameter keys and values are statically hard-coded in our filter function.  What if the form was a user signup form on a corporate site, but the redirect sends users to a URL specific to that user’s location? Each time a new location is added, the code must be updated to accommodate the additional redirect mapping. No matter the use-case, we’d much rather control the $_GET parameter key and the possible values.

Bonus Points!

My affection for ACF is well documented, so we’ll use that. A quick “options” page could be built to create settings to handle the dynamic redirects. This gives admins control over their forms and any custom redirects.

The options page would have fields to make our entire snippet dynamic. A “form” field could select which form ID the redirects apply to. The query string key could be defined as a filed also, so instead of checking for $_GET['parameter'] we might check for $_GET['location'] or $_GET['branch'].

The last fields to define on our options page are the redirect mappings. This could easily be accomplished with a “repeater” field. Admins could then quickly add/edit/delete mappings for things like location, as in our example above. For instance, when a new location in New York is added, they could quickly add a new mapping. The mapping would require that if the $_GET['location'] parameter is set to “ny”, the associated redirect URL would be ‘https://redirect.com/locations/new-york’.

Custom Gravity Forms Setting

Another option is to add custom settings directly in the form editor on the admin side. More hook awesomeness comes by way of a gform_form_settings filter made available by Gravity Forms. With some additional code, you could use this hook to add custom settings. Even the ACF-repeater-like functionality for multiple redirect mappings could be implemented with some JavaScript.

In closing, this article should as an example of how easy, and satisfying, customizing a great WordPress plugin can be for developers. When you’re building your own custom plugins, try to think of instances where another developer may need to alter a value or trigger an action at some specific point in your code. WordPress’s apply_filters and do_action functions are relatively easy to include in your code, and they make me very happy when I see them. To me, it’s what makes a “well-built” plugin.

About David

Web Developer