Version 2.4.2 Released

Back when we released 2.3, we decided to become more deliberate about our larger releases. We still plan on releasing bug fixes frequently, but we want our larger releases to be focused on adding new features or addressing a very real need. We feel this 2.4 release fits both of these.

You can check the changelog for all the little things that have been added or fixed, but in this post we want to share what we were really focused on. First, let’s talk about the why.

Ninja Forms & Scalability

Over the last few months, we’ve had several users attempting to create truly epic forms with Ninja Forms. By epic, I mean that they weren’t just creating a form with a few dozen fields but forms with fields ranging from 150 to 500 fields. This is an enormous amount of data to be included in a single form. If you were to build a 500 field form in just pure html, it would still be considered heavy, bloated, and slow. Additionally, Ninja Forms is constructed with a lot of php and, in some cases, a bit of javascript. Throw in some more complex functionality from our various add-ons, and 500 fields would be considered absolutely crippling.

The biggest challenge to smoothly running forms this large was that there were a lot of things that had to be checked upon form load. These things had to be checked multiple times, because there was no persistent storage of field data. Every piece of form and field data had to be passed through multiple filters while looping through all the fields to be displayed.

Let’s say that you wanted to add a small piece of HTML to one of your form labels on the fly. In previous versions, you would need to add a function to the ‘ninja_forms_field’ filter. On the surface, this seems perfectly harmless, and in most cases it was. The problem, though, is that you are forced to run this filter on every field in your form, even if you wanted to modify one field. If you have hundreds of fields, this function could be called hundreds of times. Throw in the fact that you were probably going to have to touch the database to pull the specific field’s settings and you have a recipe for scaling problems.

If you have a few dozen fields, you probably wouldn’t even notice this overhead, but if your form has a few hundred fields, looping over every one a few dozen times can make things very cumbersome. That’s where this new release comes in.

We want Ninja Forms to be a go-to solution, regardless of the size or complexity of your forms, so we knew that we needed to act fast and create a solution to make larger forms as fast as possible. That’s where the how comes in: the new $ninja_forms_loading class.

New Loading Class and Methods

In order to speed things up on the front-end, we needed a way to persistently store data. Not just data that you might want to add to a field, but all of the data that is related to that field: ID, label, default value, options, etc. This means that Ninja Forms only needs to touch the database once per form load. In the example above about adding HTML to a specific field’s label, we could now hook into the ninja_forms_display_init action and modify $ninja_forms_loading. We never, ever have to touch the database to pull information about that field. If you want to change the default value of a field, you no longer have to use the ninja_forms_field filter; you can hook into ninja_forms_display_init and simply modify the value using $ninja_forms_loading->update_field_value( $field_id, $value ). This code will execute once when the form loads, rather than when each field is displayed, which could be hundreds and hundreds of times.

For developers, this means that if you want to modify something about the field, you can simply declare the $ninja_forms_loading global variable and use it. You don’t have to use ninja_forms_get_field_by_id() for anything on form load. This should significantly cut down on the overhead required to load a long form, especially one that uses lots of calls to the ninja_forms_field filter. If you’re a developer, don’t worry. The ninja_forms_field filter still exists and will continue to do what it’s supposed to do.

If you’re using this filter, especially in conjunction with a database calling function like ninja_forms_get_field_by_id(), we’d recommend checking out the new $ninja_forms_loading class and new display actions. You may be able to shave a little more off of your load times by changing over to the new method.

$ninja_forms_loading is very similar to the $ninja_forms_processing global. They share many of the same methods.


If you have a Ninja Form that’s made up of over a hundred fields, version 2.4.2 introduces some new loading methods that should significantly speed up how long it takes your form to load. One of our users with a 150+ field form went from a 20 second loading time down to 3.4. I’ll type that again. 20 seconds. To. 3.4. Now, we can’t guarantee that your site will experience the same increase, but it should load much more quickly than it does in previous versions. (If you update to version 2.4.2, make sure that your extensions are all up to date to take full advantage of the speed increase and avoid any possible issues.)

For developers there’s a new method for loading and changing Ninja Forms data upon display. This method should ensure that any extensions for Ninja Forms can take advantage of the newly found loading speed.

This is just the first step in making Ninja Forms a more lean, mean, form producing machine; we can’t wait to show you what else we have instore for 2014!