Version 3.0 is here with some huge changes to make your life easier. Check out the independent Pro version, new field types, more free form builder features, and much more.
Separate lite and Pro versions
You may be managing a site that has been updating to the free version with each release. Up until now, we've advised those on Siteground to disable automatic plugin updates. But this still leaves you scrambling at least the first time to get Pro back on your site. This has taken much longer to resolve than we would have liked, since it involved huge code changes as well as coming up with a good way to get from there to here.
We are happy to announce this issue is resolved from here on out. When you update to version 3.0, you should see an additional plugin on your plugins page: Formidable Forms Pro. The lite and Pro versions will each update independently, so the version numbers may not always be the same. If the Pro plugin is installed and the lite version is missing, it is installed automatically.
New and improved form fields
The list of fields on the form builder page looks a lot different. The huge UI overhaul is planned for 4.0, but we need more room for new field types now. An amazing redesign is planned, and we can't wait to start working on it next.
But I digress. The fields panel shows the new field types, those that have moved to the lite version, and those that have been buried in another field. Range slider and toggle fields have been checked off the top of our field request list.
Along with these big changes to fields has come a new API for creating field types. If you're a developer, this is huge for you. The new slider field was added in 60 lines of code, plus a bit of CSS. Take a look at the FrmFieldType object class. Plus, we've gone to great efforts to make sure fields done the old way continue to function.
Repeater fields and star ratings now stand alone, while image fields have been merged with URL fields. Reverse compatibility is important to us, so no worries if you were using one of these field types. They will be automatically changed as needed.
New field settings
Beefed up free form builder
I mentioned the fields panel above, so you may have already noticed the the free form builder offers more field types. Phone number, user ID, hidden, number, and HTML fields have all been moved for more complete and powerful free forms too.
We are still considering moving a few more features. If you are using the free form builder, let us know if there is a small but vital feature for your project.
Benefits of CSS Grids
Have you heard of CSS grids? If you are involved in the WordPress community or on Twitter, chances are good you've heard about this awesome CSS option. It's built right into current browsers, and takes very few lines of code to implement. Another big benefit of CSS grids over something like Bootstrap grids, is the HTML structure doesn't have to change depending on how the form is laid out.
By default, all your Formidable forms now use CSS grids. The grids use a 12-column layout with classes that range from frm1 (1 column of 12) to frm12 (span all 12 columns). This makes cleaner layouts by solving a lot of pesky issues we've been seeing, including the placement of field descriptions and long labels when set to the left, and section headings ignoring the top margin when they follow a field in a column. There are bunch of similar styling quirks like this that CSS grids eliminate. The frm_text_block class has also been removed, and the text in radio buttons and checkboxes will wrapping text in a nice-looking way by default.
The CSS grids also help make for easy inline forms. Just add your fields, set the option to align the submit button inline, and up to 6 fields will be in equal by default. But you can further customize the number of columns each field covers with the styling classes.
Drawbacks of CSS Grids
However, CSS grids aren't supported by every browser. If you would like your column layouts to show for those running Internet Explorer, go to the Formidable -> Global settings page and check the "Do not use CSS Grids for form layouts" box. This option turns on the old styling for everyone so you don't get the benefits either. Thanks so much for the feedback from our feedback group that helped us make the decisions on how to best approach this change! 7 of the 40 responses helped us decide to include this fallback, but the rest helped us decide to not keep it as the default.
Also, working on a grid system gives us different widths to work with. In order to keep things simple, we need to not use a grid of 80 columns. This means a few existing classes are deprecated, and will appear a bit differently. frm_fifth, frm_seventh, and frm_eighth are no longer supported. In existing forms, each of these will be a little narrower than they were before. If you really need eighths in your form or a size between 1/12th and 1/6th, add a section field and give it a class like frm_half. Then add classes like frm_fourth to the fields inside of the section. The box on the global settings for IE layouts will also add the old styling back for these other field types.
When you update to 3.0, the first thing you'll notice is the UI pick-me-up. I already mentioned our 4.0 plans, but just want to reiterate that we still have major UI changes designed out for the form builder. Our team will start working on 4.0 right way, and we hope to have it ready at the end of the second quarter. This release is not the UI update that is coming.
This UI facelift includes more responsiveness for the form builder, and an easier way of selecting sizes for form layouts.
Better RTL and A11Y support
Along with a few UI changes, we've improved the front-end A11Y support. Hidden labels are included where required, and "for" is now on most labels. Plus, the field is linked to the field description for screenreaders to process them together. Accessibility is important to us, so please let us know if you run into anything we overlooked.
Right-to-left support has also been improved on both the front- and back-end. When a style has RTL selected, the forms using this style will include the 'frm_rtl' class. This makes styling easier when you have some RTL forms and others set to LTR.
We get a lot of requests, and see some come up over and over again. In our support, we offer ways of doing some of these commonly requested features but always watch for ways we can simplify.
The [entry_position] shortcode was born out of these types of requests. We hear from people wanting to show incremental content like an ad after 3 or four entries, and then another ad after another 5 entries. Or others would like the first entry to show different content with different styling. Read more in the docs to find a few different ways of using this new option.
Check values in the URL with inline conditionals
Have you ever wanted to show something different in your view depending on what was in the URL? It's easy to use the values in the URL to filter which entries show in the view, but what if you just want to change only part of the output rather than exclude it?
Show a message if field 25 is equal to ?set-name-here=gold:
[if 25 equals='param' param='set-name-here']
Show a message when ?set-name-here=gold is equal to 'gold':
[if get param='level' equals='gold']
Possibly breaking changes
As you know, we are constantly changing and adding code. But it also must be removed. We remove code carefully, by keeping it reverse compatible with warning messages when debug mode is turned on. Eventually, those warnings need to be removed to help reduce the footprint and baseline memory usage. Anything that was deprecated before v2.02 has been removed. This includes all of these globals that may still be used in custom code:
global $frmdb, $frm_field, $frm_form, $frm_entry, $frm_entry_meta;
If you are using any custom code or third-party addons, I'd recommend turning on debug mode in your wp-config.php before you update. While the deprecated code is still in place, you will see warning messages with information about what changes need to be made to your code. Once the code is removed the warnings are replaced with errors, making it much more difficult to remedy.
We also recommend using a staging site for testing.
frm_before_get_form: We use this hook in Pro to register and enqueue any scripts.
frm_output_single_style: This hook is also used in the Pro version to insert extra css when the styling settings are saved. We'll also use this hook for our addons so everything can be in a single, minimized file.
There are lots more changes, so take a look at the changelog if you'd like to read on.
A big Thank you!
We are two weeks away from the 7th anniversary of the Formidable Pro release. The plugin, features, and the amazing applications it has built have come a long way since then. But our wishlist and excitement to work on it isn't anywhere close to depleted. I already mentioned the 4.0 UI coming up next, but we also have several addons in the works (expanded date field options, WordPress AMP forms, and another we're not ready to announce yet).
Thanks for all your support throughout the years! We're looking forward to the next 7 and the amazing projects we can help you build.