Getting NYU onto YAML Form

Why Does NYU Need Forms?

NYU Nursing needed a way to to collect registration information for their events. There were a handful of “event types” (such as “Prospective Students,” “Current Students,” and “Information Session”) and each type had specific information needs. Occasionally, however, individual events would need to collect additional–or not as much–information as the “base” form for that event type.

Since faculty members would be creating these events, NYU Nursing needed a way to programmatically attach registration forms to each event posted to the site. They wanted the forms to use the fields of the “base” form by default, but also have the flexibility to add/remove fields for specific instances.

Form Functionality

Forms for NYU Nursing needed to be able to:

• collect various types of information, like:
  • text
  • email
  • phone
  • address
  • date
  • file attachments
  • incorporate more advanced input fields like a Likert scale
• conditionally show/hide fields based on the responses to other fields
• duplicate a form to use as a starting point for another
• create multi-step forms
• send submissions to one or more email addresses, customizable per-form
• allow per-form access control
• view the submissions on the site
• download results to CSV and Excel files

In Drupal 7, the go-to form builder was Webform. Since that doesn’t (and likely never will) exist for Drupal 8, we had to find an alternative.

The options we explored were Drupal 8’s built-in Contact Form and the Contact Storage module, eForm (the successor to Drupal 7’s Entityform module), and YAML Form.

Contact Form with Contact Storage

We could have used Drupal 8’s built-in Contact Form and the Contact Storage module, but the functionality simply didn’t match the requirement. It’s great for contact forms, and basic information gathering, but it didn’t support form duplication, multi-step forms, per-form access control, and would have required that we give all faculty permission to create and edit forms across the site, even ones they didn’t create or have any reason to modify.

eForm

Much of the functionality of Entityform from Drupal 7 was ported to Contact Forms in Drupal 8 Core, so there’s actually not a lot of benefit to using eForm. It does provide some advanced features like customizing the recipient email, displaying the forms as nodes, and downloadable results. With the introduction of YAML Forms in Drupal 8, however, the maintainer of eForm himself asked if eForm is even needed any longer. That, along with the statement on the project page that the maintainer doesn’t have time to maintain development, sent us packing pretty quick.

YAML Form

This is where I could get all gushy about YAML Form and why it was the obvious winner. Instead I’ll list some of the features and functionality, and then explain how we used it to meet NYU Nursing’s requirements.

First off, the project page gives this as the primary use-case of YAML Form:

• build a new form or duplicate an existing template
• publish the form as a page, node, or block
• collect submissions
• send confirmations and notifications
• review submissions online
• download submissions as a CSV

All of that is pretty standard for web form functionality. But here are some of the more advanced features (details can be found on yamlform.io):

• duplication of existing forms, templates, and elements
• custom messages and button labels
• pre-populate form elements using query string parameters
• entity references field
• Likert scale field
• star rating field
• conditional logic
• input masks
• source view (you can view – and edit! – the form as YAML… in the UI!)
• multistep Forms
• reusable templates

Why YAML Form

YAML Form ticked all the boxes of the requirements, and even brought additional functionality to the table. Being able to edit the form in Source View means tweaks can be made in seconds instead of the minutes it takes to click through the interface. YAML Form was written for Drupal 8, so it integrates tightly with Configuration Management (each form is a configuration entity). And the UI was so straightforward, the clients fell in love.

Wrap-Up

The one requirement that we didn’t get out-of-the-box was the ability to programmatically create a new form based on a “base” form that could then be customized with additional/fewer fields. We also needed a way to prevent configuration management from overwriting/deleting those forms when we ran drush config-import. Those were both handled by some custom code that we’re hoping to release into the wild so that others can benefit as well.

In the end, the requirements were fulfilled, and very little custom work had to be done to get the features and functionality we needed out of YAML Form. I can highly recommend it to anyone that needs to collect information through forms on their Drupal 8 site.