Yesterday we released v1.1 of our Affiliate Forms for Gravity Forms pro add-on.
Some notable changes come with this release, particularly in regard to enforcing new minimum required versions for Gravity Forms, AffiliateWP, PHP, and WordPress.
Additionally, we’ve refactored how we register custom field types and added full compatibility with the new form editing experience introduced in Gravity Forms 2.5.
New minimum requirements
In the spirit of our campaign for increasing the minimum requirements of all AffiliateWP’s products starting this year, Affiliate Forms for Gravity Forms is no exception.
The new minimum requirements for Affiliate Forms for Gravity Forms are as follows:
- Gravity Forms 2.0 (was 1.6, latest stable is 2.5.2)
- AffiliateWP 2.6 (was 2.1.7, latest stable is 2.6.8)
- PHP 5.6 (was 5.3, latest stable is 8.0.6)
- WordPress 5.0 (was 4.4, latest stable is 5.7.2)
We’re not necessarily shooting for the moon with these increases. We’ve taken great care to set minimums we feel are inline with current install trends.
With the improvements that shipped with v1.1 comes a “partial activation” mode that will be triggered if there are unmet requirements. Plugins that rely on AFGF will continue to work, and AFGF itself will be “on” but its bootstrap will not run until the minimum requirements are met.
These increases are the first of two happening this year for this add-on. For more information on what’s coming up this fall, check out our minimum requirements roadmap.
Compatibility with the new form editor
To talk about where we are today and what’s changed in AFGF and why, it’s important to first cover where we’ve been.
Breaking free of the old ways
For the entire lifespan of the add-on (2015-present), we’ve been using legacy actions and filters for registering custom field types.
For example, we used to use a flavor of the code sample below to initially register our custom field types and field group:
<?php
/**
* Adds custom field types to Gravity Forms.
*
* @since 1.0
*/
function my_custom_gf_fields( $field_groups ) {
// Custom field(s).
$fields = array(
array(
'class' => 'button',
'value' => 'Some field',
'onclick' => "StartAddField( 'some_field' );",
),
);
// Custom field group.
$field_groups[] = array(
'name' => 'custom_group_slug',
'label' => 'Some Custom Group',
'fields' => $fields
);
return $field_groups;
}
add_filter( 'gform_add_field_buttons', 'my_custom_gf_fields' );
This wasn’t necessarily a bad system, just outdated and not nearly as “rich” as directly extending Gravity Forms’ Fields framework. We’d hook in in various places and return custom data to filter hooks or manually output some markup on an action hook or four.
Over the years and the many iterations Gravity Forms made to their form editor, this approach continued to work pretty well. With the introduction of the new form editing experience in Gravity Forms 2.5, we decided it was finally time to update our code and embrace something closer to modern best practices.
Modern APIs for modern form editing experiences
The three custom field types we’ve always registered in Affiliate Forms for Gravity Forms (AFGF) are Username, Promotion Method, and Payment Email using the ‘username’, ‘promotion_method’, and ‘payment_email’ field types, respectively.
Before, these field types were registered via the aforementioned nested arrays with very little extra information than the few attributes we were able to set that way.
In extending the GF_*_Field classes today, we instantly gain streamlined access to setting all sorts of environmental attributes that both the new and older form editors leverage!
A great example of this streamlining is the ability to set the field title in a field class by overriding the get_form_editor_field_title() method:
/**
* Retrieves the form editor field title.
*
* @since 1.1
*
* @return string Field title.
*/
public function get_form_editor_field_title() {
return esc_attr__( 'Payment Email', 'affiliatewp-afgf' );
}
This method informs the field titles in both the new and old form editors. The legacy method required that we separately hook to the gform_field_type_title filter. Now we can encapsulate this information into the individual field classes themselves and keep it all together.
Other good examples specific to the new form editor are the ability to set proper field type descriptions or custom icons by overriding the new get_form_editor_field_description() and get_form_editor_field_icon() methods, respectively.
These are just a few examples of what we can do now that we’re registering custom field types with the Fields framework! Did we mention that extending the Fields framework also comes with other goodies like access to standard conditional logic? It’s been a pretty great change to make and long overdue.