Tutorial – Overview

Form Field Requirements:

v0.1.1: The basic premise of Custom Form/CRM is, like many other contact forms, that a form will generally contain two important fields: name and email. Since there is no HTML name field type, a text field must be used. This module expects that this field will have a “Field Name” of name. The Label and Help text can be used to suggest to the form user that a full name is required or at least appreciated. You may use a second text field to capture a last name if need be, but that will not be captured in the Address Book in CRM. You may edit the Address Book, however, and modify the name entry.

NEW IN v0.2.0: in the latest version of this module, several changes have been made in regard to the above. Though the basic premise hasn’t changed, there are less strict guidelines with the fields mentioned. A “name” field is not required in order to record adequately in the CRM or fill the header in the notification email. A default value will be calculated by the module. Also, in place of a single “name” field, you may now employ text fields and assign “firstname” and “lastname” as Field Names that will be captured and used in the CRM and email header.

NEW IN v0.3.2: notifications are now optional. You may now rely solely on the CRM to collect form submissions and then retrieve them manually.

v0.1.1: Given that there IS an HTML email field type, this module expects that an “Email Address” field type will be used as selected from the field list. Form submission will fail without error should a text field be used.

NEW IN v0.2.0: an “Email Address” field type is no longer required for form submission. If used, however, there must be a valid email address input into this field. If you need a field to capture a voluntary email address, you may use a simple “text” field but it will not be recorded in the CRM or validated. For the CRM, a default email address will be calculated if an “Email Address” field is not used.

NEW IN v0.3.x: you may now specify a FROM name and email address when required by your email provider.

v0.1.1: A third field that will augment the two just mentioned will be Subject ( Field Name: subject ). These three will form the Header of the Inbound Message recorded in the CRM. A subject field is NOT required, however. The module will insert default subject text.

NEW IN v0.2.0: for subject text in both the CRM and email notifications, a new control has been added to the module settings for the admin to set the default subject text.

When using the “Select Recipient” field type ( “Front End Email Selection” in General Settings ), the Field Name must be “emaillist”.

Enhancements:

NEW IN v0.2.1:

“Masking” has been added as an option for Text Fields. This allows the designer to format and restrict input. This may be particularly useful for input like phone numbers, zip or mailing codes, etc., i.e. (999) 999-9999 could be used for a US telephone number. The form user’s keystrokes would be restricted to where the digits lie in the mask. Alpha and alpha-numeric entry is restricted by “a” or “*” respectively.

NEW IN v0.2.2:

Localization was added for validation error messages. This is based on the target site’s locale as set in Admin->Settings->Site Language.

NEW IN v0.3.x:

A new module has been introduced which will supersede the previous (Custom Form2/CRM). This new module adds:

reCaptcha option to captcha choice
date format and date range options for date field type
multi-part(multi-page) form capability
conditional fields

NEW IN v0.3.1:

Localization has been added to date fields via DatePicker

NEW IN v0.3.2:

custom select drop-down field to complex form (import formatted txt files containing options)
toggle for send notifications to complex form (if desired, toggle off notifications of form submissions and retrieve from CRM manually)
left labels toggle to complex form (control placement of labels either above or to left of input)
SMTP phpmailer module settings to complex form (use your email provider’s SMTP exchange instead of simple PHP mail)