With the release of Formidable Pro 2.0 coming last night, let’s talk about some of the changes most likely to require you to make adjustments to your settings or even to some custom coding you might have done previously.
Formidable 2.0 comes with a complete re-thinking of the way certain actions were happening and email notifications is one of those actions. In the past, if you wanted to send the same email to multiple recipients, you would simply add each email address in the To: field separated by commas. Formidable would send a separate email to each of these recipients so you didn’t need to be concerned about one recipient seeing the email addresses of other recipients.
Now, with emails being merged into the new Actions area, Formidable will only send one email per action instance. This means that if you have multiple email addresses in the To: field, they will all show to each recipient, similar to how most email client programs would work.
To prevent this, you will need to move the additional recipients to the new BCC: field to hide their email addresses. This is good in a situation where, perhaps, you are sending a response to the person who completed the form, but you are also sending a copy to yourself or someone else internally.
Before we leave the Form Actions area behind, it’s a good idea to note that plugins that provide settings pages within the form’s settings will no longer be listed down the left-hand side, but instead will show as additional actions available in the Actions area. When installed, Formidable Addons will have their icon become clickable and third-party addons will show their icons here. Clicking any of them will add an instance and you will be able to edit their settings.
Twilio Settings Migration
If you are using Twilio with any forms, it is very important that you upgrade to the latest Twilio Addon before upgrading to Formidable 2.0 or you may lose your current configuration and need to re-enter these settings. This is a very recent update to both Formidable and the Twilio Addon so look for version 1.02 or later of this Addon.
Changes that Could Affect Styling
There are a few fields that have had HTML changes that could affect custom styling if your CSS was based on certain parameters. Not all fields are affected and even for fields that are, you would have to have specified specific IDs or other changed elements for your styling to break. While I don’t advise you to panic, it’s a good idea to be aware in case you see major differences after you upgrade.
As far as I can tell, these changes are limited to fields with multiple options, like dropdown, checkbox, radio and scale fields. Each option uses an HTML label tag and an attribute of “for” set to the HTML id attribute of the input tag. Since that id attribute has changed from being based on the form field’s key instead of it’s id, these values are now different.
While it’s not likely you have custom styling based on the label’s “for” attribute, it is possible you might have used the input tag’s id for styling. Still, however, this is a very rare use case so chances are good you won’t be affected. You can see in the image below where I highlighted the change. In the past, this section was the field’s id. Now it is the field’s key. Any CSS that points to this HTML id attribute will need to be updated.
A real-world example of where I discovered this was in the demo for a previous post, Better Graphs and Charts for Formidable Pro with WP Charts. In it, I styled each individual star in my star rating fields to be absolutely positioned over a graph. After updating, things wen’t whacky until I narrowed down the problem and updated my CSS.
Another Styling Change, Inline Submit Buttons
In the past, if you wanted the submit button to float to the right side of your fields, you would float the frm_form_fields class left and reduce it’s width to give room for the submit button to pop into place. Make a little adjustment to the top margin and width of input[type=submit] and you had a submit button inline with the fields.
Note: In order to make this work, however, there were changes made to the HTML that will mean previous CSS edits to move the submit button will no longer work. If you followed this example in the past, you should go into any affected forms and select the inline setting after updating. Until you do so, the button will fall back into it’s default position.
Your reCAPTCHA Keys May Need Updating
In the old reCAPTCHA, it was possible to simply create one key and use it across multiple websites on different domains. In Formidable 2.0, they have updated to Google’s sweet new reCAPTCHA that is nearly frictionless for visitors, (even easier than simple Math Captcha), Google now requires that you list each domain when registering for a key.
If you’ve never actually used the same reCAPTCHA key on multiple website, this is not an issue for you. If you have, however, you just need to follow the link in your global settings to register a key and either update your current keys or create new ones for each domain.
Going Away, User Tracking
As part of an overall effort to reduce Formidable’s weight on page loads, the global option to track users from page to page has been removed from 2.0. I’m a big fan of any plugin that chooses to reduce it’s affect on page loads when the functionality falls outside of that plugin’s primary purpose to begin with. Chances are you can get this same information from Google Analytics, but in some cases you may want to use a plugin specifically for tracking this activity. Here’s a good comparison of several plugins that track logged in user activity.
Big Change to the frm_where_filter Hook
Now, I tried to save the nerdiest topic for last. If you’ve never customized a Formidable action hook using PHP, then it’s most likely you don’t need to read this part. Even if you have, there is currently only one hook that has one certain scenario that is not able to be backwards compatible and will need attention to work properly.
The frm_where_filter hook is used to customize a filter that was added to a Formidable View. This hook receives two values, $where and $atts, like function filter_custom_display($where, $args). Previously, the $where value was a simple string. For better security, it has now been changed to an array.
If you customization changes the entire value of $where, it will continue to work as it did before. However, if your custom function appends a value, (i.e. uses “.=” operator), then you will need to update your function for your customization to work.
If that flew right over your head and you’ve never hired a developer to customize Formidable, then you are probably okay and don’t need to worry about this.