Use FrmEntry::create() with Dynamic Fields

Back Story

There's a little bit of a back story here. This article is the result of a post in the Formidable Masterminds Facebook group by Jeremy Knauff of Spartan Media in Tampa, Florida.

Jeremy and I have a long time relationship. In fact, back in the day, he was a client I once helped with the Genesis Framework and early Formidable Forms projects. Over the years, our relationship evolved from the vendor/client type into a true friendship.

If you read the Facebook post, it was the first time Jeremy has ever tagged me to ask for my help directly in a public forum like that. Normally, we'd just pick up the phone and call each other or Zoom, but last week was different. My wife and I were vacationing and celebrating our 32nd anniversary. I did no business at all and never even turned on my laptop once. I am not sorry I took off, but rather, am deeply proud of myself for focusing my attention where it rightfully belongs.

The project referenced in the post is one I am deeply familiar with. It is a future SAAS application built with Formidable Pro that I collaborate on from time to time wearing my software engineer cap.

Jeremy is an excellent developer in his own right. I only help if there's an engineering issue he's stuck on figuring out with Formidable. We chat regularly but rarely does he have a programming issue where he may need my help. I knew this was an issue that needed another set of eyes.

As developers, we know all too well that if you can't find an answer to a sticky wicket in the available documentation, you'll have to figure it out yourself by reading and testing the source code in a development environment. Sometimes, it's the only way to get a deeper understanding of how things work, such as execution flows and variables.

I'm sure you'll agree, there's not a lot of the advanced developer level documentation available for Formidable that someone may need to reference to solve a problem.

Don't get me wrong, the KnowledgeBase documentation and video tutorials are great. The Formidable YouTube channel is awesome. "Mike" is a gentle, comforting teacher that gives easy to understand instructions.

All too often though, the KnowledgeBase code examples are sometimes just wrong, too simplistic to solve a hard problem, or too old to include modern updates like dynamic fields in their examples.

There is much available to developers in Formidable that remains undocumented. Look at the Codex V2 statistics to understand what I mean.

Remember the Difference

Quite some time ago, I encouraged Jeremy to use Formidable's Dynamic fields instead of Lookup fields because of their incredible flexibility for displaying data when creating views and pick lists.

This suggestion is the catalyst that triggered the issue we're discussing today. Jeremy knew exactly what he wanted to accomplish and found code examples in the KnowledgeBase for FrmEntry::create(), but the code does not completely work because the example doesn't account for using Dynamic fields in the targeted entry.

Before we proceed further, do you know the difference between Dynamic and Lookup fields?

If not, please read this KnowlegeBase article: Dynamic vs. Lookup Fields. Without understanding the difference, the solution may be difficult to grasp.

Single Source of Truth

We advocate for Dynamic fields because they fit well within the Single Source of Truth (SSOT) information architecture.

Use Case

Following the SSOT principle, the system's enrollment form uses key data elements as a source for dynamic lookup fields used in multiple additional forms. Each of these forms sources at least one of its lookup field's select options from this single source of truth captured in the enrollment form. Other single sources of truth included well defined lookup tables, such as current phase status for example.

To streamline user interactions, the system prepopulates several subsequent forms with the lookup values originating in the enrollment form and lookup tables. The code executes in a custom callback assigned to the frm_after_create_entry action.

Since all of these subsequent forms contain dynamic lookup fields, any entries made in these forms programmatically must pass the lookup value's item_id from Formidable's frm_item_metas table to the dynamic lookup field. Reference: Formidable Database Schema

The Function Missing from FrmEntryMeta

Formidable has over 8,000 functions and over 1,000 WordPress hooks we can access as developers. The vast majority of these are undocumented.

Both WordPress and Formidable use a metadata database architecture. This means that each field on your form stores its value as a single row in the frm_item_metas table. The related basic entry header record is in frm_items. All other data occupies its own metadata row.

The FrmEntryMeta class has 14 public functions. You can find examples of a few of them in the KnowledgeBase, but not all. The methods in this class require knowing the field id and entry id in order to return a value. There are no functions that can return a metadata entry_id based on its stored value. In my opinion, in the age of Dynamic fields, that is an oversight and one that we've rectified with masterminds_get_dynamic_field_entry_id_by_value().

The Solution

Here's the code that provided the solution to creating entries where you need to populate dynamic fields with lookup entry ids.