Along with all the much anticipated features, Gravity Forms 1.9 brings a number of important changes under the hood that developers need to be aware of. If you’re the developer of a Gravity Forms Add-On, or if you have added any customizations at all, please read these notes carefully and make sure you’ve implemented the suggested changes to your code while 1.9 is still in beta. Some of the changes could result in bugs, fatal errors and white screens if the advice below is not followed.

1. GFAddOn: No more protected methods

In response to requests for greater flexibility, and to facilitate customization, we’ve decided to raise the access level for all protected methods to public. This means that all protected methods in add-ons that implement the Add-On Framework must also be raised to public to avoid fatal errors under PHP5.4+. So, if your add-on has any protected methods now’s the time to change them all to public – it will work with both 1.8 and 1.9. This change only applies to add-ons that are using the Add-On Framework. Private methods in GFAddOn will remain private and do not need to be changed.

2. New Field Class: GF_Field

As of version 1.9, GF_Field is the base class for all fields. It can be found in the includes/fields folder along with all the classes for the built-in field types each of which extend the base class. All field objects are now instances of GF_Field or one of its child classes. This change enables us to keep our code more organised and also provides a more unified way for developers to create new field types.

Object notation

When you look through the Gravity Forms code one of the biggest changes you’ll notice immediately is that Field properties are now accessed using object notation instead of array notation. So, for example, $field[‘inputs’] is now written as $field->inputs. If the property does not exist, an empty string will be returned so you don’t need to check that it’s set and you don’t need to use the rgar() function. This means that everywhere you see Field object it’s no longer an array, it’s now a GF_Field object; this includes all PHP actions and filters. JavaScript is not affected by this change

Backwards (and forwards) compatibility

We’ve put a lot of effort into ensuring that the legacy array notation will still work, at least for a while. Once everyone has had a chance to change their code, the array notation will trigger a deprecation notice.

There is one important exception to the array notation backwards compatibility; array values can’t be modified indirectly. For example, the following code will generate a ‘Indirect modification of overloaded element’ notice and will have no effect.

Indirect modification of array values (breaks in 1.9)
$field[‘conditionalLogic’][‘rules’] = $new_rules;

Works in 1.9 but not in 1.8
$field->conditionalLogic[‘rules’] = $new_rules;

Suggested approach (works in both 1.8 and 1.9)
You could either test for the version number or you could copy the entire array into a temporary variable, manipulate it and save it back to the field object, something along the lines of this:
$logic = $field[‘conditionalLogic’];
$logic[‘rules’] = $new_rules;
$field[‘conditionalLogic’] = $logic;

The following built-in field properties are arrays, so if you’re using them, double check to see if you need to change any code that uses them: inputs, conditionalLogic, choices

GF_Field is still in a state of flux at the moment so we don’t recommend that you start using it just yet as a base for new fields in production environments. Once it’s stable we’ll provide documentation and instructions on how to use it for your own projects.

3. Form Editor Buttons: Drag & Drop Support

The field buttons in the Form Editor can now be dragged and dropped onto the Form canvas. You no longer need to supply the onclick inline event as StartAddField(type) will be triggered automatically. However, you will need to add the type data attribute otherwise a deprecation notice will fire. So for example, if you’re using the gform_add_field_buttons filter you’ll need to make the following change:

Legacy Form Editor Button (triggers a deprecation notice)
$group[‘fields’][] = array( ‘class’ => ‘button’, ‘value’ => ‘Poll’, ‘onclick’ => “StartAddField(‘poll’);” );

New Form Editor Button (Version 1.9 only)
$group[‘fields’][] = array( ‘class’ => ‘button’, ‘value’ => ‘Poll’, ‘data-type’ => ‘poll’ );

Backwards compatible Form Editor Button
$group[‘fields’][] = array( ‘class’ => ‘button’, ‘value’ => ‘Poll’, ‘data-type’ => ‘poll’, ‘onclick’ => “StartAddField(‘poll’);” );

Developer Support

We do appreciate that these are some fairly major changes and it might require some significant effort from some developers to change their code. We’d like to support you to make sure your migration is as smooth and painless as possible. so if you have any questions, don’t hesitate to send us a support request. Please don’t use the comments here for support.