Skip to main content

Drupal Form Element Reference

Drupal Form Element Reference

Drupal core provides a couple dozen different input #type elements that can be added to forms.

This includes one for every standard HTML5 input element, and some Drupal-specific ones that encapsulate more complex interactions like uploading files.

But how can you know what elements exist?

Where do you find information about what Render API properties each element uses?

Of course that drupal org has all information, but since I'm already developing drupal and this site, I thinking that bringing here all relevant information and links can help me and other on the daily drupal tasks needed for development.

This reference include main elements for drupal 7,8 and 9 and will be updated from time to time with examples from real programming tasks and according to readers comments.

 

 

Render Elements

One of the central components of the Render API is render elements. You can think of them as prepackaged render arrays: shortcuts you can use to describe common things -- like tables, links, and form elements -- in a consistent way. In this tutorial we'll take a more in-depth look at the use of the #type property in render arrays in order to answer questions like:

  • What are render elements, and what is their use case?
  • Where can I find more information about available element types?

By the end of this tutorial you should be able to identify individual render element types within a larger render array, find the relevant documentation for specific types of render elements, and explain the use case for render elements.

 

Form API

Drupal's Form API is an abstraction layer around standard HTML forms and HTTP form handling. It controls the life cycle of a form including form definition, display, validation, and processing. It provides helper utilities to make it easier for module developers to make use of HTTP POST data, sanitize user input, and encapsulate complex widgets into reusable components.

Any time you write code in a Drupal module or theme that creates or interacts with a form you'll use the Form API to do so.

Introduced in Drupal 4.7, conceptually, the current version of the Form API remains largely the same, though it's gotten both more capable and more complex over time as well as moving to a more object-oriented approach.

In Drupal 8, each form starts its life as a class that implements \Drupal\Core\Form\FormInterface. This class is often referred to as the form controller.

A form controller provides an initial definition of the form via its buildForm() method and validation and submission handling via its validateForm() and submitForm() methods, respectively.

Additional modules can alter the base form definition through a series of form alter hooks (hook_form_alter).

Through hooks, modules can add new elements, modify existing ones, and insert additional handling logic for validation and submission.

Life cycle orchestration is handled by the \Drupal\Core\Form\FormBuilder service. In addition, various base classes such as \Drupal\Core\Form\FormBase provide convenient starting points for creating custom forms.

read more at drupalize - Form API Overview

 

Element Types

We listed here all of the form element types provided by Drupal core and linked to the documentation for each.

We also looked at the list of properties that are available for all form elements regardless of type. View the documentation for each individual element type to see documentation of type-specific properties.

List of form element types:

 

Form elements explained

The buildForm(array $form, FormStateInterface $form_state) method of a form controller returns an associative array, usually named $form, that defines the markup and input elements your form is composed of. Each element in the array consists of a set of properties, and possible nested child elements, that define the details Drupal uses to generate the HTML version of the form.

 

Example:

$form['phone_number'] = array( '#type' => 'tel', '#title' => $this->t('Example phone'), '#default_value' => '867-5309', );

These arrays are known as render arrays, and it's a good idea to be familiar with their structure, and the related terminology.

Render arrays that define a form can make use of all standard Render API RenderElement types, as well as the Form API-specific FormElement types. The latter are used primarily to define input and control elements on a form. These are used for the #type key of elements in a $form array, and also dictate which additional properties can be used for that element.

In addition to the set of default properties available for all RenderElement elements, FormElement elements all have the following properties, as well as element-type-specific properties.

 

Abstract class FormElement

  • #after_build: (array) Array of callables or function names, which are called after the element is built. Arguments: $element, $form_state.
  • #ajax: (array) Array of elements to specify Ajax behavior. See the Ajax API topic for more information.
  • #array_parents: (string[], read-only) Array of names of all the element's parents (including itself) in the render array. See also #parents, #tree.
  • #default_value: Default value for the element. See also #value.
  • #description: (string) Help or description text for the element. In an ideal user interface, the #title should be enough to describe the element, so most elements should not have a description; if you do need one, make sure it is translated. If it is not already wrapped in a safe markup object, it will be filtered for XSS safety.
  • #disabled: (bool) If TRUE, the element is shown but does not accept user input.
  • #element_validate: (array) Array of callables or function names, which are called to validate the input. Arguments: $element, $form_state, $form.
  • #field_prefix: (string) Prefix to display before the HTML input element. Should be translated, normally. If it is not already wrapped in a safe markup object, will be filtered for XSS safety.
  • #field_suffix: (string) Suffix to display after the HTML input element. Should be translated, normally. If it is not already wrapped in a safe markup object, will be filtered for XSS safety.
  • #input: (bool, internal) Whether or not the element accepts input.
  • #parents: (string[], read-only) Array of names of the element's parents for purposes of getting values out of $form_state. See also #array_parents, #tree.
  • #process: (array) Array of callables or function names, which are called during form building. Arguments: $element, $form_state, $form.
  • #processed: (bool, internal) Set to TRUE when the element is processed.
  • #required: (bool) Whether or not input is required on the element.
  • #states: (array) Information about JavaScript states, such as when to hide or show the element based on input on other elements. See drupal_process_states() for documentation.
  • #title: (string) Title of the form element. Should be translated.
  • #title_display: (string) Where and how to display the #title. Possible values:
    • before: Label goes before the element (default for most elements).
    • after: Label goes after the element (default for radio elements).
    • invisible: Label is there but is made invisible using CSS.
    • attribute: Make it the title attribute (hover tooltip).
  • #tree: (bool) TRUE if the values of this element and its children should be hierarchical in $form_state; FALSE if the values should be flat. See also #parents, #array_parents.
  • #value_callback: (callable) Callable or function name, which is called to transform the raw user input to the element's value. Arguments: $element, $input, $form_state.

 

You can find a complete list of the render element types provided by Drupal core at https://api.drupal.org/api/drupal/elements. Pay special attention to FormElement types, and note that you can click through to the class that defines the element type for additional documentation on element type specific properties and in most cases a usage example.

 

read more at Drupal org - Form and render elements

Form Interface

FormInterface provides the interface for the form implementation

When programming your own Form don't forget to add implementation to this 4 abstract functions: