<?php

 /**

 * @file

 * Functions for form and batch generation and processing.

 */

/**

 * @defgroup forms Form builder functions

 * @{

 * Functions that build an abstract representation of a HTML form.

 *

 * All modules should declare their form builder functions to be in this

 * group and each builder function should reference its validate and submit

 * functions using \@see. Conversely, validate and submit functions should

 * reference the form builder function using \@see. For examples, of this see

 * system_modules_uninstall() or user_pass(), the latter of which has the

 * following in its doxygen documentation:

 * - \@ingroup forms

 * - \@see user_pass_validate()

 * - \@see user_pass_submit()

 *

 * @}

 */

/**

 * @defgroup form_api Form generation

 * @{

 * Functions to enable the processing and display of HTML forms.

 *

 * Drupal uses these functions to achieve consistency in its form processing and

 * presentation, while simplifying code and reducing the amount of HTML that

 * must be explicitly generated by modules.

 *

 * The primary function used with forms is drupal_get_form(), which is

 * used for forms presented interactively to a user. Forms can also be built and

 * submitted programmatically without any user input using the

 * drupal_form_submit() function.

 *

 * drupal_get_form() handles retrieving, processing, and displaying a rendered

 * HTML form for modules automatically.

 *

 * Here is an example of how to use drupal_get_form() and a form builder

 * function:

 * @code

 * $form = drupal_get_form('my_module_example_form');

 * ...

 * function my_module_example_form($form, &$form_state) {

 *   $form['submit'] = array(

 *     '#type' => 'submit',

 *     '#value' => t('Submit'),

 *   );

 *   return $form;

 * }

 * function my_module_example_form_validate($form, &$form_state) {

 *   // Validation logic.

 * }

 * function my_module_example_form_submit($form, &$form_state) {

 *   // Submission logic.

 * }

 * @endcode

 *

 * Or with any number of additional arguments:

 * @code

 * $extra = "extra";

 * $form = drupal_get_form('my_module_example_form', $extra);

 * ...

 * function my_module_example_form($form, &$form_state, $extra) {

 *   $form['submit'] = array(

 *     '#type' => 'submit',

 *     '#value' => $extra,

 *   );

 *   return $form;

 * }

 * @endcode

 *

 * The $form argument to form-related functions is a structured array containing

 * the elements and properties of the form. For information on the array

 * components and format, and more detailed explanations of the Form API

 * workflow, see the

 * @link forms_api_reference.html Form API reference @endlink

 * and the

 * @link http://drupal.org/node/37775 Form API documentation section. @endlink

 * In addition, there is a set of Form API tutorials in

 * @link form_example_tutorial.inc the Form Example Tutorial @endlink which

 * provide basics all the way up through multistep forms.

 *

 * In the form builder, validation, submission, and other form functions,

 * $form_state is the primary influence on the processing of the form and is

 * passed by reference to most functions, so they use it to communicate with

 * the form system and each other.

 *

 * See drupal_build_form() for documentation of $form_state keys.

 */

/**

 * Returns a renderable form array for a given form ID.

 *

 * This function should be used instead of drupal_build_form() when $form_state

 * is not needed (i.e., when initially rendering the form) and is often

 * used as a menu callback.

 *

 * @param $form_id

 *   The unique string identifying the desired form. If a function with that

 *   name exists, it is called to build the form array. Modules that need to

 *   generate the same form (or very similar forms) using different $form_ids

 *   can implement hook_forms(), which maps different $form_id values to the

 *   proper form constructor function. Examples may be found in node_forms(),

 *   and search_forms(). hook_forms() can also be used to define forms in

 *   classes.

 * @param ...

 *   Any additional arguments are passed on to the functions called by

 *   drupal_get_form(), including the unique form constructor function. For

 *   example, the node_edit form requires that a node object is passed in here

 *   when it is called. These are available to implementations of

 *   hook_form_alter() and hook_form_FORM_ID_alter() as the array

 *   $form_state['build_info']['args'].

 *

 * @return

 *   The form array.

 *

 * @see drupal_build_form()

 */

function drupal_get_form($form_id) {

  $form_state = array();

  $args = func_get_args();

  // Remove $form_id from the arguments.

  array_shift($args);

  $form_state['build_info']['args'] = $args;

  return drupal_build_form($form_id, $form_state);

}

/**

 * Builds and process a form based on a form id.

 *

 * The form may also be retrieved from the cache if the form was built in a

 * previous page-load. The form is then passed on for processing, validation

 * and submission if there is proper input.

 *

 * @param $form_id

 *   The unique string identifying the desired form. If a function with that

 *   name exists, it is called to build the form array. Modules that need to

 *   generate the same form (or very similar forms) using different $form_ids

 *   can implement hook_forms(), which maps different $form_id values to the

 *   proper form constructor function. Examples may be found in node_forms(),

 *   and search_forms().

 * @param $form_state

 *   An array which stores information about the form. This is passed as a

 *   reference so that the caller can use it to examine what in the form changed

 *   when the form submission process is complete. Furthermore, it may be used

 *   to store information related to the processed data in the form, which will

 *   persist across page requests when the 'cache' or 'rebuild' flag is set.

 *   The following parameters may be set in $form_state to affect how the form

 *   is rendered:

 *   - build_info: Internal. An associative array of information stored by Form

 *     API that is necessary to build and rebuild the form from cache when the

 *     original context may no longer be available:

 *     - args: A list of arguments to pass to the form constructor.

 *     - files: An optional array defining include files that need to be loaded

 *       for building the form. Each array entry may be the path to a file or

 *       another array containing values for the parameters 'type', 'module' and

 *       'name' as needed by module_load_include(). The files listed here are

 *       automatically loaded by form_get_cache(). By default the current menu

 *       router item's 'file' definition is added, if any. Use

 *       form_load_include() to add include files from a form constructor.

 *     - form_id: Identification of the primary form being constructed and

 *       processed.

 *     - base_form_id: Identification for a base form, as declared in a

 *       hook_forms() implementation.

 *     - immutable: If this flag is set to TRUE, a new form build id is

 *       generated when the form is loaded from the cache. If it is subsequently

 *       saved to the cache again, it will have another cache id and therefore

 *       the original form and form-state will remain unaltered. This is

 *       important when page caching is enabled in order to prevent form state

 *       from leaking between anonymous users.

 *   - rebuild_info: Internal. Similar to 'build_info', but pertaining to

 *     drupal_rebuild_form().

 *   - rebuild: Normally, after the entire form processing is completed and

 *     submit handlers have run, a form is considered to be done and

 *     drupal_redirect_form() will redirect the user to a new page using a GET

 *     request (so a browser refresh does not re-submit the form). However, if

 *     'rebuild' has been set to TRUE, then a new copy of the form is

 *     immediately built and sent to the browser, instead of a redirect. This is

 *     used for multi-step forms, such as wizards and confirmation forms.

 *     Normally, $form_state['rebuild'] is set by a submit handler, since it is

 *     usually logic within a submit handler that determines whether a form is

 *     done or requires another step. However, a validation handler may already

 *     set $form_state['rebuild'] to cause the form processing to bypass submit

 *     handlers and rebuild the form instead, even if there are no validation

 *     errors.

 *   - redirect: Used to redirect the form on submission. It may either be a

 *     string containing the destination URL, or an array of arguments

 *     compatible with drupal_goto(). See drupal_redirect_form() for complete

 *     information.

 *   - no_redirect: If set to TRUE the form will NOT perform a drupal_goto(),

 *     even if 'redirect' is set.

 *   - method: The HTTP form method to use for finding the input for this form.

 *     May be 'post' or 'get'. Defaults to 'post'. Note that 'get' method

 *     forms do not use form ids so are always considered to be submitted, which

 *     can have unexpected effects. The 'get' method should only be used on

 *     forms that do not change data, as that is exclusively the domain of

 *     'post.'

 *   - cache: If set to TRUE the original, unprocessed form structure will be

 *     cached, which allows the entire form to be rebuilt from cache. A typical

 *     form workflow involves two page requests; first, a form is built and

 *     rendered for the user to fill in. Then, the user fills the form in and

 *     submits it, triggering a second page request in which the form must be

 *     built and processed. By default, $form and $form_state are built from

 *     scratch during each of these page requests. Often, it is necessary or

 *     desired to persist the $form and $form_state variables from the initial

 *     page request to the one that processes the submission. 'cache' can be set

 *     to TRUE to do this. A prominent example is an Ajax-enabled form, in which

 *     ajax_process_form() enables form caching for all forms that include an

 *     element with the #ajax property. (The Ajax handler has no way to build

 *     the form itself, so must rely on the cached version.) Note that the

 *     persistence of $form and $form_state happens automatically for

 *     (multi-step) forms having the 'rebuild' flag set, regardless of the value

 *     for 'cache'.

 *   - no_cache: If set to TRUE the form will NOT be cached, even if 'cache' is

 *     set.

 *   - values: An associative array of values submitted to the form. The

 *     validation functions and submit functions use this array for nearly all

 *     their decision making. (Note that #tree determines whether the values are

 *     a flat array or an array whose structure parallels the $form array. See

 *     @link forms_api_reference.html Form API reference @endlink for more

 *     information.) These are raw and unvalidated, so should not be used

 *     without a thorough understanding of security implications. In almost all

 *     cases, code should use the data in the 'values' array exclusively. The

 *     most common use of this key is for multi-step forms that need to clear

 *     some of the user input when setting 'rebuild'. The values correspond to

 *     $_POST or $_GET, depending on the 'method' chosen.

 *   - always_process: If TRUE and the method is GET, a form_id is not

 *     necessary. This should only be used on RESTful GET forms that do NOT

 *     write data, as this could lead to security issues. It is useful so that

 *     searches do not need to have a form_id in their query arguments to

 *     trigger the search.

 *   - must_validate: Ordinarily, a form is only validated once, but there are

 *     times when a form is resubmitted internally and should be validated

 *     again. Setting this to TRUE will force that to happen. This is most

 *     likely to occur during Ajax operations.

 *   - programmed: If TRUE, the form was submitted programmatically, usually

 *     invoked via drupal_form_submit(). Defaults to FALSE.

 *   - programmed_bypass_access_check: If TRUE, programmatic form submissions

 *     are processed without taking #access into account. Set this to FALSE

 *     when submitting a form programmatically with values that may have been

 *     input by the user executing the current request; this will cause #access

 *     to be respected as it would on a normal form submission. Defaults to

 *     TRUE.

 *   - process_input: Boolean flag. TRUE signifies correct form submission.

 *     This is always TRUE for programmed forms coming from drupal_form_submit()

 *     (see 'programmed' key), or if the form_id coming from the $_POST data is

 *     set and matches the current form_id.

 *   - submitted: If TRUE, the form has been submitted. Defaults to FALSE.

 *   - executed: If TRUE, the form was submitted and has been processed and

 *     executed. Defaults to FALSE.

 *   - triggering_element: (read-only) The form element that triggered

 *     submission. This is the same as the deprecated

 *     $form_state['clicked_button']. It is the element that caused submission,

 *     which may or may not be a button (in the case of Ajax forms). This key is

 *     often used to distinguish between various buttons in a submit handler,

 *     and is also used in Ajax handlers.

 *   - clicked_button: Deprecated. Use triggering_element instead.

 *   - has_file_element: Internal. If TRUE, there is a file element and Form API

 *     will set the appropriate 'enctype' HTML attribute on the form.

 *   - groups: Internal. An array containing references to fieldsets to render

 *     them within vertical tabs.

 *   - storage: $form_state['storage'] is not a special key, and no specific

 *     support is provided for it in the Form API. By tradition it was

 *     the location where application-specific data was stored for communication

 *     between the submit, validation, and form builder functions, especially

 *     in a multi-step-style form. Form implementations may use any key(s)

 *     within $form_state (other than the keys listed here and other reserved

 *     ones used by Form API internals) for this kind of storage. The

 *     recommended way to ensure that the chosen key doesn't conflict with ones

 *     used by the Form API or other modules is to use the module name as the

 *     key name or a prefix for the key name. For example, the Node module uses

 *     $form_state['node'] in node editing forms to store information about the

 *     node being edited, and this information stays available across successive

 *     clicks of the "Preview" button as well as when the "Save" button is

 *     finally clicked.

 *   - buttons: A list containing copies of all submit and button elements in

 *     the form.

 *   - complete form: A reference to the $form variable containing the complete

 *     form structure. #process, #after_build, #element_validate, and other

 *     handlers being invoked on a form element may use this reference to access

 *     other information in the form the element is contained in.

 *   - temporary: An array holding temporary data accessible during the current

 *     page request only. All $form_state properties that are not reserved keys

 *     (see form_state_keys_no_cache()) persist throughout a multistep form

 *     sequence. Form API provides this key for modules to communicate

 *     information across form-related functions during a single page request.

 *     It may be used to temporarily save data that does not need to or should

 *     not be cached during the whole form workflow; e.g., data that needs to be

 *     accessed during the current form build process only. There is no use-case

 *     for this functionality in Drupal core.

 *   - wrapper_callback: Modules that wish to pre-populate certain forms with

 *     common elements, such as back/next/save buttons in multi-step form

 *     wizards, may define a form builder function name that returns a form

 *     structure, which is passed on to the actual form builder function.

 *     Such implementations may either define the 'wrapper_callback' via

 *     hook_forms() or have to invoke drupal_build_form() (instead of

 *     drupal_get_form()) on their own in a custom menu callback to prepare

 *     $form_state accordingly.

 *   Information on how certain $form_state properties control redirection

 *   behavior after form submission may be found in drupal_redirect_form().

 *

 * @return

 *   The rendered form. This function may also perform a redirect and hence may

 *   not return at all, depending upon the $form_state flags that were set.

 *

 * @see drupal_redirect_form()

 */

function drupal_build_form($form_id, &$form_state) {

  // Ensure some defaults; if already set they will not be overridden.

  $form_state += form_state_defaults();

  if (!isset($form_state['input'])) {

    $form_state['input'] = $form_state['method'] == 'get' ? $_GET : $_POST;

  }

  if (isset($_SESSION['batch_form_state'])) {

    // We've been redirected here after a batch processing. The form has

    // already been processed, but needs to be rebuilt. See _batch_finished().

    $form_state = $_SESSION['batch_form_state'];

    unset($_SESSION['batch_form_state']);

    return drupal_rebuild_form($form_id, $form_state);

  }

  // If the incoming input contains a form_build_id, we'll check the cache for a

  // copy of the form in question. If it's there, we don't have to rebuild the

  // form to proceed. In addition, if there is stored form_state data from a

  // previous step, we'll retrieve it so it can be passed on to the form

  // processing code.

  $check_cache = isset($form_state['input']['form_id']) && $form_state['input']['form_id'] == $form_id && !empty($form_state['input']['form_build_id']);

  if ($check_cache) {

    $form = form_get_cache($form_state['input']['form_build_id'], $form_state);

  }

  // If the previous bit of code didn't result in a populated $form object, we

  // are hitting the form for the first time and we need to build it from

  // scratch.

  if (!isset($form)) {

    // If we attempted to serve the form from cache, uncacheable $form_state

    // keys need to be removed after retrieving and preparing the form, except

    // any that were already set prior to retrieving the form.

    if ($check_cache) {

      $form_state_before_retrieval = $form_state;

    }

    $form = drupal_retrieve_form($form_id, $form_state);

    drupal_prepare_form($form_id, $form, $form_state);

    // form_set_cache() removes uncacheable $form_state keys defined in

    // form_state_keys_no_cache() in order for multi-step forms to work

    // properly. This means that form processing logic for single-step forms

    // using $form_state['cache'] may depend on data stored in those keys

    // during drupal_retrieve_form()/drupal_prepare_form(), but form

    // processing should not depend on whether the form is cached or not, so

    // $form_state is adjusted to match what it would be after a

    // form_set_cache()/form_get_cache() sequence. These exceptions are

    // allowed to survive here:

    // - always_process: Does not make sense in conjunction with form caching

    //   in the first place, since passing form_build_id as a GET parameter is

    //   not desired.

    // - temporary: Any assigned data is expected to survives within the same

    //   page request.

    if ($check_cache) {

      $uncacheable_keys = array_flip(array_diff(form_state_keys_no_cache(), array('always_process', 'temporary')));

      $form_state = array_diff_key($form_state, $uncacheable_keys);

      $form_state += $form_state_before_retrieval;

    }

  }

  // Now that we have a constructed form, process it. This is where:

  // - Element #process functions get called to further refine $form.

  // - User input, if any, gets incorporated in the #value property of the

  //   corresponding elements and into $form_state['values'].

  // - Validation and submission handlers are called.

  // - If this submission is part of a multistep workflow, the form is rebuilt

  //   to contain the information of the next step.

  // - If necessary, the form and form state are cached or re-cached, so that

  //   appropriate information persists to the next page request.

  // All of the handlers in the pipeline receive $form_state by reference and

  // can use it to know or update information about the state of the form.

  drupal_process_form($form_id, $form, $form_state);

  // If this was a successful submission of a single-step form or the last step

  // of a multi-step form, then drupal_process_form() issued a redirect to

  // another page, or back to this page, but as a new request. Therefore, if

  // we're here, it means that this is either a form being viewed initially

  // before any user input, or there was a validation error requiring the form

  // to be re-displayed, or we're in a multi-step workflow and need to display

  // the form's next step. In any case, we have what we need in $form, and can

  // return it for rendering.

  return $form;

}

/**

 * Retrieves default values for the $form_state array.

 */

function form_state_defaults() {

  return array(

    'rebuild' => FALSE,

    'rebuild_info' => array(),

    'redirect' => NULL,

    // @todo 'args' is usually set, so no other default 'build_info' keys are

    //   appended via += form_state_defaults().

    'build_info' => array(

      'args' => array(),

      'files' => array(),

    ),

    'temporary' => array(),

    'submitted' => FALSE,

    'executed' => FALSE,

    'programmed' => FALSE,

    'programmed_bypass_access_check' => TRUE,

    'cache'=> FALSE,

    'method' => 'post',

    'groups' => array(),

    'buttons' => array(),

  );

}

/**

 * Constructs a new $form from the information in $form_state.

 *

 * This is the key function for making multi-step forms advance from step to

 * step. It is called by drupal_process_form() when all user input processing,

 * including calling validation and submission handlers, for the request is

 * finished. If a validate or submit handler set $form_state['rebuild'] to TRUE,

 * and if other conditions don't preempt a rebuild from happening, then this

 * function is called to generate a new $form, the next step in the form

 * workflow, to be returned for rendering.

 *

 * Ajax form submissions are almost always multi-step workflows, so that is one

 * common use-case during which form rebuilding occurs. See ajax_form_callback()

 * for more information about creating Ajax-enabled forms.

 *

 * @param $form_id

 *   The unique string identifying the desired form. If a function

 *   with that name exists, it is called to build the form array.

 *   Modules that need to generate the same form (or very similar forms)

 *   using different $form_ids can implement hook_forms(), which maps

 *   different $form_id values to the proper form constructor function. Examples

 *   may be found in node_forms() and search_forms().

 * @param $form_state

 *   A keyed array containing the current state of the form.

 * @param $old_form

 *   (optional) A previously built $form. Used to retain the #build_id and

 *   #action properties in Ajax callbacks and similar partial form rebuilds. The

 *   only properties copied from $old_form are the ones which both exist in

 *   $old_form and for which $form_state['rebuild_info']['copy'][PROPERTY] is

 *   TRUE. If $old_form is not passed, the entire $form is rebuilt freshly.

 *   'rebuild_info' needs to be a separate top-level property next to

 *   'build_info', since the contained data must not be cached.

 *

 * @return

 *   The newly built form.

 *

 * @see drupal_process_form()

 * @see ajax_form_callback()

 */

function drupal_rebuild_form($form_id, &$form_state, $old_form = NULL) {

  $form = drupal_retrieve_form($form_id, $form_state);

  // If only parts of the form will be returned to the browser (e.g., Ajax or

  // RIA clients), or if the form already had a new build ID regenerated when it

  // was retrieved from the form cache, reuse the existing #build_id.

  // Otherwise, a new #build_id is generated, to not clobber the previous

  // build's data in the form cache; also allowing the user to go back to an

  // earlier build, make changes, and re-submit.

  // @see drupal_prepare_form()

  $enforce_old_build_id = isset($old_form['#build_id']) && !empty($form_state['rebuild_info']['copy']['#build_id']);

  $old_form_is_mutable_copy = isset($old_form['#build_id_old']);

  if ($enforce_old_build_id || $old_form_is_mutable_copy) {

    $form['#build_id'] = $old_form['#build_id'];

    if ($old_form_is_mutable_copy) {

      $form['#build_id_old'] = $old_form['#build_id_old'];

    }

  }

  else {

    if (isset($old_form['#build_id'])) {

      $form['#build_id_old'] = $old_form['#build_id'];

    }

    $form['#build_id'] = 'form-' . drupal_random_key();

  }

  // #action defaults to request_uri(), but in case of Ajax and other partial

  // rebuilds, the form is submitted to an alternate URL, and the original

  // #action needs to be retained.

  if (isset($old_form['#action']) && !empty($form_state['rebuild_info']['copy']['#action'])) {

    $form['#action'] = $old_form['#action'];

  }

  drupal_prepare_form($form_id, $form, $form_state);

  // Caching is normally done in drupal_process_form(), but what needs to be

  // cached is the $form structure before it passes through form_builder(),

  // so we need to do it here.

  // @todo For Drupal 8, find a way to avoid this code duplication.

  if (empty($form_state['no_cache'])) {

    form_set_cache($form['#build_id'], $form, $form_state);

  }

  // Clear out all group associations as these might be different when

  // re-rendering the form.

  $form_state['groups'] = array();

  // Return a fully built form that is ready for rendering.

  return form_builder($form_id, $form, $form_state);

}

/**

 * Fetches a form from cache.

 */

function form_get_cache($form_build_id, &$form_state) {

  if ($cached = cache_get('form_' . $form_build_id, 'cache_form')) {

    $form = $cached->data;

    global $user;

    if ((isset($form['#cache_token']) && drupal_valid_token($form['#cache_token'])) || (!isset($form['#cache_token']) && !$user->uid)) {

      if ($cached = cache_get('form_state_' . $form_build_id, 'cache_form')) {

        // Re-populate $form_state for subsequent rebuilds.

        $form_state = $cached->data + $form_state;

        // If the original form is contained in include files, load the files.

        // @see form_load_include()

        $form_state['build_info'] += array('files' => array());