Writing Transportable Code: Keys vs. IDs

When you drag and drop a field onto a form, two pieces of data to identify the field in code are created. The first, the field’s ID is created by MySQL using an auto increment field. This is a standard methodology used throughout WordPress.

WordPress creates an ID for every single data element added to its database. It doesn’t matter what the element is or does. It can be a post, page, media library item, form, form field, or form entry data element. If it lives in the database, MySQL creates a unique ID for it so it can be identified internally by the system.

The second identity element is the item’s key created by Formidable. Formidable creates keys for forms, fields, and form entries. A form’s key is located on the form’s Settings page.

The Field Key can be seen on this page in any field’s Advanced collapsible section on the Field Options sidebar. Initially, Formidable creates a randomly generated string as the Field Key. You almost have complete autonomy to change this key to something more meaningful to you.

“Almost complete autonomy” means that there are certain words used internally by Formidable that are not allowed as user selected keys. These restricted words are 'id', 'key', 'created-at', 'detaillink', 'editlink', 'siteurl', and 'evenodd'.

If you create a custom key that already exists in the database, or duplicate a form, Formidable detects the key collision and auto appends characters to the end of the string to keep them unique.

Both field IDs and field keys are unique in WordPress. It’s important to keep in mind that as you progress into more advanced code writing topics, Formidable’s objects should be referenced by their key rather than their ID.

The reason for this may not become apparent until you export your forms from one WordPress instance and import them into another. When you perform an export/import operation, the new WordPress instance creates entirely new IDs for the imported elements.

When the WordPress ID changes as it does during an import, it means that any code you’ve written that references IDs will suddenly stop working because the ID you reference in your code is different after the import. Depending on the complexity of your forms, it can be very difficult to track down and correct these types of issues.

The only way to ensure that IDs remain the same between WordPress instances is by cloning the entire WordPress database from one instance to another as you might do as a developer utilizing development, staging, and production environments for a migration path. But if you work as a freelancer or run an agency, cloning may not work for you if you develop in your environment and staging and production are in your client’s environment.

Keys created by Formidable will not change across Formidable installations. They are transferred “as is”. The odds of finding a duplicate key in another Formidable installation that is not a clone is astronomical.

At their base calculation, Formidable’s default keys are generated from random numbers that range from 37 to 36^{^5} or 60,466,176. The ken gen calculation is lot more complex than that, but with the method used to generate Formidable’s keys, you have a better chance of being struck by lightning than Formidable has of colliding with a duplicate key during an import.

When you reference Formidable’s elements by their key and not their ID, you'll spare yourself from future headaches if you ever export Formidable forms from one WordPress instance and import them into another. Referencing by key is THE KEY to writing transportable code.