Source Folder

Files in the source folder handle the creation and execution of form actions. The configuration for the actions are handled within, calling helper functions from the shared folder to take those configurations and register the actions with Ninja Forms. As part of the registration, the files within this folder also provide the processors that receive the submission data and prepare it for processing. On this side of things, the processor structures the submission data as needed by the CiviCRMSDK package, which would then make the requests to CiviCRM.

Master Factory

The Master Factory constructs the primary objects used by the plugin including the CreateContact action, the submission metabox entries, data access, and DB connectivity objects.

It has a public method to set a bypass function. This bypass is used when the CiviCRM plugin is not activated to mock CiviCRM funtionality, enabling one to work with the Ninja Forms plugin when CiviCRM is not available.

NinjaForms\CiviCrm\Processors\CreateChainedContact

This class is a Form Action Processor, extending an abstract that handles common functionality (see the Shared folders docs for explanation of that). Its child responsibilities include finalizing the action settings and processing the submission data.

When you read through this class, and the MasterFactory that instantiates it in the constructCreateContactActionConfiguration() method, you'll note that much of the work is done using configuration files. Thus should you need to adjust anything in the action, start with that configuration file, as it defines much of what is in the action.

Finalizing the action settings, done in method finalizeActionSettings() gives it the opportunity to modify the configured action settings at run time. This class uses the opportunity to pull in live data from CiviCRM to populate drop down settings with CiviCRM values. Follow the protected methods inside finalizeActionSettings() to see what is modified.

Output of the action UI in the builder can be controlled by templates. Look in the configuration files for the specific action setting you wish, and look for a tmpl_row key-value. If that key-value is set for the setting, then the output is controlled by that file withing the src\Templates folder. If no key-value is specified, then it is handled by the default NF core template. If you have a need to modify the styling of an action setting, start with the template file; if you need to change the underlying data structure, use the action configuration file.

Contact Matching

Contacts have the option to be matched, or 'DeDuped' in Civi lingo so that, instead of creating a new contact, the matched contact can be updated. Form creators are presented with pre-existing 'DedupeRuleGroups' and they can opt to use one of those DeDupe groups, or to not use any, which would then always create a new contact.

Currently, only deduping by email is possible. The process() method first checks to see if a dedupe rule has been selected. If it has, then it constructs an array of the contact data and adds an email key with the first email being mapped in the submission. If a match is returned, then this matched contact Id is used for downstream options. When matched, then certain processors, like email and address, are skipped to prevent adding duplicates of those associated with the matched contact. Other processors, like activities, will still process as they will add a new activity to the matched contact.