function hook_views_data in Zircon Profile 8.0

Same name and namespace in other branches

8 core/modules/views/views.api.php \hook_views_data()

Describe data tables and fields (or the equivalent) to Views.

The table and fields are processed in Views using various plugins. See the Views plugins topic for more information.

To provide views data for an entity, instead of implementing this hook, create a class implementing \Drupal\views\EntityViewsDataInterface and reference this in the "views" annotation in the entity class. The return value of the getViewsData() method on the interface is the same as this hook. See the Entity API topic for more information about entities.

The data described with this hook is fetched and retrieved by \Drupal\views\Views::viewsData()->get().

Return value

array An associative array describing the structure of database tables and fields (and their equivalents) provided for use in Views. At the outermost level, the keys are the names used internally by Views for the tables (usually the actual table name). Each table's array describes the table itself, how to join to other tables, and the fields that are part of the table. The sample function body provides documentation of the details.

File

core/modules/views/views.api.php, line 131: Describes hooks and plugins provided by the Views module.

Code

function hook_views_data() {

  // This example describes how to write hook_views_data() for a table defined
  // like this:
  // CREATE TABLE example_table (
  //   nid INT(11) NOT NULL         COMMENT 'Primary key: {node}.nid.',
  //   plain_text_field VARCHAR(32) COMMENT 'Just a plain text field.',
  //   numeric_field INT(11)        COMMENT 'Just a numeric field.',
  //   boolean_field INT(1)         COMMENT 'Just an on/off field.',
  //   timestamp_field INT(8)       COMMENT 'Just a timestamp field.',
  //   PRIMARY KEY(nid)
  // );
  // Define the return array.
  $data = array();

  // The outermost keys of $data are Views table names, which should usually
  // be the same as the hook_schema() table names.
  $data['example_table'] = array();

  // The value corresponding to key 'table' gives properties of the table
  // itself.
  $data['example_table']['table'] = array();

  // Within 'table', the value of 'group' (translated string) is used as a
  // prefix in Views UI for this table's fields, filters, etc. When adding
  // a field, filter, etc. you can also filter by the group.
  $data['example_table']['table']['group'] = t('Example table');

  // Within 'table', the value of 'provider' is the module that provides schema
  // or the entity type that causes the table to exist. Setting this ensures
  // that views have the correct dependencies. This is automatically set to the
  // module that implements hook_views_data().
  $data['example_table']['table']['provider'] = 'example_module';

  // Some tables are "base" tables, meaning that they can be the base tables
  // for views. Non-base tables can only be brought in via relationships in
  // views based on other tables. To define a table to be a base table, add
  // key 'base' to the 'table' array:
  $data['example_table']['table']['base'] = array(
    // Identifier (primary) field in this table for Views.
    'field' => 'nid',
    // Label in the UI.
    'title' => t('Example table'),
    // Longer description in the UI. Required.
    'help' => t('Example table contains example content and can be related to nodes.'),
    'weight' => -10,
  );

  // Some tables have an implicit, automatic relationship to other tables,
  // meaning that when the other table is available in a view (either as the
  // base table or through a relationship), this table's fields, filters, etc.
  // are automatically made available without having to add an additional
  // relationship. To define an implicit relationship that will make your
  // table automatically available when another table is present, add a 'join'
  // section to your 'table' section. Note that it is usually only a good idea
  // to do this for one-to-one joins, because otherwise your automatic join
  // will add more rows to the view. It is also not a good idea to do this if
  // most views won't need your table -- if that is the case, define a
  // relationship instead (see the field section below).
  //
  // If you've decided an automatic join is a good idea, here's how to do it:
  $data['example_table']['table']['join'] = array(
    // Within the 'join' section, list one or more tables to automatically
    // join to. In this example, every time 'node' is available in a view,
    // 'example_table' will be too. The array keys here are the array keys
    // for the other tables, given in their hook_views_data() implementations.
    // If the table listed here is from another module's hook_views_data()
    // implementation, make sure your module depends on that other module.
    'node_field_data' => array(
      // Primary key field in node to use in the join.
      'left_field' => 'nid',
      // Foreign key field in example_table to use in the join.
      'field' => 'nid',
      // An array of extra conditions on the join.
      'extra' => array(
        0 => array(
          // Adds AND node.published = TRUE to the join.
          'field' => 'published',
          'value' => TRUE,
        ),
        1 => array(
          // Adds AND example_table.numeric_field = 1 to the join.
          'left_field' => 'numeric_field',
          'value' => 1,
          // If true, the value will not be surrounded in quotes.
          'numeric' => TRUE,
        ),
        2 => array(
          // Adds AND example_table.boolean_field <> node.published to the join.
          'field' => 'published',
          'left_field' => 'boolean_field',
          // The operator used, Defaults to "=".
          'operator' => '!=',
        ),
      ),
    ),
  );

  // Other array elements at the top level of your table's array describe
  // individual database table fields made available to Views. The array keys
  // are the names (unique within the table) used by Views for the fields,
  // usually equal to the database field names.
  //
  // Each field entry must have the following elements:
  // - title: Translated label for the field in the UI.
  // - help: Description of the field in the UI.
  //
  // Each field entry may also have one or more of the following elements,
  // describing "handlers" (plugins) for the field:
  // - relationship: Specifies a handler that allows this field to be used
  //   to define a relationship to another table in Views.
  // - field: Specifies a handler to make it available to Views as a field.
  // - filter: Specifies a handler to make it available to Views as a filter.
  // - sort: Specifies a handler to make it available to Views as a sort.
  // - argument: Specifies a handler to make it available to Views as an
  //   argument, or contextual filter as it is known in the UI.
  // - area: Specifies a handler to make it available to Views to add content
  //   to the header, footer, or as no result behavior.
  //
  // Note that when specifying handlers, you must give the handler plugin ID
  // and you may also specify overrides for various settings that make up the
  // plugin definition. See examples below; the Boolean example demonstrates
  // setting overrides.
  // Node ID field, exposed as relationship only, since it is a foreign key
  // in this table.
  $data['example_table']['nid'] = array(
    'title' => t('Example content'),
    'help' => t('Relate example content to the node content'),
    // Define a relationship to the node table, so views whose base table is
    // example_table can add a relationship to the node table. To make a
    // relationship in the other direction, you can:
    // - Use hook_views_data_alter() -- see the function body example on that
    //   hook for details.
    // - Use the implicit join method described above.
    'relationship' => array(
      // Views name of the table to join to for the relationship.
      'base' => 'node',
      // Database field name in the other table to join on.
      'base field' => 'nid',
      // ID of relationship handler plugin to use.
      'id' => 'standard',
      // Default label for relationship in the UI.
      'label' => t('Example node'),
    ),
  );

  // Plain text field, exposed as a field, sort, filter, and argument.
  $data['example_table']['plain_text_field'] = array(
    'title' => t('Plain text field'),
    'help' => t('Just a plain text field.'),
    'field' => array(
      // ID of field handler plugin to use.
      'id' => 'standard',
    ),
    'sort' => array(
      // ID of sort handler plugin to use.
      'id' => 'standard',
    ),
    'filter' => array(
      // ID of filter handler plugin to use.
      'id' => 'string',
    ),
    'argument' => array(
      // ID of argument handler plugin to use.
      'id' => 'string',
    ),
  );

  // Numeric field, exposed as a field, sort, filter, and argument.
  $data['example_table']['numeric_field'] = array(
    'title' => t('Numeric field'),
    'help' => t('Just a numeric field.'),
    'field' => array(
      // ID of field handler plugin to use.
      'id' => 'numeric',
    ),
    'sort' => array(
      // ID of sort handler plugin to use.
      'id' => 'standard',
    ),
    'filter' => array(
      // ID of filter handler plugin to use.
      'id' => 'numeric',
    ),
    'argument' => array(
      // ID of argument handler plugin to use.
      'id' => 'numeric',
    ),
  );

  // Boolean field, exposed as a field, sort, and filter. The filter section
  // illustrates overriding various settings.
  $data['example_table']['boolean_field'] = array(
    'title' => t('Boolean field'),
    'help' => t('Just an on/off field.'),
    'field' => array(
      // ID of field handler plugin to use.
      'id' => 'boolean',
    ),
    'sort' => array(
      // ID of sort handler plugin to use.
      'id' => 'standard',
    ),
    'filter' => array(
      // ID of filter handler plugin to use.
      'id' => 'boolean',
      // Override the generic field title, so that the filter uses a different
      // label in the UI.
      'label' => t('Published'),
      // Override the default BooleanOperator filter handler's 'type' setting,
      // to display this as a "Yes/No" filter instead of a "True/False" filter.
      'type' => 'yes-no',
      // Override the default Boolean filter handler's 'use_equal' setting, to
      // make the query use 'boolean_field = 1' instead of 'boolean_field <> 0'.
      'use_equal' => TRUE,
    ),
  );

  // Integer timestamp field, exposed as a field, sort, and filter.
  $data['example_table']['timestamp_field'] = array(
    'title' => t('Timestamp field'),
    'help' => t('Just a timestamp field.'),
    'field' => array(
      // ID of field handler plugin to use.
      'id' => 'date',
    ),
    'sort' => array(
      // ID of sort handler plugin to use.
      'id' => 'date',
    ),
    'filter' => array(
      // ID of filter handler plugin to use.
      'id' => 'date',
    ),
  );

  // Area example. Areas are not generally associated with actual data
  // tables and fields. This example is from views_views_data(), which defines
  // the "Global" table (not really a table, but a group of Fields, Filters,
  // etc. that are grouped into section "Global" in the UI). Here's the
  // definition of the generic "Text area":
  $data['views']['area'] = array(
    'title' => t('Text area'),
    'help' => t('Provide markup text for the area.'),
    'area' => array(
      // ID of the area handler plugin to use.
      'id' => 'text',
    ),
  );
  return $data;
}

You are here

function hook_views_data in Zircon Profile 8.0

Return value

See also

Related topics

File

Code

API Navigation