drupal/core/modules/field/field.module

548 lines
22 KiB
Plaintext
Raw Normal View History

<?php
/**
* @file
* Attach custom data fields to Drupal entities.
*/
use Drupal\Component\Utility\Html;
use Drupal\Component\Utility\Xss;
use Drupal\Core\Entity\ContentEntityInterface;
use Drupal\Core\Entity\EntityTypeInterface;
use Drupal\Core\Template\Attribute;
use Drupal\entity\Entity\EntityViewDisplay;
use Drupal\field\Field;
/*
* Load all public Field API functions. Drupal currently has no
* mechanism for auto-loading core APIs, so we have to load them on
* every page request.
*/
require_once __DIR__ . '/field.info.inc';
require_once __DIR__ . '/field.attach.inc';
require_once __DIR__ . '/field.form.inc';
require_once __DIR__ . '/field.purge.inc';
require_once __DIR__ . '/field.deprecated.inc';
/**
* @defgroup field Field API
* @{
* Attaches custom data fields to Drupal entities.
*
* The Field API allows custom data fields to be attached to Drupal entities and
* takes care of storing, loading, editing, and rendering field data. Any entity
* type (node, user, etc.) can use the Field API to make itself "fieldable" and
* thus allow fields to be attached to it. Other modules can provide a user
* interface for managing custom fields via a web browser as well as a wide and
* flexible variety of data type, form element, and display format capabilities.
*
* The Field API defines two primary data structures, Field and Instance, and
* the concept of a Bundle. A Field defines a particular type of data that can
* be attached to entities. A Field Instance is a Field attached to a single
* Bundle. A Bundle is a set of fields that are treated as a group by the Field
* Attach API and is related to a single fieldable entity type.
*
* For example, suppose a site administrator wants Article nodes to have a
* subtitle and photo. Using the Field API or Field UI module, the administrator
* creates a field named 'subtitle' of type 'text' and a field named 'photo' of
* type 'image'. The administrator (again, via a UI) creates two Field
* Instances, one attaching the field 'subtitle' to the 'node' bundle 'article'
* and one attaching the field 'photo' to the 'node' bundle 'article'. When the
* node storage controller loads an Article node, it loads the values of the
* 'subtitle' and 'photo' fields because they are both attached to the 'node'
* bundle 'article'.
*
* - @link field_types Field Types API @endlink: Defines field types, widget
* types, and display formatters. Field modules use this API to provide field
* types like Text and Node Reference along with the associated form elements
* and display formatters.
*
* - @link field_crud Field CRUD API @endlink: Create, updates, and deletes
* fields, bundles (a.k.a. "content types"), and instances. Modules use this
* API, often in hook_install(), to create custom data structures.
*
* - @link field_attach Field Attach API @endlink: Connects entity types to the
* Field API. Field Attach API functions load, store, generate Form API
* structures, display, and perform a variety of other functions for field
* data connected to individual entities. Fieldable entity types like node and
* user use this API to make themselves fieldable.
*
* - @link field_info Field Info API @endlink: Exposes information about all
* fields, instances, widgets, and related information defined by or with the
* Field API.
*
* - @link field_purge Field API bulk data deletion @endlink: Cleans up after
* bulk deletion operations such as deletion of field or field_instance.
*
* - @link field_language Field language API @endlink: Provides native
* multilingual support for the Field API.
*/
/**
* Implements hook_help().
*/
function field_help($path, $arg) {
switch ($path) {
case 'admin/help#field':
$output = '';
$output .= '<h3>' . t('About') . '</h3>';
$output .= '<p>' . t('The Field module allows custom data fields to be defined for <em>entity</em> types (entities include content items, comments, user accounts, and taxonomy terms). The Field module takes care of storing, loading, editing, and rendering field data. Most users will not interact with the Field module directly, but will instead use the <a href="@field-ui-help">Field UI module</a> user interface. Module developers can use the Field API to make new entity types "fieldable" and thus allow fields to be attached to them. For more information, see the online handbook entry for <a href="@field">Field module</a>.', array('@field-ui-help' => url('admin/help/field_ui'), '@field' => 'http://drupal.org/documentation/modules/field')) . '</p>';
$output .= '<h3>' . t('Uses') . '</h3>';
$output .= '<dl>';
$output .= '<dt>' . t('Enabling field types') . '</dt>';
$output .= '<dd>' . t('The Field module provides the infrastructure for fields and field attachment; the field types and input widgets themselves are provided by additional modules. The modules can be enabled from the <a href="@modules">Modules administration page</a>. Drupal core includes the following field type modules: Text, Number, Email, Link, Telephone, Image, File, Options, Taxonomy, and Entity Reference. Additional fields and widgets may be provided by contributed modules, which you can find in the <a href="@contrib">contributed module section of Drupal.org</a>.', array('@modules' => url('admin/modules'), '@contrib' => 'http://drupal.org/project/modules', '@options' => url('admin/help/options')));
// Make a list of all widget and field modules currently enabled, ordered
// by displayed module name (module names are not translated).
$items = array();
$info = system_get_info('module');
$field_widgets = \Drupal::service('plugin.manager.field.widget')->getDefinitions();
$field_types = \Drupal::service('plugin.manager.field.field_type')->getConfigurableDefinitions();
$providers = array();
foreach (array_merge($field_types, $field_widgets) as $plugin) {
$providers[] = $plugin['provider'];
}
$providers = array_unique($providers);
sort($providers);
foreach ($providers as $provider) {
// Skip plugins provided by core components as they do not implement
// hook_help().
if (isset($info[$provider]['name'])) {
$display = $info[$provider]['name'];
if (\Drupal::moduleHandler()->implementsHook($provider, 'help')) {
$items[] = l($display, 'admin/help/' . $provider);
}
else {
$items[] = $display;
}
}
}
if ($items) {
$output .= ' ' . t('Currently enabled field and input widget modules:');
$item_list = array(
'#theme' => 'item_list',
'#items' => $items,
);
$output .= drupal_render($item_list);
}
return $output;
}
}
/**
* Implements hook_theme().
*/
function field_theme() {
return array(
'field' => array(
'render element' => 'element',
),
'field_multiple_value_form' => array(
'render element' => 'element',
),
);
}
/**
* Implements hook_cron().
*/
function field_cron() {
// Do a pass of purging on deleted Field API data, if any exists.
$limit = \Drupal::config('field.settings')->get('purge_batch_size');
field_purge_batch($limit);
}
/**
* Implements hook_system_info_alter().
*
* Goes through a list of all modules that provide a field type and makes them
* required if there are any active fields of that type.
*/
function field_system_info_alter(&$info, $file, $type) {
// It is not safe to call entity_load_multiple_by_properties() during
// maintenance mode.
if ($type == 'module' && !defined('MAINTENANCE_MODE')) {
$fields = entity_load_multiple_by_properties('field_config', array('module' => $file->name, 'include_deleted' => TRUE));
if ($fields) {
$info['required'] = TRUE;
// Provide an explanation message (only mention pending deletions if there
// remains no actual, non-deleted fields)
$non_deleted = FALSE;
foreach ($fields as $field) {
if (empty($field->deleted)) {
$non_deleted = TRUE;
break;
}
}
if ($non_deleted) {
if (\Drupal::moduleHandler()->moduleExists('field_ui')) {
$explanation = t('Field type(s) in use - see <a href="@fields-page">Field list</a>', array('@fields-page' => url('admin/reports/fields')));
}
else {
$explanation = t('Fields type(s) in use');
}
}
else {
$explanation = t('Fields pending deletion');
}
$info['explanation'] = $explanation;
}
}
}
/**
* Implements hook_entity_bundle_field_info().
*/
function field_entity_bundle_field_info(EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) {
if ($entity_type->isFieldable()) {
// Configurable fields, which are always attached to a specific bundle, are
// added 'by bundle'.
return Field::fieldInfo()->getBundleInstances($entity_type->id(), $bundle);
}
}
/**
* Implements hook_entity_bundle_create().
*/
function field_entity_bundle_create($entity_type, $bundle) {
// Clear the cache.
field_cache_clear();
}
/**
* Implements hook_entity_bundle_rename().
*/
function field_entity_bundle_rename($entity_type, $bundle_old, $bundle_new) {
$instances = entity_load_multiple_by_properties('field_instance_config', array('entity_type' => $entity_type, 'bundle' => $bundle_old));
foreach ($instances as $instance) {
if ($instance->entity_type == $entity_type && $instance->bundle == $bundle_old) {
$id_new = $instance->entity_type . '.' . $bundle_new . '.' . $instance->field_name;
$instance->id = $id_new;
$instance->bundle = $bundle_new;
$instance->allowBundleRename();
$instance->save();
}
}
// Clear the field cache.
field_cache_clear();
}
/**
* Implements hook_entity_bundle_delete().
*
* This deletes the data for the field instances as well as the field instances
* themselves. This function actually just marks the data and field instances as
* deleted, leaving the garbage collection for a separate process, because it is
* not always possible to delete this much data in a single page request
* (particularly since for some field types, the deletion is more than just a
* simple DELETE query).
*/
function field_entity_bundle_delete($entity_type, $bundle) {
// Get the instances on the bundle. entity_load_multiple_by_properties() must
// be used here since field_info_instances() does not return instances for
// disabled entity types or bundles.
$instances = entity_load_multiple_by_properties('field_instance_config', array('entity_type' => $entity_type, 'bundle' => $bundle));
foreach ($instances as $instance) {
$instance->delete();
}
// Clear the cache.
field_cache_clear();
}
/**
* Implements hook_rebuild().
*/
function field_rebuild() {
field_cache_clear();
}
/**
* Implements hook_modules_installed().
*/
function field_modules_installed($modules) {
field_cache_clear();
}
/**
* Implements hook_modules_uninstalled().
*/
function field_modules_uninstalled($modules) {
field_cache_clear();
}
/**
* Clears the field info and field data caches.
*/
function field_cache_clear() {
\Drupal::cache('field')->deleteAll();
field_info_cache_clear();
}
/**
* Filters an HTML string to prevent cross-site-scripting (XSS) vulnerabilities.
*
* Like filter_xss_admin(), but with a shorter list of allowed tags.
*
* Used for items entered by administrators, like field descriptions, allowed
* values, where some (mainly inline) mark-up may be desired (so
* drupal_htmlspecialchars() is not acceptable).
*
* @param $string
* The string with raw HTML in it.
*
* @return
* An XSS safe version of $string, or an empty string if $string is not valid
* UTF-8.
*/
function field_filter_xss($string) {
return Html::normalize(Xss::filter($string, _field_filter_xss_allowed_tags()));
}
/**
* Returns a list of tags allowed by field_filter_xss().
*/
function _field_filter_xss_allowed_tags() {
return array('a', 'b', 'big', 'code', 'del', 'em', 'i', 'ins', 'pre', 'q', 'small', 'span', 'strong', 'sub', 'sup', 'tt', 'ol', 'ul', 'li', 'p', 'br', 'img');
}
/**
* Returns a human-readable list of allowed tags for display in help texts.
*/
function _field_filter_xss_display_allowed_tags() {
return '<' . implode('> <', _field_filter_xss_allowed_tags()) . '>';
}
/**
* Implements hook_page_build().
*/
function field_page_build(&$page) {
$path = drupal_get_path('module', 'field');
$page['#attached']['css'][$path . '/css/field.module.css'] = array('every_page' => TRUE);
}
/**
* Implements hook_theme_suggestions_HOOK().
*/
function field_theme_suggestions_field(array $variables) {
$suggestions = array();
$element = $variables['element'];
$suggestions[] = 'field__' . $element['#field_type'];
$suggestions[] = 'field__' . $element['#field_name'];
$suggestions[] = 'field__' . $element['#entity_type'] . '__' . $element['#bundle'];
$suggestions[] = 'field__' . $element['#entity_type'] . '__' . $element['#field_name'];
$suggestions[] = 'field__' . $element['#entity_type'] . '__' . $element['#field_name'] . '__' . $element['#bundle'];
return $suggestions;
}
/**
* Prepares variables for field templates.
*
* Default template: field.html.twig.
*
* @param array $variables
* An associative array containing:
* - element: A render element representing the field.
* - attributes: A string containing the attributes for the wrapping div.
* - title_attributes: A string containing the attributes for the title.
* - content_attributes: A string containing the attributes for the content's
* div.
*/
function template_preprocess_field(&$variables, $hook) {
$element = $variables['element'];
// There's some overhead in calling check_plain() so only call it if the label
// variable is being displayed. Otherwise, set it to NULL to avoid PHP
// warnings if a theme implementation accesses the variable even when it's
// supposed to be hidden. If a theme implementation needs to print a hidden
// label, it needs to supply a preprocess function that sets it to the
// sanitized element title or whatever else is wanted in its place.
$variables['label_hidden'] = ($element['#label_display'] == 'hidden');
$variables['label'] = check_plain($element['#title']);
// We want other preprocess functions and the theme implementation to have
// fast access to the field item render arrays. The item render array keys
// (deltas) should always be numerically indexed starting from 0, and looping
// on those keys is faster than calling element_children() or looping on all
// keys within $element, since that requires traversal of all element
// properties.
$variables['items'] = array();
$delta = 0;
while (!empty($element[$delta])) {
$variables['items'][$delta] = $element[$delta];
$delta++;
}
// Add default CSS classes. Since there can be many fields rendered on a page,
// save some overhead by calling strtr() directly instead of
// drupal_html_class().
$variables['entity_type_css'] = strtr($element['#entity_type'], '_', '-');
$variables['field_name_css'] = strtr($element['#field_name'], '_', '-');
$variables['field_type_css'] = strtr($element['#field_type'], '_', '-');
$variables['attributes']['class'] = array(
'field',
'field-' . $variables['entity_type_css'] . '--' . $variables['field_name_css'],
'field-name-' . $variables['field_name_css'],
'field-type-' . $variables['field_type_css'],
'field-label-' . $element['#label_display'],
);
// Add a "clearfix" class to the wrapper since we float the label and the
// field items in field.module.css if the label is inline.
if ($element['#label_display'] == 'inline') {
$variables['attributes']['class'][] = 'clearfix';
}
static $default_attributes;
if (!isset($default_attributes)) {
$default_attributes = new Attribute;
}
// The default theme implementation for fields is a function.
// template_preprocess() (which initializes the attributes, title_attributes,
// and content_attributes arrays) does not run for theme function
// implementations. Additionally, Attribute objects for the three variables
// below only get instantiated for template file implementations, and we need
// Attribute objects for printing in both theme functions and template files.
// For best performance, we only instantiate Attribute objects when needed.
$variables['attributes'] = isset($variables['attributes']) ? new Attribute($variables['attributes']) : clone $default_attributes;
$variables['title_attributes'] = isset($variables['title_attributes']) ? new Attribute($variables['title_attributes']) : clone($default_attributes);
$variables['content_attributes'] = isset($variables['content_attributes']) ? new Attribute($variables['content_attributes']) : clone($default_attributes);
// Modules (e.g., rdf.module) can add field item attributes (to
// $item->_attributes) within hook_entity_prepare_view(). Some field
// formatters move those attributes into some nested formatter-specific
// element in order have them rendered on the desired HTML element (e.g., on
// the <a> element of a field item being rendered as a link). Other field
// formatters leave them within $element['#items'][$delta]['_attributes'] to
// be rendered on the item wrappers provided by theme_field().
foreach ($variables['items'] as $delta => $item) {
$variables['item_attributes'][$delta] = !empty($element['#items'][$delta]->_attributes) ? new Attribute($element['#items'][$delta]->_attributes) : clone($default_attributes);
}
}
/**
* @} End of "defgroup field".
*/
/**
* Returns HTML for a field.
*
* This is the default theme implementation to display the value of a field.
* Theme developers who are comfortable with overriding theme functions may do
* so in order to customize this markup. This function can be overridden with
* varying levels of specificity. For example, for a field named 'body'
* displayed on the 'article' content type, any of the following functions will
* override this default implementation. The first of these functions that
* exists is used:
* - THEMENAME_field__body__article()
* - THEMENAME_field__article()
* - THEMENAME_field__body()
* - THEMENAME_field()
*
* Theme developers who prefer to customize templates instead of overriding
* functions may copy the "field.html.twig" from the "modules/field/theme"
* folder of the Drupal installation to somewhere within the theme's folder and
* customize it, just like customizing other Drupal templates such as
* page.html.twig or node.html.twig. However, it takes longer for the server to
* process templates than to call a function, so for websites with many fields
* displayed on a page, this can result in a noticeable slowdown of the website.
* For these websites, developers are discouraged from placing a field.html.twig
* file into the theme's folder, but may customize templates for specific
* fields. For example, for a field named 'body' displayed on the 'article'
* content type, any of the following templates will override this default
* implementation. The first of these templates that exists is used:
* - field--body--article.html.twig
* - field--article.html.twig
* - field--body.html.twig
* - field.html.twig
* So, if the body field on the article content type needs customization, a
* field--body--article.html.twig file can be added within the theme's folder.
* Because it's a template, it will result in slightly more time needed to
* display that field, but it will not impact other fields, and therefore, is
* unlikely to cause a noticeable change in website performance. A very rough
* guideline is that if a page is being displayed with more than 100 fields and
* they are all themed with a template instead of a function, it can add up to
* 5% to the time it takes to display that page. This is a guideline only and
* the exact performance impact depends on the server configuration and the
* details of the website.
*
* @param array $variables
* An associative array containing:
* - label_hidden: A boolean indicating whether to show or hide the field
* label.
* - title_attributes: A string containing the attributes for the title.
* - label: The label for the field.
* - content_attributes: A string containing the attributes for the content's
* div.
* - items: An array of field items.
* - item_attributes: An array of attributes for each item.
* - classes: A string containing the classes for the wrapping div.
* - attributes: A string containing the attributes for the wrapping div.
*
* @see template_preprocess_field()
* @see field.html.twig
*
* @ingroup themeable
*/
function theme_field($variables) {
$output = '';
// Render the label, if it's not hidden.
if (!$variables['label_hidden']) {
$output .= '<div class="field-label"' . $variables['title_attributes'] . '>' . $variables['label'] . '</div>';
}
// Render the items.
$output .= '<div class="field-items"' . $variables['content_attributes'] . '>';
foreach ($variables['items'] as $delta => $item) {
$output .= '<div class="field-item"' . $variables['item_attributes'][$delta] . '>' . drupal_render($item, TRUE) . '</div>';
}
$output .= '</div>';
// Render the top-level DIV.
$output = '<div' . $variables['attributes'] . '>' . $output . '</div>';
return $output;
}
/**
* Assembles a partial entity structure with initial IDs.
*
* @param object $ids
* An object with the properties entity_type (required), entity_id (required),
* revision_id (optional) and bundle (optional).
*
* @return \Drupal\Core\Entity\EntityInterface
* An entity, initialized with the provided IDs.
*/
function _field_create_entity_from_ids($ids) {
$id_properties = array();
$entity_type = \Drupal::entityManager()->getDefinition($ids->entity_type);
if ($id_key = $entity_type->getKey('id')) {
$id_properties[$id_key] = $ids->entity_id;
}
if (isset($ids->revision_id) && $revision_key = $entity_type->getKey('revision')) {
$id_properties[$revision_key] = $ids->revision_id;
}
if (isset($ids->bundle) && $bundle_key = $entity_type->getKey('bundle')) {
$id_properties[$bundle_key] = $ids->bundle;
}
return entity_create($ids->entity_type, $id_properties);
}
/**
* Implements hook_hook_info().
*/
function field_hook_info() {
$hooks['field_views_data'] = array(
'group' => 'views',
);
$hooks['field_views_data_alter'] = array(
'group' => 'views',
);
return $hooks;
}