The Drupal forms API is a powerful leap forward. It also allows for almost unlimited possibilities for custom theming, validation, and execution of forms. Even better, ANY form (even those in core) can be altered in almost any way imaginable--elements can be removed, added, and rearranged. This page is certainly not a comprehensive guide to this functionality, but should provide a good working foundation with which to do the most basic form creation, theming, validation, and execution. For programming details on form elements and their properties, please see the Forms API Reference.
Form elements are now declared in array fashion, with the hierarchical structure of the form elements themselves as array elements (which can be nested), and each form elements properties/attributes listed as array elements in key/value pairs--the key being the name of the property/attribute, and the value being the value of the property/attribute. For example, here's how to go about constructing a textfield form element:
<?php
$form['foo'] = array(
'#type' => 'textfield',
'#title' => t('bar'),
'#default_value' => $object['foo'],
'#size' => 60,
'#maxlength' => 64,
'#description' => t('baz'),
);
?>
and a submit button:
<?php
$form['submit'] = array(
'#type' => 'submit',
'#value' => t('Save'),
);
?>
a few things to note:
name
property is declared in the $form
array, at the very end of the array tree. For example, if an element in the form tree was structured like this: <?php
$form['account_settings']['username']
?>
$form_state['values']
, in your validation and submission functions, as the form code flattens the array in this fashion before it passes the key/value pairs. NOTE: if you wish to have the full tree structure passed to $form_state['values']
, this is possible, and will be discussed later.'#type'
property.'#value'
attribute for any form elements that can be changed by the user. Use the '#default_value'
attribute instead. Don't put values from $form_state['values']
(or $_POST
) here! FormsAPI will deal with that for you; only put the original value of the field here.One great advantages of this system is that the explicitly named keys make deciphering the form element much easier.
Let's take a look at a working piece of code using the API:
<?php
function test_form($form_state) {
// Access log settings:
$options = array('1' => t('Enabled'), '0' => t('Disabled'));
$form['access'] = array(
'#type' => 'fieldset',
'#title' => t('Access log settings'),
'#tree' => TRUE,
);
$form['access']['log'] = array(
'#type' => 'radios',
'#title' => t('Log'),
'#default_value' => variable_get('log', 0),
'#options' => $options,
'#description' => t('The log.'),
);
$period = drupal_map_assoc(array(3600, 10800, 21600, 32400, 43200, 86400, 172800, 259200, 604800, 1209600, 2419200, 4838400, 9676800), 'format_interval');
$form['access']['timer'] = array(
'#type' => 'select',
'#title' => t('Discard logs older than'),
'#default_value' => variable_get('timer', 259200),
'#options' => $period,
'#description' => t('The timer.'),
);
// Description
$form['details'] = array(
'#type' => 'fieldset',
'#title' => t('Details'),
'#collapsible' => TRUE,
'#collapsed' => TRUE,
);
$form['details']['description'] = array(
'#type' => 'textarea',
'#title' => t('Describe it'),
'#default_value' => variable_get('description', ''),
'#cols' => 60,
'#rows' => 5,
'#description' => t('Log description.'),
);
$form['details']['admin'] = array(
'#type' => 'checkbox',
'#title' => t('Only admin can view'),
'#default_value' => variable_get('admin', 0),
);
$form['name'] = array(
'#type' => 'textfield',
'#title' => t('Name'),
'#size' => 30,
'#maxlength' => 64,
'#description' => t('Enter the name for this group of settings'),
);
$form['hidden'] = array('#type' => 'value', '#value' => 'is_it_here');
$form['submit'] = array('#type' => 'submit', '#value' => t('Save'));
return $form;
}
function test_page() {
return drupal_get_form('test_form');
}
?>
This example demonstrates how form elements can be built in a hierarchical fashion by expanding and layering the form array. There are two functions involved - the function that builds the form, and another that renders the form using drupal_get_form()
. Note that the form builder function always takes $form_state
as its first argument, though for basic usage (as here) it is not used. Also note that the test_page() function that renders the form is returning the rendered HTML output, which is what you would need to do if test_page() is the page callback from a hook_menu() implementation, for example.
Notice that the first layer is made up of two form groups, 'access', and 'details', and that inside each of these groups, one layer down, are some individual form elements. Order of construction is important here, as the form building code will default to the constructed order of the $form
array when it builds the form (this can be overridden, and will be discussed later in the custom theming section).
For form groups, the '#type'
parameter is set to 'fieldset'
, and notice how the 'details'
form group is made into a collapsed form group with the addition of a few attributes.
All groups/elements are been built into the master $form
array by the builder function.
The drupal_get_form
function is the "key" function in the Forms API. Note that in its basic usage, it takes just one argument, a string which
is both the form ID and also the name of the function that builds the $form
array. Because the form ID is generally also the name of a function, it must be a valid PHP variable name. It should start with a letter or underscore, followed by any number of letters, numbers, or underscores; spaces and hyphens are not allowed. drupal_get_form
can take optional additional arguments, which will be simply passed on to the $form
builder function.
drupal_get_form
does the following:
$form
from the builder function$form['name']
items into actual form elementsFor more detailed information, also see the API page for drupal_get_form()
An important thing to note: notice that $form['access']
has a '#tree' => TRUE
attribute. this setting retains the full tree structure for all elements under it when it is passed to $form_state['values']
. you must explicitly declare this anywhere you wish to retain an array's full hierarchy when it is passed.
The API makes custom theming of all forms (including those found in core) possible. This custom theming becomes possible when all hard coded theming elements have been abstracted, so that they can be overridden at time of form generation. The abstraction is accomplished using one of the following methods:
'#theme'
attributes to the form and/or elements. This allows you to specify which theme function will be used to render the form or elements, overriding the default theming function.'#prefix'
and '#suffix'
attributes, and these will place the declared markup either before or after the form element in question. for example:
<?php
$form['access'] = array(
'#type' => 'fieldset',
'#title' => t('Access log settings'),
'#prefix' => '<div class="foo">',
'#suffix' => '</div>',
);
?>
...will place the div tags before and after the entire form group (meaning the form elements of the group will also be enclosed in the div). if you were to put those attributes in one of the form elements inside that form group, then they would only wrap that particular element, etc.
'#markup'
type which you can place anywhere in the form, and its value will be output directly in its specified location in the forms hierarchy when the form is rendered. example: <?php
$form['div_tag'] = array('#type' => 'markup', '#value' => '<div class="foo">');
?>
This markup form element can then be accessed/altered through its name in the array, 'div_tag'
NOTE: it's not necessary to explicitly declare the type as markup, since type will default to markup if none is declared.
drupal_get_form
--in which case the third arg of drupal_get_form
will be a string containing the name of the callback function which the form building code will call, and the theming function will be theme_ prepended to the name of the callback.
example:
For our above form, we could create a custom theming function as follows:
<?php
function theme_test_form($form) {
$output = '';
$output .= drupal_render($form['name']);
$output .= '<div class="foo">';
$output .= drupal_render($form['access']);
$output .= '<div class="bar">';
$output .= drupal_render($form['details']);
$output .= '</div></div>';
$output .= drupal_render($form);
return $output;
}
?>
A few things to note:
drupal_render
functiondrupal_render
and pass it an array of elements (as in a fieldset), it will render all the elements in the passed array, in the order in which they were built in the form array.drupal_render
for any element in the place where you would like it to be rendered. In the above example, this was done with $form['name']
.drupal_render
is called for the entire form array at the very end of the theming function, but it will only render the remaining unrendered element, which in this case is the submit button. calling drupal_render($form)
is a common way to end a theming function, as it will then render any submit buttons and/or hidden fields that have been declared in the form in a single call.The form API has general form validation which it performs on all submitted forms. If there is additional validation you wish to perform on a submitted form, you can create a validation function. the name of the validation function is the form ID with _validate appended to it. the function has two args: $form
and $form_state
. $form
is the form array of the executed form, and $form_state['values']
contains the form values which you may perform validation on. (Note - in more advanced usage, several forms may share a _validate or _submit function - so if the form's ID is needed, it can be retrieved from $form['form_id']['#value']
, or $form_state['values']['form_id']
.)
Here's an example validation function for our example code:
<?php
function test_form_validate($form, &$form_state) {
if ($form_state['values']['name'] == '') {
form_set_error('', t('You must select a name for this group of settings.'));
}
}
?>
The normal method of submitting forms with the API is through the use of a form submit function. This has the same naming convention and arguments as the validation function, except _submit is appended instead. Any forms which are submitted from a button of type => 'submit'
will be passed to their corresponding submit function if it is available.
example:
<?php
function test_form_submit($form, &$form_state) {
db_query("INSERT INTO {table} (name, log, hidden) VALUES ('%s', %d, '%s')", $form_state['values']['name'], $form_state['values']['access']['log'], $form_state['values']['hidden']);
drupal_set_message(t('Your form has been saved.'));
}
?>
a few things to note:
$form_state['values']
array will not usually have the same hierarchical structure as the constructed $form
array (due to the flattening discussed previously), so be aware of what arrays have been flattened, and what arrays have retained their hierarchy by use of the tree => TRUE
attribute. notice above that 'statistics_enable_access_log' belongs to a tree'd array, and the full array structure must be used to access the value.$form_state['values']
can be declared in the $form
array as such: <?php
$form['foo'] = array('#type' => 'value', '#value' => 'bar')
?>
This is accessed in $form_state['values']['foo']
, with a value of bar. This method is preferred because the values are not sent to the browser.
$form_state['redirect']
which will be the target of a drupal_goto; every form is redirected after a submit. If you store nothing in $form_state['redirect']
, the form will simply be redirected to itself after a submit. It is polite to use drupal_set_message()
to explain to the user that the submission was successful.
An important concept with Forms API compared to using raw HTML forms (as in Drupal 4.6 and before) is that the drupal_get_form()
function handles both presenting and responding to the form. What this means is that the $form array you construct in your function will be built first when the form is presented, and again when the form is submitted.
The practical upshot to this is that many developers immediately find themselves asking the question of "where does my data get stored?". The answer is simply that it doesn't. You put your $form data together, perhaps loading your object from the database and filling in #default_values, the form builder then checks this against what was posted. What you gain from this, however, is that the FormsAPI can deal with your data securely. Faking a POST is much harder since it won't let values that weren't actually on the form come through to the $form_state['values'] in your submit function, and in your 'select' types, it will check to ensure that the value actually existed in the select and reject the form if it was not. In addition, Drupal adds, by default, a security token to each form that will protect against cross-site forgery.