Club Drupal

  // This one is used as the base to reduce errors when updating.

  // Map extra Views tables to the entity that holds its date fields, needed

  // for Views tables other than the primary tables identified in entity_info().

 * Helper function to map entity types to the Views base table they use.

 *

 * Used to make it easier to infer the entity type from a base table.

 * Views has a new handler called views_handler_field_entity() that loads

 * entities.

 * And you can use something like the following to get the entity type from a

 * view, but not all our base tables contain the entity information we need,

 * (i.e. revisions).

 * So it won't work here and we resort to creating information from

 * entity_get_info().

    // Then we let other modules tell us about other entity tables that hold

    // date fields.

  // All modules that create custom fields that use the

  // 'views_handler_field_date' handler can provide additional information here

  // about the type of date they create so the date can be used by the Date API

  // views date argument and date filter.

 * A version of date_real_url that formats links correctly for the Date pager.

  // If someone adds a pager without a matching argument, there is not date

  // information to work with.

  // The View arguments array is indexed numerically but is not necessarily in

  // numerical order. Sort the arguments to ensure the correct order.

  // If there are empty arguments before the date argument, pad them with the

  // wildcard so the date argument will be in the right position.

  // Is this an embedded or a block view? Return the pager query value.

  if (!$force_view_url &&

      (!empty($view->preview) || !empty($view->date_info->block_identifier))) {

  // Normal views may need querystrings appended to them if they use exposed

  // filters.

  // Create a Views field for each date column we care about to supplement the

  // generic 'entity_id' and 'revision_id' fields that are automatically

  // created. Also use friendlier labels to distinguish the start date and end

  // date in listings (for fields that use both).

          // Not sure yet if we still need a custom field handler in D7 now

          // that custom formatters are available. Might still need it to

          // handle grouping of multiple value dates.

 * Implements hook_form_FORM_ID_alter() for views_exposed_form().

 */

function date_views_form_views_exposed_form_alter(&$form, &$form_state, $form_id) {

  $children = element_children($form);

  // @todo On a stock views_exposed_form, there won't be any grandchildren

  // items, but will this always be the case? How about better_exposed_filters?

  foreach ($children as $child) {

    if (isset($form[$child]['#id']) && strpos($form[$child]['#id'], 'date_views_exposed_filter-') === 0) {

      // Remove empty or scalar date input when an array was expected.

      if (empty($form_state['input'][$child]) || !is_array($form_state['input'][$child])) {

        unset($form_state['input'][$child]);

      }

      elseif (empty($form_state['input'][$child]['value']) || !is_array($form_state['input'][$child]['value'])) {

        unset($form_state['input'][$child]['value']);

      }

    }

  }

}

/**

 * Work out if the plugin is a date.

 * The instanceof function makes this work for any handler that was derived from

 * 'views_handler_filter_date' or 'views_handler_argument_date', which includes

 * core date fields like the node updated field.

 *

 * The test for $handler->min_date tells us that this is an argument that not

 * only is derived from the views date handler but also has been processed by

 * the Date Views filter or argument code.

 * This is to ensure the the user completes all parts of the date not just some

 * parts. Only needed for the select widget.

  // If we are displaying a date from a view, see if we have information about

  // which multiple value to display. If so, set the date_id in the entity.