Notes On Changes To Form Configuration Saving In Caldera Forms 1.3.4

In Caldera Forms we changed how form configuration — not entires are stored. This change should be seamless and was done both for performance reasons as well as to help us with our future plans for the plugin. It is important to note that while this involves some moving of data to a new location, the old data is not removed. That means if you need to roll back to an older version of Caldera Forms, your old forms will still work.

This process should go smoothly for all users. There are technical details below, but the simple explanation is we didn’t move the location of individual forms, just how we save the list of forms. This means that if the bad edge case we have done our best to prevent happens, your forms will not break in the front-end.

If Something Goes Wrong

If suddenly, after upgrading you see no forms in the admin after update — please don’t panic. Your data is not lost and your forms will work in the front-end. Most likely, the top of our admin screen will turn red and give you a button to re-run the updater.

If that doesn’t work, add this code to your theme’s functions.php and reload the admin page.

add_action( 'plugins_loaded', function() {
   if( ! is_admin() ){ return; }
   include_once CFCORE_PATH . 'includes/updater.php';


If that doesn’t work, please use WP Rollback to revert to the old version of Caldera Forms and contact us.

Technical Details

In previous versions of Caldera Forms, we stored a array of data about all saved forms in one option called “_caldera_forms”. That option, which we call “the registry” didn’t have the full configuration, but it still could get really big. We also stored each form’s full configuration in a separate option named for the form’s ID.

This had a few drawbacks, beacuse each of these options was autoloaded. Also, the registry could get quite large, and was filled with redundant data. So in the new version we made all of these options not autoload and we migrated the registry to a new option “_caldera_forms_forms” that has only the IDs of the forms.

On this site which has about eight Caldera Forms, we are seeing minor performance improvments in the front-end and significant improvments in the editor. We also moved all form configuration functions into a new class Caldera_Forms_Forms. This new class was created to centralize create, read, update and delete functions for forms, to decouple those functions from HTTP requests in the admin and allowed us to get unit test coverage form them.

This is the first step on our roadmap for moving all database interactions into testable classes, that will be more stable with our UI, and work equally well with our current system and with the REST API we plan to add to our plugin soon.