Drupal 8  8.0.2
Hooks
Collaboration diagram for Hooks:

Modules

 Field Types API
 

Functions

 hook_cron ()
 
 hook_data_type_info_alter (&$data_types)
 
 hook_queue_info_alter (&$queues)
 
 hook_mail_alter (&$message)
 
 hook_mail_backend_info_alter (&$info)
 
 hook_countries_alter (&$countries)
 
 hook_display_variant_plugin_alter (array &$definitions)
 
 hook_cache_flush ()
 
 hook_rebuild ()
 
 hook_config_import_steps_alter (&$sync_steps,\Drupal\Core\Config\ConfigImporter $config_importer)
 
 hook_config_schema_info_alter (&$definitions)
 
 hook_validation_constraint_alter (array &$definitions)
 
 hook_entity_view_mode_info_alter (&$view_modes)
 
 hook_entity_bundle_info ()
 
 hook_entity_bundle_info_alter (&$bundles)
 
 hook_entity_bundle_create ($entity_type_id, $bundle)
 
 hook_entity_storage_load (array $entities, $entity_type)
 
 hook_ENTITY_TYPE_storage_load (array $entities)
 
 hook_entity_query_alter (\Drupal\Core\Entity\Query\QueryInterface $query)
 
 hook_entity_base_field_info (\Drupal\Core\Entity\EntityTypeInterface $entity_type)
 
 hook_entity_base_field_info_alter (&$fields,\Drupal\Core\Entity\EntityTypeInterface $entity_type)
 
 hook_entity_bundle_field_info (\Drupal\Core\Entity\EntityTypeInterface $entity_type, $bundle, array $base_field_definitions)
 
 hook_entity_bundle_field_info_alter (&$fields,\Drupal\Core\Entity\EntityTypeInterface $entity_type, $bundle)
 
 hook_entity_field_storage_info (\Drupal\Core\Entity\EntityTypeInterface $entity_type)
 
 hook_entity_field_storage_info_alter (&$fields,\Drupal\Core\Entity\EntityTypeInterface $entity_type)
 
 hook_entity_operation (\Drupal\Core\Entity\EntityInterface $entity)
 
 hook_entity_operation_alter (array &$operations,\Drupal\Core\Entity\EntityInterface $entity)
 
 hook_entity_field_access ($operation,\Drupal\Core\Field\FieldDefinitionInterface $field_definition,\Drupal\Core\Session\AccountInterface $account,\Drupal\Core\Field\FieldItemListInterface $items=NULL)
 
 hook_entity_extra_field_info ()
 
 hook_entity_extra_field_info_alter (&$info)
 
 hook_hook_info ()
 
 hook_module_implements_alter (&$implementations, $hook)
 
 hook_system_info_alter (array &$info,\Drupal\Core\Extension\Extension $file, $type)
 
 hook_module_preinstall ($module)
 
 hook_modules_installed ($modules)
 
 hook_install ()
 
 hook_module_preuninstall ($module)
 
 hook_modules_uninstalled ($modules)
 
 hook_uninstall ()
 
 hook_install_tasks (&$install_state)
 
 hook_install_tasks_alter (&$tasks, $install_state)
 
 hook_requirements ($phase)
 
 hook_file_download ($uri)
 
 hook_file_url_alter (&$uri)
 
 hook_file_mimetype_mapping_alter (&$mapping)
 
 hook_archiver_info_alter (&$info)
 
 hook_filetransfer_info ()
 
 hook_filetransfer_info_alter (&$filetransfer_info)
 
 hook_ajax_render_alter (array &$data)
 
 hook_language_switch_links_alter (array &$links, $type, $path)
 
 hook_transliteration_overrides_alter (&$overrides, $langcode)
 
 hook_link_alter (&$variables)
 
 hook_form_system_theme_settings_alter (&$form,\Drupal\Core\Form\FormStateInterface $form_state)
 
 hook_preprocess (&$variables, $hook)
 
 hook_preprocess_HOOK (&$variables)
 
 hook_theme_suggestions_alter (array &$suggestions, array $variables, $hook)
 
 hook_theme ($existing, $type, $theme, $path)
 
 hook_theme_registry_alter (&$theme_registry)
 
 hook_template_preprocess_default_variables_alter (&$variables)
 
 hook_tokens_alter (array &$replacements, array $context,\Drupal\Core\Render\BubbleableMetadata $bubbleable_metadata)
 
 hook_token_info ()
 
 hook_token_info_alter (&$data)
 
 hook_action_delete ($aid)
 
 hook_ckeditor_plugin_info_alter (array &$plugins)
 
 hook_ckeditor_css_alter (array &$css, Editor $editor)
 
 hook_comment_links_alter (array &$links, CommentInterface $entity, array &$context)
 
 hook_config_translation_info (&$info)
 
 hook_config_translation_info_alter (&$info)
 
 hook_contextual_links_view_alter (&$element, $items)
 
 hook_editor_info_alter (array &$editors)
 
 hook_editor_js_settings_alter (array &$settings)
 
 hook_editor_xss_filter_alter (&$editor_xss_filter_class, FilterFormatInterface $format, FilterFormatInterface $original_format=NULL)
 
 hook_file_validate (Drupal\file\FileInterface $file)
 
 hook_file_copy (Drupal\file\FileInterface $file, Drupal\file\FileInterface $source)
 
 hook_file_move (Drupal\file\FileInterface $file, Drupal\file\FileInterface $source)
 
 hook_filter_info_alter (&$info)
 
 hook_filter_secure_image_alter (&$image)
 
 hook_filter_format_disable ($format)
 
 hook_help ($route_name,\Drupal\Core\Routing\RouteMatchInterface $route_match)
 
 hook_image_effect_info_alter (&$effects)
 
 hook_image_style_flush ($style)
 
 hook_language_types_info ()
 
 hook_language_types_info_alter (array &$language_types)
 
 hook_language_negotiation_info_alter (array &$negotiation_info)
 
 hook_language_fallback_candidates_alter (array &$candidates, array $context)
 
 hook_language_fallback_candidates_OPERATION_alter (array &$candidates, array $context)
 
 hook_node_grants (\Drupal\Core\Session\AccountInterface $account, $op)
 
 hook_node_access_records (\Drupal\node\NodeInterface $node)
 
 hook_node_access_records_alter (&$grants, Drupal\node\NodeInterface $node)
 
 hook_node_grants_alter (&$grants,\Drupal\Core\Session\AccountInterface $account, $op)
 
 hook_node_access (\Drupal\node\NodeInterface $node, $op,\Drupal\Core\Session\AccountInterface $account)
 
 hook_node_links_alter (array &$links, NodeInterface $entity, array &$context)
 
 hook_options_list_alter (array &$options, array $context)
 
 hook_path_insert ($path)
 
 hook_path_update ($path)
 
 hook_path_delete ($path)
 
 hook_quickedit_editor_alter (&$editors)
 
 hook_quickedit_render_field (Drupal\Core\Entity\EntityInterface $entity, $field_name, $view_mode_id, $langcode)
 
 hook_rdf_namespaces ()
 
 hook_rest_resource_alter (&$definitions)
 
 hook_rest_type_uri_alter (&$uri, $context=array())
 
 hook_rest_relation_uri_alter (&$uri, $context=array())
 
 hook_search_preprocess ($text, $langcode=NULL)
 
 hook_search_plugin_alter (array &$definitions)
 
 hook_shortcut_default_set ($account)
 
 hook_simpletest_alter (&$groups)
 
 hook_test_group_started ()
 
 hook_test_group_finished ()
 
 hook_test_finished ($results)
 
 hook_system_themes_page_alter (&$theme_groups)
 
 hook_toolbar ()
 
 hook_toolbar_alter (&$items)
 
 hook_tour_tips_alter (array &$tour_tips, Drupal\Core\Entity\EntityInterface $entity)
 
 hook_tour_tips_info_alter (&$info)
 
 hook_update_projects_alter (&$projects)
 
 hook_update_status_alter (&$projects)
 
 hook_verify_update_archive ($project, $archive_file, $directory)
 
 hook_user_cancel ($edit, $account, $method)
 
 hook_user_cancel_methods_alter (&$methods)
 
 hook_user_format_name_alter (&$name, $account)
 
 hook_user_login ($account)
 
 hook_user_logout ($account)
 
 hook_views_analyze (Drupal\views\ViewExecutable $view)
 
 hook_views_data ()
 
 hook_views_data_alter (array &$data)
 
 hook_field_views_data (\Drupal\field\FieldStorageConfigInterface $field_storage)
 
 hook_field_views_data_alter (array &$data,\Drupal\field\FieldStorageConfigInterface $field_storage)
 
 hook_field_views_data_views_data_alter (array &$data,\Drupal\field\FieldStorageConfigInterface $field)
 
 hook_views_query_substitutions (ViewExecutable $view)
 
 hook_views_form_substitutions ()
 
 hook_views_pre_view (ViewExecutable $view, $display_id, array &$args)
 
 hook_views_pre_build (ViewExecutable $view)
 
 hook_views_post_build (ViewExecutable $view)
 
 hook_views_pre_execute (ViewExecutable $view)
 
 hook_views_post_execute (ViewExecutable $view)
 
 hook_views_pre_render (ViewExecutable $view)
 

Detailed Description

Define functions that alter the behavior of Drupal core.

One way for modules to alter the core behavior of Drupal (or another module) is to use hooks. Hooks are specially-named functions that a module defines (this is known as "implementing the hook"), which are discovered and called at specific times to alter or add to the base behavior or data (this is known as "invoking the hook"). Each hook has a name (example: hook_batch_alter()), a defined set of parameters, and a defined return value. Your modules can implement hooks that are defined by Drupal core or other modules that they interact with. Your modules can also define their own hooks, in order to let other modules interact with them.

To implement a hook:

To define a hook:

To invoke a hook, use methods on such as alter(), invoke(), and invokeAll(). You can obtain a module handler by calling ::moduleHandler(), or getting the 'module_handler' service on an injected container.

See Also
Extending and altering Drupal
Theme system overview
Callbacks
::moduleHandler()

End of "addtogroup callbacks".

Function Documentation

hook_action_delete (   $aid)

Executes code after an action is deleted.

Parameters
$aidThe action ID.

References db_delete().

Here is the call graph for this function:

hook_ajax_render_alter ( array &  $data)

Alter the Ajax command data that is sent to the client.

Parameters
\Drupal\Core\Ajax\CommandInterface[]$data An array of all the rendered commands that will be sent to the client.
See Also
::ajaxRender()

References Drupal\service().

Here is the call graph for this function:

hook_archiver_info_alter ( $info)

Alter archiver information declared by other modules.

See hook_archiver_info() for a description of archivers and the archiver information structure.

Parameters
$infoArchiver information to alter (return values from hook_archiver_info()).
hook_cache_flush ( )

Flush all persistent and static caches.

This hook asks your module to clear all of its static caches, in order to ensure a clean environment for subsequently invoked data rebuilds.

Do NOT use this hook for rebuilding information. Only use it to flush custom caches.

Static caches using drupal_static() do not need to be reset manually. However, all other static variables that do not use drupal_static() must be manually reset.

This hook is invoked by drupal_flush_all_caches(). It runs before module data is updated and before hook_rebuild().

See Also
drupal_flush_all_caches()
hook_rebuild()
hook_ckeditor_css_alter ( array &  $css,
Editor  $editor 
)

Modify the list of CSS files that will be added to a CKEditor instance.

Modules may use this hook to provide their own custom CSS file without providing a CKEditor plugin. This list of CSS files is only used in the iframe versions of CKEditor.

Front-end themes (and base themes) can easily specify CSS files to be used in iframe instances of CKEditor through an entry in their .info file:

ckeditor_stylesheets[] = css/ckeditor-iframe.css
Parameters
array&$cssAn array of CSS files, passed by reference. This is a flat list of file paths relative to the Drupal root.
$editorThe text editor object as returned by editor_load(), for which these files are being loaded. Based on this information, it is possible to load the corresponding text format object.
See Also
_ckeditor_theme_css()
hook_ckeditor_plugin_info_alter ( array &  $plugins)

Modify the list of available CKEditor plugins.

This hook may be used to modify plugin properties after they have been specified by other modules.

Parameters
$pluginsAn array of all the existing plugin definitions, passed by reference.
See Also
CKEditorPluginManager

References t().

Here is the call graph for this function:

hook_comment_links_alter ( array &  $links,
CommentInterface  $entity,
array &  $context 
)

Alter the links of a comment.

Parameters
array&$linksA renderable array representing the comment links.
\Drupal\comment\CommentInterface$entityThe comment being rendered.
array&$contextVarious aspects of the context in which the comment links are going to be displayed, with the following keys:
  • 'view_mode': the view mode in which the comment is being viewed
  • 'langcode': the language in which the comment is being viewed
  • 'commented_entity': the entity to which the comment is attached
See Also
::renderLinks()
::buildLinks()

References Drupal\getContainer(), EntityInterface\id(), and t().

Here is the call graph for this function:

hook_config_import_steps_alter ( $sync_steps,
\Drupal\Core\Config\ConfigImporter  $config_importer 
)

Alter the configuration synchronization steps.

Parameters
array$sync_stepsA one-dimensional array of method names or callables that are invoked to complete the import, in the order that they will be processed. Each callable item defined in $sync_steps should either be a global function or a public static method. The callable should accept a $context array by reference. For example: function _additional_configuration_step(&$context) { // Do stuff. // If finished set $context['finished'] = 1. } For more information on creating batches, see the Batch operations documentation.
See Also
callback_batch_operation()
::initialize()
hook_config_schema_info_alter ( $definitions)

Alter config typed data definitions.

For example you can alter the typed data types representing each configuration schema type to change default labels or form element renderers used for configuration translation.

If implementations of this hook add or remove configuration schema a ConfigSchemaAlterException will be thrown. Keep in mind that there are tools that may use the configuration schema for static analysis of configuration files, like the string extractor for the localization system. Such systems won't work with dynamically defined configuration schemas.

For adding new data types use configuration schema YAML files instead.

Parameters
$definitionsAssociative array of configuration type definitions keyed by schema type names. The elements are themselves array with information about the type.
See Also
hook_config_translation_info ( $info)

Introduce dynamic translation tabs for translation of configuration.

This hook augments MODULE.config_translation.yml as well as THEME.config_translation.yml files to collect dynamic translation mapper information. If your information is static, just provide such a YAML file with your module containing the mapping.

Note that while themes can provide THEME.config_translation.yml files this hook is not invoked for themes.

Parameters
array$infoAn associative array of configuration mapper information. Use an entity name for the key (for entity mapping) or a unique string for configuration name list mapping. The values of the associative array are arrays themselves in the same structure as the *.config_translation.yml files.
See Also
hook_config_translation_info_alter()
::routes()

References Drupal\entityManager(), Drupal\moduleHandler(), Drupal\service(), and t().

Here is the call graph for this function:

hook_config_translation_info_alter ( $info)

Alter existing translation tabs for translation of configuration.

This hook is useful to extend existing configuration mappers with new configuration names, for example when altering existing forms with new settings stored elsewhere. This allows the translation experience to also reflect the compound form element in one screen.

Parameters
array$infoAn associative array of discovered configuration mappers. Use an entity name for the key (for entity mapping) or a unique string for configuration name list mapping. The values of the associative array are arrays themselves in the same structure as the *.config_translation.yml files.
See Also
hook_translation_info()
hook_contextual_links_view_alter ( $element,
  $items 
)

Alter a contextual links element before it is rendered.

This hook is invoked by contextual_pre_render_links(). The renderable array of #type 'contextual_links', containing the entire contextual links data that is passed in by reference. Further links may be added or existing links can be altered.

Parameters
$elementA renderable array representing the contextual links.
$itemsAn associative array containing the original contextual link items, as generated by ::getContextualLinksArrayByGroup(), which were used to build $element['#links'].
See Also
hook_contextual_links_alter()
hook_contextual_links_plugins_alter()
contextual_pre_render_links()
hook_countries_alter ( $countries)

Alter the default country list.

Parameters
$countriesThe associative array of countries keyed by two-letter country code.
See Also
::getList().
hook_cron ( )

Perform periodic actions.

Modules that require some commands to be executed periodically can implement hook_cron(). The engine will then call the hook whenever a cron run happens, as defined by the administrator. Typical tasks managed by hook_cron() are database maintenance, backups, recalculation of settings or parameters, automated mailing, and retrieving remote data.

Short-running or non-resource-intensive tasks can be executed directly in the hook_cron() implementation.

Long-running tasks and tasks that could time out, such as retrieving remote data, sending email, and intensive file tasks, should use the queue API instead of executing the tasks directly. To do this, first define one or more queues via a plugin. Then, add items that need to be processed to the defined queues.

References db_delete(), db_query(), Drupal\queue(), and Drupal\state().

Here is the call graph for this function:

hook_data_type_info_alter ( $data_types)

Alter available data types for typed data wrappers.

Parameters
array$data_typesAn array of data type information.
See Also
hook_data_type_info()
hook_display_variant_plugin_alter ( array &  $definitions)

Alter display variant plugin definitions.

Parameters
array$definitionsThe array of display variant definitions, keyed by plugin ID.
See Also

References t().

Here is the call graph for this function:

hook_editor_info_alter ( array &  $editors)

Performs alterations on text editor definitions.

Parameters
array$editorsAn array of metadata of text editors, as collected by the plugin annotation discovery mechanism.
See Also

References t().

Here is the call graph for this function:

hook_editor_js_settings_alter ( array &  $settings)

Modifies JavaScript settings that are added for text editors.

Parameters
array$settingsAll the settings that will be added to the page for the text formats to which a user has access.
hook_editor_xss_filter_alter ( $editor_xss_filter_class,
FilterFormatInterface  $format,
FilterFormatInterface  $original_format = NULL 
)

Modifies the text editor XSS filter that will used for the given text format.

Is only called when an EditorXssFilter will effectively be used; this hook does not allow one to alter that decision.

Parameters
string&$editor_xss_filter_classThe text editor XSS filter class that will be used.
\Drupal\filter\FilterFormatInterface$formatThe text format configuration entity. Provides context based upon which one may want to adjust the filtering.
\Drupal\filter\FilterFormatInterface$original_format,|null(optional) The original text format configuration entity (when switching text formats/editors). Also provides context based upon which one may want to adjust the filtering.
See Also

References FilterFormatInterface\filters().

Here is the call graph for this function:

hook_entity_base_field_info ( \Drupal\Core\Entity\EntityTypeInterface  $entity_type)

Provides custom base field definitions for a content entity type.

Parameters
\Drupal\Core\Entity\EntityTypeInterface$entity_typeThe entity type definition.
Returns
[] An array of field definitions, keyed by field name.
See Also
hook_entity_base_field_info_alter()
hook_entity_bundle_field_info()
hook_entity_bundle_field_info_alter()
::getFieldDefinitions()

References t().

Here is the call graph for this function:

hook_entity_base_field_info_alter ( $fields,
\Drupal\Core\Entity\EntityTypeInterface  $entity_type 
)

Alter base field definitions for a content entity type.

Parameters
\Drupal\Core\Field\FieldDefinitionInterface[]$fields The array of base field definitions for the entity type.
\Drupal\Core\Entity\EntityTypeInterface$entity_typeThe entity type definition.
See Also
hook_entity_base_field_info()
hook_entity_bundle_field_info()
hook_entity_bundle_field_info_alter()
Todo:
WARNING: This hook will be changed in https://www.drupal.org/node/2346329.
hook_entity_bundle_create (   $entity_type_id,
  $bundle 
)

Act on entity_bundle_create().

This hook is invoked after the operation has been performed.

Parameters
string$entity_type_idThe type of $entity; e.g. 'node' or 'user'.
string$bundleThe name of the bundle.
See Also
Entity CRUD, editing, and view hooks

References Drupal\service().

Here is the call graph for this function:

hook_entity_bundle_field_info ( \Drupal\Core\Entity\EntityTypeInterface  $entity_type,
  $bundle,
array  $base_field_definitions 
)

Provides field definitions for a specific bundle within an entity type.

Bundle fields either have to override an existing base field, or need to provide a field storage definition via hook_entity_field_storage_info() unless they are computed.

Parameters
\Drupal\Core\Entity\EntityTypeInterface$entity_typeThe entity type definition.
string$bundleThe bundle.
\Drupal\Core\Field\FieldDefinitionInterface[]$base_field_definitions The list of base field definitions for the entity type.
Returns
[] An array of bundle field definitions, keyed by field name.
See Also
hook_entity_base_field_info()
hook_entity_base_field_info_alter()
hook_entity_field_storage_info()
hook_entity_field_storage_info_alter()
hook_entity_bundle_field_info_alter()
::getFieldDefinitions()
Todo:
WARNING: This hook will be changed in https://www.drupal.org/node/2346347.

References t().

Here is the call graph for this function:

hook_entity_bundle_field_info_alter ( $fields,
\Drupal\Core\Entity\EntityTypeInterface  $entity_type,
  $bundle 
)

Alter bundle field definitions.

Parameters
\Drupal\Core\Field\FieldDefinitionInterface[]$fields The array of bundle field definitions.
\Drupal\Core\Entity\EntityTypeInterface$entity_typeThe entity type definition.
string$bundleThe bundle.
See Also
hook_entity_base_field_info()
hook_entity_base_field_info_alter()
hook_entity_bundle_field_info()
Todo:
WARNING: This hook will be changed in https://www.drupal.org/node/2346347.
hook_entity_bundle_info ( )

Describe the bundles for entity types.

Returns
array An associative array of all entity bundles, keyed by the entity type name, and then the bundle name, with the following keys:
  • label: The human-readable name of the bundle.
  • uri_callback: The same as the 'uri_callback' key defined for the entity type in the EntityManager, but for the bundle only. When determining the URI of an entity, if a 'uri_callback' is defined for both the entity type and the bundle, the one for the bundle is used.
  • translatable: (optional) A boolean value specifying whether this bundle has translation support enabled. Defaults to FALSE.
See Also
entity_get_bundles()
hook_entity_bundle_info_alter()

References t().

Here is the call graph for this function:

hook_entity_bundle_info_alter ( $bundles)

Alter the bundles for entity types.

Parameters
array$bundlesAn array of bundles, keyed first by entity type, then by bundle name.
See Also
entity_get_bundles()
hook_entity_bundle_info()

References t().

Here is the call graph for this function:

hook_entity_extra_field_info ( )

Exposes "pseudo-field" components on content entities.

Field UI's "Manage fields" and "Manage display" pages let users re-order fields, but also non-field components. For nodes, these include elements exposed by modules through hook_form_alter(), for instance.

Content entities or modules that want to have their components supported should expose them using this hook. The user-defined settings (weight, visible) are automatically applied when entities or entity forms are rendered.

See Also
hook_entity_extra_field_info_alter()
Returns
array The array structure is identical to that of the return value of ::getExtraFields().

References Drupal\moduleHandler(), and t().

Here is the call graph for this function:

hook_entity_extra_field_info_alter ( $info)

Alter "pseudo-field" components on content entities.

Parameters
array$infoThe array structure is identical to that of the return value of ::getExtraFields().
See Also
hook_entity_extra_field_info()
hook_entity_field_access (   $operation,
\Drupal\Core\Field\FieldDefinitionInterface  $field_definition,
\Drupal\Core\Session\AccountInterface  $account,
\Drupal\Core\Field\FieldItemListInterface  $items = NULL 
)

Control access to fields.

This hook is invoked from ::fieldAccess() to let modules grant or deny operations on fields.

Parameters
string$operationThe operation to be performed. See ::access() for possible values.
\Drupal\Core\Field\FieldDefinitionInterface$field_definitionThe field definition.
\Drupal\Core\Session\AccountInterface$accountThe user account to check.
\Drupal\Core\Field\FieldItemListInterface$items(optional) The entity field object on which the operation is to be performed.
Returns
The access result.
hook_entity_field_storage_info ( \Drupal\Core\Entity\EntityTypeInterface  $entity_type)

Provides field storage definitions for a content entity type.

Parameters
\Drupal\Core\Entity\EntityTypeInterface$entity_typeThe entity type definition.
Returns
[] An array of field storage definitions, keyed by field name.
See Also
hook_entity_field_storage_info_alter()
::getFieldStorageDefinitions()

References Drupal\entityManager(), and Drupal\entityQuery().

Here is the call graph for this function:

hook_entity_field_storage_info_alter ( $fields,
\Drupal\Core\Entity\EntityTypeInterface  $entity_type 
)

Alter field storage definitions for a content entity type.

Parameters
\Drupal\Core\Field\FieldStorageDefinitionInterface[]$fields The array of field storage definitions for the entity type.
\Drupal\Core\Entity\EntityTypeInterface$entity_typeThe entity type definition.
See Also
hook_entity_field_storage_info()
hook_entity_operation ( \Drupal\Core\Entity\EntityInterface  $entity)

Declares entity operations.

Parameters
\Drupal\Core\Entity\EntityInterface$entityThe entity on which the linked operations will be performed.
Returns
array An operations array as returned by EntityListBuilderInterface::getOperations().
See Also
::getOperations()

References t().

Here is the call graph for this function:

hook_entity_operation_alter ( array &  $operations,
\Drupal\Core\Entity\EntityInterface  $entity 
)

Alter entity operations.

Parameters
array$operationsOperations array as returned by ::getOperations().
\Drupal\Core\Entity\EntityInterface$entityThe entity on which the linked operations will be performed.

References t().

Here is the call graph for this function:

hook_entity_query_alter ( \Drupal\Core\Entity\Query\QueryInterface  $query)

Alter or execute an Drupal.

Parameters
\Drupal\Core\Entity\Query\QueryInterface$queryNote the $query->altered attribute which is TRUE in case the query has already been altered once. This happens with cloned queries. If there is a pager, then such a cloned query will be executed to count all elements. This query can be detected by checking for ($query->pager && $query->count), allowing the driver to return 0 from the count query and disable the pager.
hook_entity_storage_load ( array  $entities,
  $entity_type 
)

Act on content entities when loaded from the storage.

The results of this hook will be cached.

Parameters
\Drupal\Core\Entity\EntityInterface[]$entities The entities keyed by entity ID.
string$entity_typeThe type of entities being loaded (i.e. node, user, comment).
See Also
hook_entity_load()
hook_ENTITY_TYPE_storage_load ( array  $entities)

Act on content entities of a given type when loaded from the storage.

The results of this hook will be cached if the entity type supports it.

Parameters
\Drupal\Core\Entity\EntityInterface[]$entities The entities keyed by entity ID.
See Also
hook_entity_storage_load()
hook_entity_view_mode_info_alter ( $view_modes)

Alter the view modes for entity types.

Parameters
array$view_modesAn array of view modes, keyed first by entity type, then by view mode name.
See Also
::getAllViewModes()
::getViewModes()
hook_entity_view_mode_info()
hook_field_views_data ( \Drupal\field\FieldStorageConfigInterface  $field_storage)

Override the default Views data for a Field API field.

The field module's implementation of hook_views_data() invokes this for each field storage, in the module that defines the field type. It is not invoked in other modules.

If no hook implementation exists, hook_views_data() falls back to views_field_default_views_data().

Parameters
\Drupal\field\FieldStorageConfigInterface$field_storageThe field storage config entity.
Returns
array An array of views data, in the same format as the return value of hook_views_data().
See Also
views_views_data()
hook_field_views_data_alter()
hook_field_views_data_views_data_alter()

References t().

Here is the call graph for this function:

hook_field_views_data_alter ( array &  $data,
\Drupal\field\FieldStorageConfigInterface  $field_storage 
)

Alter the Views data for a single Field API field.

This is called on all modules even if there is no hook_field_views_data() implementation for the field, and therefore may be used to alter the default data that views_field_default_views_data() supplies for the field storage.

Parameters
array$dataThe views data for the field storage. This has the same format as the return value of hook_views_data().
\Drupal\field\FieldStorageConfigInterface$field_storageThe field storage config entity.
See Also
views_views_data()
hook_field_views_data()
hook_field_views_data_views_data_alter()

References Drupal\entityManager(), and t().

Here is the call graph for this function:

hook_field_views_data_views_data_alter ( array &  $data,
\Drupal\field\FieldStorageConfigInterface  $field 
)

Alter the Views data on a per field basis.

The field module's implementation of hook_views_data_alter() invokes this for each field storage, in the module that defines the field type. It is not invoked in other modules.

Unlike hook_field_views_data_alter(), this operates on the whole of the views data. This allows a field type to add data that concerns its fields in other tables, which would not yet be defined at the point when hook_field_views_data() and hook_field_views_data_alter() are invoked. For example, entityreference adds reverse relationships on the tables for the entities which are referenced by entityreference fields.

(Note: this is weirdly named so as not to conflict with hook_field_views_data_alter().)

Parameters
array$dataThe views data.
\Drupal\field\FieldStorageConfigInterface$fieldThe field storage config entity.
See Also
hook_field_views_data()
hook_field_views_data_alter()
views_views_data_alter()

References Drupal\entityManager(), and t().

Here is the call graph for this function:

hook_file_copy ( Drupal\file\FileInterface  $file,
Drupal\file\FileInterface  $source 
)

Respond to a file that has been copied.

Parameters
\Drupal\file\FileInterface$fileThe newly copied file entity.
\Drupal\file\FileInterface$sourceThe original file before the copy.
See Also
file_copy()

References Drupal\logger().

Here is the call graph for this function:

hook_file_download (   $uri)

Control access to private file downloads and specify HTTP headers.

This hook allows modules to enforce permissions on file downloads whenever Drupal is handling file download, as opposed to the web server bypassing Drupal and returning the file from a public directory. Modules can also provide headers to specify information like the file's name or MIME type.

Parameters
$uriThe URI of the file.
Returns
If the user does not have permission to access the file, return -1. If the user has permission, return an array with the appropriate headers. If the file is not controlled by the current module, the return value should be NULL.
See Also
file_download()

References file_uri_scheme(), and file_uri_target().

Here is the call graph for this function:

hook_file_mimetype_mapping_alter ( $mapping)

Alter MIME type mappings used to determine MIME type from a file extension.

Invoked by ::guess(). It is used to allow modules to add to or modify the default mapping from ::$defaultMapping.

Parameters
$mappingAn array of mimetypes correlated to the extensions that relate to them. The array has 'mimetypes' and 'extensions' elements, each of which is an array.
See Also
::guess()
::$defaultMapping
hook_file_move ( Drupal\file\FileInterface  $file,
Drupal\file\FileInterface  $source 
)

Respond to a file that has been moved.

Parameters
\Drupal\file\FileInterface$fileThe updated file entity after the move.
\Drupal\file\FileInterface$sourceThe original file entity before the move.
See Also
file_move()

References Drupal\logger().

Here is the call graph for this function:

hook_file_url_alter ( $uri)

Alter the URL to a file.

This hook is called from file_create_url(), and is called fairly frequently (10+ times per page), depending on how many files there are in a given page. If CSS and JS aggregation are disabled, this can become very frequently (50+ times per page) so performance is critical.

This function should alter the URI, if it wants to rewrite the file URL.

Parameters
$uriThe URI to a file for which we need an external URL, or the path to a shipped file.

References Drupal\currentUser(), file_uri_scheme(), file_uri_target(), and Drupal\service().

Here is the call graph for this function:

hook_file_validate ( Drupal\file\FileInterface  $file)

Check that files meet a given criteria.

This hook lets modules perform additional validation on files. They're able to report a failure by returning one or more error messages.

Parameters
\Drupal\file\FileInterface$fileThe file entity being validated.
Returns
array An array of error messages. If there are no problems with the file return an empty array.
See Also
file_validate()

References t().

Here is the call graph for this function:

hook_filetransfer_info ( )

Register information about FileTransfer classes provided by a module.

The FileTransfer class allows transferring files over a specific type of connection. Core provides classes for FTP and SSH. Contributed modules are free to extend the FileTransfer base class to add other connection types, and if these classes are registered via hook_filetransfer_info(), those connection types will be available to site administrators using the Update manager when they are redirected to the authorize.php script to authorize the file operations.

Returns
array Nested array of information about FileTransfer classes. Each key is a FileTransfer type (not human readable, used for form elements and variable names, etc), and the values are subarrays that define properties of that type. The keys in each subarray are:
  • 'title': Required. The human-readable name of the connection type.
  • 'class': Required. The name of the FileTransfer class. The constructor will always be passed the full path to the root of the site that should be used to restrict where file transfer operations can occur (the $jail) and an array of settings values returned by the settings form.
  • 'file': Required. The include file containing the FileTransfer class. This should be a separate .inc file, not just the .module file, so that the minimum possible code is loaded when authorize.php is running.
  • 'file path': Optional. The directory (relative to the Drupal root) where the include file lives. If not defined, defaults to the base directory of the module implementing the hook.
  • 'weight': Optional. Integer weight used for sorting connection types on the authorize.php form.
See Also
authorize.php
hook_filetransfer_info_alter()
drupal_get_filetransfer_info()

References t().

Here is the call graph for this function:

hook_filetransfer_info_alter ( $filetransfer_info)

Alter the FileTransfer class registry.

Parameters
array$filetransfer_infoReference to a nested array containing information about the FileTransfer class registry.
See Also
hook_filetransfer_info()
hook_filter_format_disable (   $format)

Perform actions when a text format has been disabled.

Parameters
$formatThe format object of the format being disabled.
hook_filter_info_alter ( $info)

Perform alterations on filter definitions.

Parameters
$infoArray of information on filters exposed by filter plugins.
hook_filter_secure_image_alter ( $image)

Alters images with an invalid source.

When the 'Restrict images to this site' filter is enabled, any images that are not hosted on the site will be passed through this hook, most commonly to replace the invalid image with an error indicator.

Parameters
DOMElement$imageAn IMG node to format, parsed from the filtered text.

References t().

Here is the call graph for this function:

hook_form_system_theme_settings_alter ( $form,
\Drupal\Core\Form\FormStateInterface  $form_state 
)

Allow themes to alter the theme-specific settings form.

With this hook, themes can alter the theme-specific settings form in any way allowable by Drupal's Form API, such as adding form elements, changing default values and removing form elements. See the Form API documentation on api.drupal.org for detailed information.

Note that the base theme's form alterations will be run before any sub-theme alterations.

Parameters
$formNested array of form elements that comprise the form.
$form_stateThe current state of the form.

References t().

Here is the call graph for this function:

hook_help (   $route_name,
\Drupal\Core\Routing\RouteMatchInterface  $route_match 
)

Provide online user help.

By implementing hook_help(), a module can make documentation available to the user for the module as a whole, or for specific pages. Help for developers should usually be provided via function header comments in the code, or in special API example files.

The page-specific help information provided by this hook appears in the Help block (provided by the core Help module), if the block is displayed on that page. The module overview help information is displayed by the Help module. It can be accessed from the page at admin/help or from the Extend Extend page. If a module implements hook_help() the help system expects module overview help to be provided.

For detailed usage examples of:

  • Module overview help, see content_translation_help(). Module overview help should follow the standard help template.
  • Page-specific help using only routes, see book_help().
  • Page-specific help using routes and $request, see block_help().
Parameters
string$route_nameFor page-specific help, use the route name as identified in the module's routing.yml file. For module overview help, the route name will be in the form of "help.page.$modulename".
Drupal\Core\Routing\RouteMatchInterface$route_matchThe current route match. This can be used to generate different help output for different pages that share the same route.
Returns
string A localized string containing the help text.

References t(), and Drupal\url().

Here is the call graph for this function:

hook_hook_info ( )

Defines one or more hooks that are exposed by a module.

Normally hooks do not need to be explicitly defined. However, by declaring a hook explicitly, a module may define a "group" for it. Modules that implement a hook may then place their implementation in either $module.module or in $module.$group.inc. If the hook is located in $module.$group.inc, then that file will be automatically loaded when needed. In general, hooks that are rarely invoked and/or are very large should be placed in a separate include file, while hooks that are very short or very frequently called should be left in the main module file so that they are always available.

Returns
An associative array whose keys are hook names and whose values are an associative array containing:
  • group: A string defining the group to which the hook belongs. The module system will determine whether a file with the name $module.$group.inc exists, and automatically load it when required.

See system_hook_info() for all hook groups defined by Drupal core.

See Also
hook_hook_info_alter().
hook_image_effect_info_alter ( $effects)

Alter the information provided in .

Parameters
$effectsThe array of image effects, keyed on the machine-readable effect name.

References t().

Here is the call graph for this function:

hook_image_style_flush (   $style)

Respond to image style flushing.

This hook enables modules to take effect when a style is being flushed (all images are being deleted from the server and regenerated). Any module-specific caches that contain information related to the style should be cleared using this hook. This hook is called whenever a style is updated, deleted, or any effect associated with the style is update or deleted.

Parameters
\Drupal\image\ImageStyleInterface$styleThe image style object that is being flushed.

References Drupal\cache().

Here is the call graph for this function:

hook_install ( )

Perform setup tasks when the module is installed.

If the module implements hook_schema(), the database tables will be created before this hook is fired.

Implementations of this hook are by convention declared in the module's .install file. The implementation can rely on the .module file being loaded. The hook will only be called when a module is installed. The module's schema version will be set to the module's greatest numbered update hook. Because of this, any time a hook_update_N() is added to the module, this function needs to be updated to reflect the current version of the database schema.

See the Schema API documentation for details on hook_schema and how database tables are defined.

Note that since this function is called from a full bootstrap, all functions (including those in modules enabled by the current page request) are available when this hook is called. Use cases could be displaying a user message, or calling a module function necessary for initial setup, etc.

Please be sure that anything added or modified in this function that can be removed during uninstall should be removed with hook_uninstall().

See Also
hook_schema()
::install()
hook_uninstall()
hook_modules_installed()

References FILE_CREATE_DIRECTORY, file_default_scheme(), FILE_MODIFY_PERMISSIONS, and file_prepare_directory().

Here is the call graph for this function:

hook_install_tasks ( $install_state)

Return an array of tasks to be performed by an installation profile.

Any tasks you define here will be run, in order, after the installer has finished the site configuration step but before it has moved on to the final import of languages and the end of the installation. This is invoked by install_tasks(). You can have any number of custom tasks to perform during this phase.

Each task you define here corresponds to a callback function which you must separately define and which is called when your task is run. This function will receive the global installation state variable, $install_state, as input, and has the opportunity to access or modify any of its settings. See the install_state_defaults() function in the installer for the list of $install_state settings used by Drupal core.

At the end of your task function, you can indicate that you want the installer to pause and display a page to the user by returning any themed output that should be displayed on that page (but see below for tasks that use the form API or batch API; the return values of these task functions are handled differently). You should also use #title within the task callback function to set a custom page title. For some tasks, however, you may want to simply do some processing and pass control to the next task without ending the page request; to indicate this, simply do not send back a return value from your task function at all. This can be used, for example, by installation profiles that need to configure certain site settings in the database without obtaining any input from the user.

The task function is treated specially if it defines a form or requires batch processing; in that case, you should return either the form API definition or batch API array, as appropriate. See below for more information on the 'type' key that you must define in the task definition to inform the installer that your task falls into one of those two categories. It is important to use these APIs directly, since the installer may be run non-interactively (for example, via a command line script), all in one page request; in that case, the installer will automatically take care of submitting forms and processing batches correctly for both types of installations. You can inspect the $install_state['interactive'] boolean to see whether or not the current installation is interactive, if you need access to this information.

Remember that a user installing Drupal interactively will be able to reload an installation page multiple times, so you should use ::state() to store any data that you may need later in the installation process. Any temporary state must be removed using ::state()->delete() before your last task has completed and control is handed back to the installer.

Parameters
array$install_stateAn array of information about the current installation state.
Returns
array A keyed array of tasks the profile will perform during the final stage of the installation. Each key represents the name of a function (usually a function defined by this profile, although that is not strictly required) that is called when that task is run. The values are associative arrays containing the following key-value pairs (all of which are optional):
  • display_name: The human-readable name of the task. This will be displayed to the user while the installer is running, along with a list of other tasks that are being run. Leave this unset to prevent the task from appearing in the list.
  • display: This is a boolean which can be used to provide finer-grained control over whether or not the task will display. This is mostly useful for tasks that are intended to display only under certain conditions; for these tasks, you can set 'display_name' to the name that you want to display, but then use this boolean to hide the task only when certain conditions apply.
  • type: A string representing the type of task. This parameter has three possible values:
    • normal: (default) This indicates that the task will be treated as a regular callback function, which does its processing and optionally returns HTML output.
    • batch: This indicates that the task function will return a batch API definition suitable for batch_set() or an array of batch definitions suitable for consecutive batch_set() calls. The installer will then take care of automatically running the task via batch processing.
    • form: This indicates that the task function will return a standard form API definition (and separately define validation and submit handlers, as appropriate). The installer will then take care of automatically directing the user through the form submission process.
  • run: A constant representing the manner in which the task will be run. This parameter has three possible values:
    • INSTALL_TASK_RUN_IF_NOT_COMPLETED: (default) This indicates that the task will run once during the installation of the profile.
    • INSTALL_TASK_SKIP: This indicates that the task will not run during the current installation page request. It can be used to skip running an installation task when certain conditions are met, even though the task may still show on the list of installation tasks presented to the user.
    • INSTALL_TASK_RUN_IF_REACHED: This indicates that the task will run on each installation page request that reaches it. This is rarely necessary for an installation profile to use; it is primarily used by the Drupal installer for bootstrap-related tasks.
  • function: Normally this does not need to be set, but it can be used to force the installer to call a different function when the task is run (rather than the function whose name is given by the array key). This could be used, for example, to allow the same function to be called by two different tasks.
See Also
install_state_defaults()
batch_set()
hook_install_tasks_alter()
install_tasks()

References Drupal\state(), and t().

Here is the call graph for this function:

hook_install_tasks_alter ( $tasks,
  $install_state 
)

Alter the full list of installation tasks.

You can use this hook to change or replace any part of the Drupal installation process that occurs after the installation profile is selected.

This hook is invoked on the install profile in install_tasks().

Parameters
$tasksAn array of all available installation tasks, including those provided by Drupal core. You can modify this array to change or replace individual steps within the installation process.
$install_stateAn array of information about the current installation state.
See Also
hook_install_tasks()
install_tasks()
hook_language_fallback_candidates_alter ( array &  $candidates,
array  $context 
)

Allow modules to alter the language fallback candidates.

Parameters
array$candidatesAn array of language codes whose order will determine the language fallback order.
array$contextA language fallback context.
See Also
::getFallbackCandidates()
hook_language_fallback_candidates_OPERATION_alter ( array &  $candidates,
array  $context 
)

Allow modules to alter the fallback candidates for specific operations.

Parameters
array$candidatesAn array of language codes whose order will determine the language fallback order.
array$contextA language fallback context.
See Also
::getFallbackCandidates()
hook_language_negotiation_info_alter ( array &  $negotiation_info)

Perform alterations on language negotiation methods.

Parameters
$negotiation_infoArray of language negotiation method definitions.
hook_language_switch_links_alter ( array &  $links,
  $type,
  $path 
)

Perform alterations on language switcher links.

A language switcher link may need to point to a different path or use a translated link text before going through the link generator, which will just handle the path aliases.

Parameters
$linksNested array of links keyed by language code.
$typeThe language type the links will switch.
$pathThe current path.

References Drupal\languageManager().

Here is the call graph for this function:

hook_language_types_info ( )

Define language types.

Returns
An associative array of language type definitions. The keys are the identifiers, which are also used as names for global variables representing the types in the bootstrap phase. The values are associative arrays that may contain the following elements:
  • name: The human-readable language type identifier.
  • description: A description of the language type.
  • locked: A boolean indicating if the user can choose whether to configure the language type or not using the UI.
  • fixed: A fixed array of language negotiation method identifiers to use to initialize this language. If locked is set to TRUE and fixed is set, it will always use the specified methods in the given priority order. If not present and locked is TRUE then language-interface will be used.
Todo:
Rename the 'fixed' key to something more meaningful, for instance 'negotiation settings'. See https://www.drupal.org/node/2166879.
See Also
hook_language_types_info_alter()

References t().

Here is the call graph for this function:

hook_language_types_info_alter ( array &  $language_types)

Perform alterations on language types.

Parameters
$language_typesArray of language type definitions.
See Also
hook_language_types_info()

References t().

Here is the call graph for this function:

hook_link_alter ( $variables)

Alter the parameters for links.

Parameters
array$variablesAn associative array of variables defining a link. The link may be either a "route link" using ::link(), which is exposed as the 'link_generator' service or a link generated by ::generate(). If the link is a "route link", 'route_name' will be set; otherwise, 'path' will be set. The following keys can be altered:
  • text: The link text for the anchor tag. If the hook implementation changes this text it needs to preserve the safeness of the original text. Using t() or ::format() with is recommended as this will escape the original text if necessary. If the resulting text is not marked safe it will be escaped.
  • url_is_active: Whether or not the link points to the currently active URL.
  • url: The object.
  • options: An associative array of additional options that will be passed to either ::assemble() or ::generateFromRoute() to generate the href attribute for this link, and also used when generating the link. Defaults to an empty array. It may contain the following elements:
    • 'query': An array of query key/value-pairs (without any URL-encoding) to append to the URL.
    • absolute: Whether to force the output to be an absolute link (beginning with http:). Useful for links that will be displayed outside the site, such as in an RSS feed. Defaults to FALSE.
    • language: An optional language object. May affect the rendering of the anchor tag, such as by adding a language prefix to the path.
    • attributes: An associative array of HTML attributes to apply to the anchor tag. If element 'class' is included, it must be an array; 'title' must be a string; other elements are more flexible, as they just need to work as an argument for the constructor of the class Drupal($options['attributes']).
See Also
::assemble()
::generateFromRoute()

References t().

Here is the call graph for this function:

hook_mail_alter ( $message)

Alter an email message created with MailManagerInterface->mail().

hook_mail_alter() allows modification of email messages created and sent with MailManagerInterface->mail(). Usage examples include adding and/or changing message text, message fields, and message headers.

Email messages sent using functions other than MailManagerInterface->mail() will not invoke hook_mail_alter(). For example, a contributed module directly calling the MailInterface->mail() or PHP mail() function will not invoke this hook. All core modules use MailManagerInterface->mail() for messaging, it is best practice but not mandatory in contributed modules.

Parameters
$messageAn array containing the message data. Keys in this array include:
  • 'id': The MailManagerInterface->mail() id of the message. Look at module source code or MailManagerInterface->mail() for possible id values.
  • 'to': The address or addresses the message will be sent to. The formatting of this string must comply with RFC 2822.
  • 'from': The address the message will be marked as being from, which is either a custom address or the site-wide default email address.
  • 'subject': Subject of the email to be sent. This must not contain any newline characters, or the email may not be sent properly.
  • 'body': An array of strings containing the message text. The message body is created by concatenating the individual array strings into a single text string using "\n\n" as a separator.
  • 'headers': Associative array containing mail headers, such as From, Sender, MIME-Version, Content-Type, etc.
  • 'params': An array of optional parameters supplied by the caller of MailManagerInterface->mail() that is used to build the message before hook_mail_alter() is invoked.
  • 'language': The language object used to build the message before hook_mail_alter() is invoked.
  • 'send': Set to FALSE to abort sending this email message.
See Also
::mail()

References Drupal\config().

Here is the call graph for this function:

hook_mail_backend_info_alter ( $info)

Alter the list of mail backend plugin definitions.

Parameters
array$infoThe mail backend plugin definitions to be altered.
See Also
hook_module_implements_alter ( $implementations,
  $hook 
)

Alter the registry of modules implementing a hook.

This hook is invoked during ::moduleHandler()->getImplementations(). A module may implement this hook in order to reorder the implementing modules, which are otherwise ordered by the module's system weight.

Note that hooks invoked using ::moduleHandler->alter() can have multiple variations(such as hook_form_alter() and hook_form_FORM_ID_alter()). ::moduleHandler->alter() will call all such variants defined by a single module in turn. For the purposes of hook_module_implements_alter(), these variants are treated as a single hook. Thus, to ensure that your implementation of hook_form_FORM_ID_alter() is called at the right time, you will have to change the order of hook_form_alter() implementation in hook_module_implements_alter().

Parameters
$implementationsAn array keyed by the module's name. The value of each item corresponds to a $group, which is usually FALSE, unless the implementation is in a file named $module.$group.inc.
$hookThe name of the module hook being implemented.
hook_module_preinstall (   $module)

Perform necessary actions before a module is installed.

Parameters
string$moduleThe name of the module about to be installed.
hook_module_preuninstall (   $module)

Perform necessary actions before a module is uninstalled.

Parameters
string$moduleThe name of the module about to be uninstalled.
hook_modules_installed (   $modules)

Perform necessary actions after modules are installed.

This function differs from hook_install() in that it gives all other modules a chance to perform actions when a module is installed, whereas hook_install() is only called on the module actually being installed. See ::install() for a detailed description of the order in which install hooks are invoked.

This hook should be implemented in a .module file, not in an .install file.

Parameters
$modulesAn array of the modules that were installed.
See Also
::install()
hook_install()

References Drupal\state().

Here is the call graph for this function:

hook_modules_uninstalled (   $modules)

Perform necessary actions after modules are uninstalled.

This function differs from hook_uninstall() in that it gives all other modules a chance to perform actions when a module is uninstalled, whereas hook_uninstall() is only called on the module actually being uninstalled.

It is recommended that you implement this hook if your module stores data that may have been set by other modules.

Parameters
$modulesAn array of the modules that were uninstalled.
See Also
hook_uninstall()

References Drupal\state().

Here is the call graph for this function:

hook_node_access ( \Drupal\node\NodeInterface  $node,
  $op,
\Drupal\Core\Session\AccountInterface  $account 
)

Controls access to a node.

Modules may implement this hook if they want to have a say in whether or not a given user has access to perform a given operation on a node.

The administrative account (user ID #1) always passes any access check, so this hook is not called in that case. Users with the "bypass node access" permission may always view and edit content through the administrative interface.

Note that not all modules will want to influence access on all node types. If your module does not want to explicitly allow or forbid access, return an AccessResultInterface object with neither isAllowed() nor isForbidden() equaling TRUE. Blindly returning an object with isForbidden() equaling TRUE will break other node access modules.

Also note that this function isn't called for node listings (e.g., RSS feeds, the default home page at path 'node', a recent content block, etc.) See Node access rights for a full explanation.

Parameters
\Drupal\node\NodeInterface | string$nodeEither a node entity or the machine name of the content type on which to perform the access check.
string$opThe operation to be performed. Possible values:
  • "create"
  • "delete"
  • "update"
  • "view"
\Drupal\Core\Session\AccountInterface$accountThe user object to perform the access check operation on.
Returns
The access result.
hook_node_access_records ( \Drupal\node\NodeInterface  $node)

Set permissions for a node to be written to the database.

When a node is saved, a module implementing hook_node_access_records() will be asked if it is interested in the access permissions for a node. If it is interested, it must respond with an array of permissions arrays for that node.

Node access grants apply regardless of the published or unpublished status of the node. Implementations must make sure not to grant access to unpublished nodes if they don't want to change the standard access control behavior. Your module may need to create a separate access realm to handle access to unpublished nodes.

Note that the grant values in the return value from your hook must be integers and not boolean TRUE and FALSE.

Each permissions item in the array is an array with the following elements:

  • 'realm': The name of a realm that the module has defined in hook_node_grants().
  • 'gid': A 'grant ID' from hook_node_grants().
  • 'grant_view': If set to 1 a user that has been identified as a member of this gid within this realm can view this node. This should usually be set to $node->isPublished(). Failure to do so may expose unpublished content to some users.
  • 'grant_update': If set to 1 a user that has been identified as a member of this gid within this realm can edit this node.
  • 'grant_delete': If set to 1 a user that has been identified as a member of this gid within this realm can delete this node.
  • langcode: (optional) The language code of a specific translation of the node, if any. Modules may add this key to grant different access to different translations of a node, such that (e.g.) a particular group is granted access to edit the Catalan version of the node, but not the Hungarian version. If no value is provided, the langcode is set automatically from the $node parameter and the node's original language (if specified) is used as a fallback. Only specify multiple grant records with different languages for a node if the site has those languages configured.

A "deny all" grant may be used to deny all access to a particular node or node translation:

$grants[] = array(
'realm' => 'all',
'gid' => 0,
'grant_view' => 0,
'grant_update' => 0,
'grant_delete' => 0,
'langcode' => 'ca',
);

Note that another module node access module could override this by granting access to one or more nodes, since grants are additive. To enforce that access is denied in a particular case, use hook_node_access_records_alter(). Also note that a deny all is not written to the database; denies are implicit.

Parameters
\Drupal\node\NodeInterface$nodeThe node that has just been saved.
Returns
An array of grants as defined above.
See Also
node_access_write_grants()
hook_node_access_records_alter()
hook_node_access_records_alter ( $grants,
Drupal\node\NodeInterface  $node 
)

Alter permissions for a node before it is written to the database.

Node access modules establish rules for user access to content. Node access records are stored in the {node_access} table and define which permissions are required to access a node. This hook is invoked after node access modules returned their requirements via hook_node_access_records(); doing so allows modules to modify the $grants array by reference before it is stored, so custom or advanced business logic can be applied.

Upon viewing, editing or deleting a node, hook_node_grants() builds a permissions array that is compared against the stored access records. The user must have one or more matching permissions in order to complete the requested operation.

A module may deny all access to a node by setting $grants to an empty array.

Parameters
array$grantsThe $grants array returned by hook_node_access_records().
\Drupal\node\NodeInterface$nodeThe node for which the grants were acquired.

The preferred use of this hook is in a module that bridges multiple node access modules with a configurable behavior, as shown in the example with the 'is_preview' field.

See Also
hook_node_access_records()
hook_node_grants()
hook_node_grants_alter()
hook_node_grants ( \Drupal\Core\Session\AccountInterface  $account,
  $op 
)

Inform the node access system what permissions the user has.

This hook is for implementation by node access modules. In this hook, the module grants a user different "grant IDs" within one or more "realms". In hook_node_access_records(), the realms and grant IDs are associated with permission to view, edit, and delete individual nodes.

The realms and grant IDs can be arbitrarily defined by your node access module; it is common to use role IDs as grant IDs, but that is not required. Your module could instead maintain its own list of users, where each list has an ID. In that case, the return value of this hook would be an array of the list IDs that this user is a member of.

A node access module may implement as many realms as necessary to properly define the access privileges for the nodes. Note that the system makes no distinction between published and unpublished nodes. It is the module's responsibility to provide appropriate realms to limit access to unpublished content.

Node access records are stored in the {node_access} table and define which grants are required to access a node. There is a special case for the view operation – a record with node ID 0 corresponds to a "view all" grant for the realm and grant ID of that record. If there are no node access modules enabled, the core node module adds a node ID 0 record for realm 'all'. Node access modules can also grant "view all" permission on their custom realms; for example, a module could create a record in {node_access} with:

$record = array(
'nid' => 0,
'gid' => 888,
'realm' => 'example_realm',
'grant_view' => 1,
'grant_update' => 0,
'grant_delete' => 0,
);
db_insert('node_access')->fields($record)->execute();

And then in its hook_node_grants() implementation, it would need to return:

if ($op == 'view') {
$grants['example_realm'] = array(888);
}

If you decide to do this, be aware that the node_access_rebuild() function will erase any node ID 0 entry when it is called, so you will need to make sure to restore your {node_access} record after node_access_rebuild() is called.

Parameters
\Drupal\Core\Session\AccountInterface$accountThe account object whose grants are requested.
string$opThe node operation to be performed, such as 'view', 'update', or 'delete'.
Returns
array An array whose keys are "realms" of grants, and whose values are arrays of the grant IDs within this realm that this user is being granted.

For a detailed example, see node_access_example.module.

See Also
node_access_view_all_nodes()
node_access_rebuild()
hook_node_grants_alter ( $grants,
\Drupal\Core\Session\AccountInterface  $account,
  $op 
)

Alter user access rules when trying to view, edit or delete a node.

Node access modules establish rules for user access to content. hook_node_grants() defines permissions for a user to view, edit or delete nodes by building a $grants array that indicates the permissions assigned to the user by each node access module. This hook is called to allow modules to modify the $grants array by reference, so the interaction of multiple node access modules can be altered or advanced business logic can be applied.

The resulting grants are then checked against the records stored in the {node_access} table to determine if the operation may be completed.

A module may deny all access to a user by setting $grants to an empty array.

Developers may use this hook to either add additional grants to a user or to remove existing grants. These rules are typically based on either the permissions assigned to a user role, or specific attributes of a user account.

Parameters
array$grantsThe $grants array returned by hook_node_grants().
\Drupal\Core\Session\AccountInterface$accountThe account requesting access to content.
string$opThe operation being performed, 'view', 'update' or 'delete'.
See Also
hook_node_grants()
hook_node_access_records()
hook_node_access_records_alter()

References Drupal\config().

Here is the call graph for this function:

hook_node_links_alter ( array &  $links,
NodeInterface  $entity,
array &  $context 
)

Alter the links of a node.

Parameters
array&$linksA renderable array representing the node links.
\Drupal\node\NodeInterface$entityThe node being rendered.
array&$contextVarious aspects of the context in which the node links are going to be displayed, with the following keys:
  • 'view_mode': the view mode in which the node is being viewed
  • 'langcode': the language in which the node is being viewed
See Also
::renderLinks()
::buildLinks()
Entity CRUD, editing, and view hooks

References Drupal\getContainer(), and t().

Here is the call graph for this function:

hook_options_list_alter ( array &  $options,
array  $context 
)

Alters the list of options to be displayed for a field.

This hook can notably be used to change the label of the empty option.

Parameters
array$optionsThe array of options for the field, as returned by ::getSettableOptions(). An empty option (_none) might have been added, depending on the field properties.
array$contextAn associative array containing:
  • field_definition: The field definition ().
  • entity: The entity object the field is attached to ().
See Also
hook_options_list()

References t().

Here is the call graph for this function:

hook_path_delete (   $path)

Respond to a path being deleted.

Parameters
array$pathThe array structure is identical to that of the return value of ::save().
See Also
::delete()

References db_delete().

Here is the call graph for this function:

hook_path_insert (   $path)

Respond to a path being inserted.

Parameters
array$pathThe array structure is identical to that of the return value of ::save().
See Also
::save()

References db_insert().

Here is the call graph for this function:

hook_path_update (   $path)

Respond to a path being updated.

Parameters
array$pathThe array structure is identical to that of the return value of ::save().
See Also
::save()

References db_update().

Here is the call graph for this function:

hook_preprocess ( $variables,
  $hook 
)

Preprocess theme variables for templates.

This hook allows modules to preprocess theme variables for theme templates. It is called for all theme hooks implemented as templates, but not for theme hooks implemented as functions. hook_preprocess_HOOK() can be used to preprocess variables for a specific theme hook, whether implemented as a template or function.

For more detailed information, see the Theme system overview topic .

Parameters
$variablesThe variables array (modify in place).
$hookThe name of the theme hook.

References Drupal\currentUser().

Here is the call graph for this function:

hook_preprocess_HOOK ( $variables)

Preprocess theme variables for a specific theme hook.

This hook allows modules to preprocess theme variables for a specific theme hook. It should only be used if a module needs to override or add to the theme preprocessing for a theme hook it didn't define.

For more detailed information, see the Theme system overview topic .

Parameters
$variablesThe variables array (modify in place).
hook_queue_info_alter ( $queues)

Alter cron queue information before cron runs.

Called by to allow modules to alter cron queue settings before any jobs are processesed.

Parameters
array$queuesAn array of cron queue information.
See Also
hook_quickedit_editor_alter ( $editors)

Allow modules to alter in-place editor plugin metadata.

This hook is called after the in-place editor plugins have been discovered, but before they are cached. Hence any alterations will be cached.

Parameters
array&$editorsAn array of metadata on existing in-place editors, as collected by the annotation discovery mechanism.
See Also
hook_quickedit_render_field ( Drupal\Core\Entity\EntityInterface  $entity,
  $field_name,
  $view_mode_id,
  $langcode 
)

Returns a renderable array for the value of a single field in an entity.

To integrate with in-place field editing when a non-standard render pipeline is used (FieldItemListInterface::view() is not sufficient to render back the field following in-place editing in the exact way it was displayed originally), implement this hook.

Edit module integrates with HTML elements with data-edit-field-id attributes. For example: data-edit-field-id="node/1/<field-name>/und/<module-name>-<custom-id>" After the editing is complete, this hook is invoked on the module with the custom render pipeline identifier (last part of data-edit-field-id) to re-render the field. Use the same logic used when rendering the field for the original display.

The implementation should take care of invoking the prepare_view steps. It should also respect field access permissions.

Parameters
\Drupal\Core\Entity\EntityInterface$entityThe entity containing the field to display.
string$field_nameThe name of the field to display.
string$view_mode_idView mode ID for the custom render pipeline this field view was destined for. This is not a regular view mode ID for the Entity/Field API render pipeline and is provided by the renderer module instead. An example could be Views' render pipeline. In the example of Views, the view mode ID would probably contain the View's ID, display and the row index. Views would know the internal structure of this ID. The only structure imposed on this ID is that it contains dash separated values and the first value is the module name. Only that module's hook implementation will be invoked. Eg. 'views-...-...'.
string$langcode(Optional) The language code the field values are to be shown in.
Returns
A renderable array for the field value.
See Also
::view()
hook_rdf_namespaces ( )

Allow modules to define namespaces for RDF mappings.

Many common namespace prefixes are defined in rdf_rdf_namespaces(). However, if a module implements rdf mappings that use prefixes that are not defined in rdf_rdf_namespaces(), this hook should be used to define the new namespace prefixes.

Returns
string[] An associative array of namespaces where the key is the namespace prefix and the value is the namespace URI.
hook_rebuild ( )

Rebuild data based upon refreshed caches.

This hook allows your module to rebuild its data based on the latest/current module data. It runs after hook_cache_flush() and after all module data has been updated.

This hook is only invoked after the system has been completely cleared; i.e., all previously cached data is known to be gone and every API in the system is known to return current information, so your module can safely rely on all available data to rebuild its own.

See Also
hook_cache_flush()
drupal_flush_all_caches()

References Drupal\service().

Here is the call graph for this function:

hook_requirements (   $phase)

Check installation requirements and do status reporting.

This hook has three closely related uses, determined by the $phase argument:

  • Checking installation requirements ($phase == 'install').
  • Checking update requirements ($phase == 'update').
  • Status reporting ($phase == 'runtime').

Note that this hook, like all others dealing with installation and updates, must reside in a module_name.install file, or it will not properly abort the installation of the module if a critical requirement is missing.

During the 'install' phase, modules can for example assert that library or server versions are available or sufficient. Note that the installation of a module can happen during installation of Drupal itself (by install.php) with an installation profile or later by hand. As a consequence, install-time requirements must be checked without access to the full Drupal API, because it is not available during install.php. If a requirement has a severity of REQUIREMENT_ERROR, install.php will abort or at least the module will not install. Other severity levels have no effect on the installation. Module dependencies do not belong to these installation requirements, but should be defined in the module's .info.yml file.

The 'runtime' phase is not limited to pure installation requirements but can also be used for more general status information like maintenance tasks and security issues. The returned 'requirements' will be listed on the status report in the administration section, with indication of the severity level. Moreover, any requirement with a severity of REQUIREMENT_ERROR severity will result in a notice on the administration configuration page.

Parameters
$phaseThe phase in which requirements are checked:
  • install: The module is being installed.
  • update: The module is enabled and update.php is run.
  • runtime: The runtime requirements are being checked and shown on the status report page.
Returns
An associative array where the keys are arbitrary but must be unique (it is suggested to use the module short name as a prefix) and the values are themselves associative arrays with the following elements:
  • title: The name of the requirement.
  • value: The current value (e.g., version, time, level, etc). During install phase, this should only be used for version numbers, do not set it if not applicable.
  • description: The description of the requirement/status.
  • severity: The requirement's result/severity level, one of:
    • REQUIREMENT_INFO: For info only.
    • REQUIREMENT_OK: The requirement is satisfied.
    • REQUIREMENT_WARNING: The requirement failed with a warning.
    • REQUIREMENT_ERROR: The requirement failed with an error.

References Drupal\l(), Drupal\service(), Drupal\state(), t(), Drupal\url(), and Drupal\VERSION.

Here is the call graph for this function:

hook_rest_relation_uri_alter ( $uri,
  $context = array() 
)

Alter the REST relation URI.

Modules may wish to alter the relation URI generated for a resource based on the context of the serializer/normalizer operation.

Parameters
string$uriThe URI to alter.
array$contextThe context from the serializer/normalizer operation.
See Also
::serialize()
::deserialize()
::normalize()
::denormalize()

References Drupal\config().

Here is the call graph for this function:

hook_rest_resource_alter ( $definitions)

Alter the resource plugin definitions.

Parameters
array$definitionsThe collection of resource definitions.
hook_rest_type_uri_alter ( $uri,
  $context = array() 
)

Alter the REST type URI.

Modules may wish to alter the type URI generated for a resource based on the context of the serializer/normalizer operation.

Parameters
string$uriThe URI to alter.
array$contextThe context from the serializer/normalizer operation.
See Also
::serialize()
::deserialize()
::normalize()
::denormalize()

References Drupal\config().

Here is the call graph for this function:

hook_search_plugin_alter ( array &  $definitions)

Alter search plugin definitions.

Parameters
array$definitionsThe array of search plugin definitions, keyed by plugin ID.
See Also

References t().

Here is the call graph for this function:

hook_search_preprocess (   $text,
  $langcode = NULL 
)

Preprocess text for search.

This hook is called to preprocess both the text added to the search index and the keywords users have submitted for searching. The same processing needs to be applied to both so that searches will find matches.

Possible uses:

  • Adding spaces between words of Chinese or Japanese text.
  • Stemming words down to their root words to allow matches between, for instance, walk, walked, walking, and walks in searching.
  • Expanding abbreviations and acronyms that occur in text.
Parameters
string$textThe text to preprocess. This is a single piece of plain text extracted from between two HTML tags or from the search query. It will not contain any HTML entities or HTML tags.
string | null$langcodeThe language code for the language the text is in, if known. When this hook is invoked during search indexing, the language will most likely be known and passed in. This is left up to the search plugin; does pass in the node language. However, when this hook is invoked during searching, in order to let a module apply the same preprocessing to the search keywords and indexed text so they will match, $langcode will be NULL. A hook implementation can call the getCurrentLanguage() method on the 'language_manager' service to determine the current language and act accordingly.
Returns
string The text after preprocessing. Note that if your module decides not to alter the text, it should return the original text. Also, after preprocessing, words in the text should be separated by a space.

References Drupal\languageManager().

Here is the call graph for this function:

hook_shortcut_default_set (   $account)

Return the name of a default shortcut set for the provided user account.

This hook allows modules to define default shortcut sets for a particular user that differ from the site-wide default (for example, a module may want to define default shortcuts on a per-role basis).

The default shortcut set is used only when the user does not have any other shortcut set explicitly assigned to them.

Note that only one default shortcut set can exist per user, so when multiple modules implement this hook, the last (i.e., highest weighted) module which returns a valid shortcut set name will prevail.

Parameters
$accountThe user account whose default shortcut set is being requested.
Returns
string The name of the shortcut set that this module recommends for that user, if there is one.

References Drupal\entityManager().

Here is the call graph for this function:

hook_simpletest_alter ( $groups)

Alter the list of tests.

Parameters
$groupsA two dimensional array, the first key is the test group, the second is the name of the test class, and the value is in associative array containing 'name', 'description', 'group', and 'requires' keys.
hook_system_info_alter ( array &  $info,
\Drupal\Core\Extension\Extension  $file,
  $type 
)

Alter the information parsed from module and theme .info.yml files.

This hook is invoked in _system_rebuild_module_data() and in ::rebuildThemeData(). A module may implement this hook in order to add to or alter the data generated by reading the .info.yml file with .

Using implementations of this hook to make modules required by setting the $info['required'] key is discouraged. Doing so will slow down the module installation and uninstallation process. Instead, use .

Parameters
array$infoThe .info.yml file contents, passed by reference so that it can be altered.
\Drupal\Core\Extension\Extension$fileFull information about the module or theme.
string$typeEither 'module' or 'theme', depending on the type of .info.yml file that was passed.
See Also
hook_system_themes_page_alter ( $theme_groups)

Alters theme operation links.

Parameters
$theme_groupsAn associative array containing groups of themes.
See Also
system_themes_page()

References t().

Here is the call graph for this function:

hook_template_preprocess_default_variables_alter ( $variables)

Alter the default, hook-independent variables for all templates.

Allows modules to provide additional default template variables or manipulate existing. This hook is invoked from template_preprocess() after basic default template variables have been set up and before the next template preprocess function is invoked.

Note that the default template variables are statically cached within a request. When adding a template variable that depends on other context, it is your responsibility to appropriately reset the static cache in template_preprocess() when needed:

drupal_static_reset('template_preprocess');

See user_template_preprocess_default_variables_alter() for an example.

Parameters
array$variablesAn associative array of default template variables, as set up by _template_preprocess_default_variables(). Passed by reference.
See Also
template_preprocess()
_template_preprocess_default_variables()

References Drupal\currentUser().

Here is the call graph for this function:

hook_test_finished (   $results)

An individual test has finished.

This hook is called when an individual test has finished.

Parameters
$resultsThe results of the test as gathered by .
See Also
->results()
hook_test_group_finished ( )

A test group has finished.

This hook is called just once at the end of a test group.

hook_test_group_started ( )

A test group has started.

This hook is called just once at the beginning of a test group.

hook_theme (   $existing,
  $type,
  $theme,
  $path 
)

Alters named suggestions for a specific theme hook.

This hook allows any module or theme to provide alternative theme function or template name suggestions and reorder or remove suggestions provided by hook_theme_suggestions_HOOK() or by earlier invocations of this hook.

HOOK is the least-specific version of the hook being called. For example, if '#theme' => 'node__article' is called, then node_theme_suggestions_node() will be invoked, not node_theme_suggestions_node__article(). The specific hook called (in this case 'node__article') is available in $variables['theme_hook_original'].

Todo:
Add
sample.
@param array $suggestions
An array of theme suggestions.
@param array $variables
An array of variables passed to the theme hook. Note that this hook is
invoked before any preprocessing.
@see hook_theme_suggestions_HOOK()
/
function hook_theme_suggestions_HOOK_alter(array &$suggestions, array $variables) {
if (empty($variables['header'])) {
$suggestions[] = 'hookname__' . 'no_header';
}
}
function hook_themes_installed($theme_list) {
foreach ($theme_list as $theme) {
block_theme_initialize($theme);
}
}
function hook_themes_uninstalled(array $themes) {
// Remove some state entries depending on the theme.
foreach ($themes as $theme) {
\Drupal::state()->delete('example.' . $theme);
}
}
function hook_extension() {
// Extension for template base names in Twig.
return '.html.twig';
}
function hook_render_template($template_file, $variables) {
$twig_service = \Drupal::service('twig');
return $twig_service->loadTemplate($template_file)->render($variables);
}
function hook_element_info_alter(array &$types) {
// Decrease the default size of textfields.
if (isset($types['textfield']['#size'])) {
$types['textfield']['#size'] = 40;
}
}
function hook_js_alter(&$javascript, \Drupal\Core\Asset\AttachedAssetsInterface $assets) {
// Swap out jQuery to use an updated version of the library.
$javascript['core/assets/vendor/jquery/jquery.min.js']['data'] = drupal_get_path('module', 'jquery_update') . '/jquery.js';
}
function hook_library_info_build() {
$libraries = [];
// Add a library whose information changes depending on certain conditions.
$libraries['mymodule.zombie'] = [
'dependencies' => [
'core/backbone',
],
];
if (Drupal::moduleHandler()->moduleExists('minifyzombies')) {
$libraries['mymodule.zombie'] += [
'js' => [
'mymodule.zombie.min.js' => [],
],
'css' => [
'base' => [
'mymodule.zombie.min.css' => [],
],
],
];
}
else {
$libraries['mymodule.zombie'] += [
'js' => [
'mymodule.zombie.js' => [],
],
'css' => [
'base' => [
'mymodule.zombie.css' => [],
],
],
];
}
// Add a library only if a certain condition is met. If code wants to
// integrate with this library it is safe to (try to) load it unconditionally
// without reproducing this check. If the library definition does not exist
// the library (of course) not be loaded but no notices or errors will be
// triggered.
if (Drupal::moduleHandler()->moduleExists('vampirize')) {
$libraries['mymodule.vampire'] = [
'js' => [
'js/vampire.js' => [],
],
'css' => [
'base' => [
'css/vampire.css',
],
],
'dependencies' => [
'core/jquery',
],
];
}
return $libraries;
}
function hook_js_settings_build(array &$settings, \Drupal\Core\Asset\AttachedAssetsInterface $assets) {
// Manipulate settings.
if (isset($settings['dialog'])) {
$settings['dialog']['autoResize'] = FALSE;
}
}
function hook_js_settings_alter(array &$settings, \Drupal\Core\Asset\AttachedAssetsInterface $assets) {
// Add settings.
$settings['user']['uid'] = \Drupal::currentUser();
// Manipulate settings.
if (isset($settings['dialog'])) {
$settings['dialog']['autoResize'] = FALSE;
}
}
function hook_library_info_alter(&$libraries, $extension) {
// Update Farbtastic to version 2.0.
if ($extension == 'core' && isset($libraries['jquery.farbtastic'])) {
// Verify existing version is older than the one we are updating to.
if (version_compare($libraries['jquery.farbtastic']['version'], '2.0', '<')) {
// Update the existing Farbtastic to version 2.0.
$libraries['jquery.farbtastic']['version'] = '2.0';
// To accurately replace library files, the order of files and the options
// of each file have to be retained; e.g., like this:
$old_path = 'assets/vendor/farbtastic';
// Since the replaced library files are no longer located in a directory
// relative to the original extension, specify an absolute path (relative
// to DRUPAL_ROOT / base_path()) to the new location.
$new_path = '/' . drupal_get_path('module', 'farbtastic_update') . '/js';
$new_js = array();
$replacements = array(
$old_path . '/farbtastic.js' => $new_path . '/farbtastic-2.0.js',
);
foreach ($libraries['jquery.farbtastic']['js'] as $source => $options) {
if (isset($replacements[$source])) {
$new_js[$replacements[$source]] = $options;
}
else {
$new_js[$source] = $options;
}
}
$libraries['jquery.farbtastic']['js'] = $new_js;
}
}
}
function hook_css_alter(&$css, \Drupal\Core\Asset\AttachedAssetsInterface $assets) {
// Remove defaults.css file.
unset($css[drupal_get_path('module', 'system') . '/defaults.css']);
}
function hook_page_attachments(array &$attachments) {
// Unconditionally attach an asset to the page.
$attachments['#attached']['library'][] = 'core/domready';
// Conditionally attach an asset to the page.
if (!\Drupal::currentUser()->hasPermission('may pet kittens')) {
$attachments['#attached']['library'][] = 'core/jquery';
}
}
function hook_page_attachments_alter(array &$attachments) {
// Conditionally remove an asset.
if (in_array('core/jquery', $attachments['#attached']['library'])) {
$index = array_search('core/jquery', $attachments['#attached']['library']);
unset($attachments['#attached']['library'][$index]);
}
}
function hook_page_top(array &$page_top) {
$page_top['mymodule'] = ['#markup' => 'This is the top.'];
}
function hook_page_bottom(array &$page_bottom) {
$page_bottom['mymodule'] = ['#markup' => 'This is the bottom.'];
}
  • preprocess functions: A list of functions used to preprocess this data. Ordinarily this won't be used; it's automatically filled in. By default, for a module this will be filled in as template_preprocess_HOOK. For a theme this will be filled in as twig_preprocess and twig_preprocess_HOOK as well as themename_preprocess and themename_preprocess_HOOK.
  • override preprocess functions: Set to TRUE when a theme does NOT want the standard preprocess functions to run. This can be used to give a theme FULL control over how variables are set. For example, if a theme wants total control over how certain variables in the page.html.twig are set, this can be set to true. Please keep in mind that when this is used by a theme, that theme becomes responsible for making sure necessary variables are set.
  • type: (automatically derived) Where the theme hook is defined: 'module', 'theme_engine', or 'theme'.
  • theme path: (automatically derived) The directory path of the theme or module, so that it doesn't need to be looked up.
See Also
Theme system overview
hook_theme_registry_alter()
hook_theme_registry_alter ( $theme_registry)

Alter the theme registry information returned from hook_theme().

The theme registry stores information about all available theme hooks, including which callback functions those hooks will call when triggered, what template files are exposed by these hooks, and so on.

Note that this hook is only executed as the theme cache is re-built. Changes here will not be visible until the next cache clear.

The $theme_registry array is keyed by theme hook name, and contains the information returned from hook_theme(), as well as additional properties added by ::processExtension().

For example:

$theme_registry['block_content_add_list'] = array (
'template' => 'block-content-add-list',
'path' => 'core/themes/seven/templates',
'type' => 'theme_engine',
'theme path' => 'core/themes/seven',
'includes' => array (
0 => 'core/modules/block_content/block_content.pages.inc',
),
'variables' => array (
'content' => NULL,
),
'preprocess functions' => array (
0 => 'template_preprocess',
1 => 'template_preprocess_block_content_add_list',
2 => 'contextual_preprocess',
3 => 'seven_preprocess_block_content_add_list',
),
);
Parameters
$theme_registryThe entire cache of theme registry information, post-processing.
See Also
hook_theme()
::processExtension()
hook_theme_suggestions_alter ( array &  $suggestions,
array  $variables,
  $hook 
)

Provides alternate named suggestions for a specific theme hook.

This hook allows modules to provide alternative theme function or template name suggestions.

HOOK is the least-specific version of the hook being called. For example, if '#theme' => 'node__article' is called, then hook_theme_suggestions_node() will be invoked, not hook_theme_suggestions_node__article(). The specific hook called (in this case 'node__article') is available in $variables['theme_hook_original'].

Todo:
Add
sample.
@param array $variables
An array of variables passed to the theme hook. Note that this hook is
invoked before any preprocessing.
@return array
An array of theme suggestions.
@see hook_theme_suggestions_HOOK_alter()
/
function hook_theme_suggestions_HOOK(array $variables) {
$suggestions = array();
$suggestions[] = 'node__' . $variables['elements']['#langcode'];
return $suggestions;
}
Parameters
array$suggestionsAn array of alternate, more specific names for template files or theme functions.
array$variablesAn array of variables passed to the theme hook. Note that this hook is invoked before any variable preprocessing.
string$hookThe base hook name. For example, if '#theme' => 'node__article' is called, then $hook will be 'node', not 'node__article'. The specific hook called (in this case 'node__article') is available in $variables['theme_hook_original'].
Returns
array An array of theme suggestions.
See Also
hook_theme_suggestions_HOOK_alter()

References Drupal\languageManager().

Here is the call graph for this function:

hook_token_info ( )

Provide information about available placeholder tokens and token types.

Tokens are placeholders that can be put into text by using the syntax [type:token], where type is the machine-readable name of a token type, and token is the machine-readable name of a token within this group. This hook provides a list of types and tokens to be displayed on text editing screens, so that people editing text can see what their token options are.

The actual token replacement is done by ::replace(), which invokes hook_tokens(). Your module will need to implement that hook in order to generate token replacements from the tokens defined here.

Returns
An associative array of available tokens and token types. The outer array has two components:
  • types: An associative array of token types (groups). Each token type is an associative array with the following components:
    • name: The translated human-readable short name of the token type.
    • description (optional): A translated longer description of the token type.
    • needs-data: The type of data that must be provided to ::replace() in the $data argument (i.e., the key name in $data) in order for tokens of this type to be used in the $text being processed. For instance, if the token needs a node object, 'needs-data' should be 'node', and to use this token in ::replace(), the caller needs to supply a node object as $data['node']. Some token data can also be supplied indirectly; for instance, a node object in $data supplies a user object (the author of the node), allowing user tokens to be used when only a node data object is supplied.
  • tokens: An associative array of tokens. The outer array is keyed by the group name (the same key as in the types array). Within each group of tokens, each token item is keyed by the machine name of the token, and each token item has the following components:
    • name: The translated human-readable short name of the token.
    • description (optional): A translated longer description of the token.
    • type (optional): A 'needs-data' data type supplied by this token, which should match a 'needs-data' value from another token type. For example, the node author token provides a user object, which can then be used for token replacement data in ::replace() without having to supply a separate user object.
See Also
hook_token_info_alter()
hook_tokens()

References t().

Here is the call graph for this function:

hook_token_info_alter ( $data)

Alter the metadata about available placeholder tokens and token types.

Parameters
$dataThe associative array of token definitions from hook_token_info().
See Also
hook_token_info()

References t().

Here is the call graph for this function:

hook_tokens_alter ( array &  $replacements,
array  $context,
\Drupal\Core\Render\BubbleableMetadata  $bubbleable_metadata 
)

Alter replacement values for placeholder tokens.

Parameters
$replacementsAn associative array of replacements returned by hook_tokens().
$contextThe context in which hook_tokens() was called. An associative array with the following keys, which have the same meaning as the corresponding parameters of hook_tokens():
  • 'type'
  • 'tokens'
  • 'data'
  • 'options'
\Drupal\Core\Render\BubbleableMetadata$bubbleable_metadataThe bubbleable metadata. In case you alter an existing token based upon a data source that isn't in $context['data'], you must add that dependency to $bubbleable_metadata.
See Also
hook_tokens()

References Drupal\languageManager().

Here is the call graph for this function:

hook_toolbar ( )

Add items to the toolbar menu.

The toolbar is a container for administrative and site-global interactive components.

The toolbar provides a common styling for items denoted by the .toolbar-tab class.

The toolbar provides a construct called a 'tray'. The tray is a container for content. The tray may be associated with a toggle in the administration bar. The toggle shows or hides the tray and is optimized for small and large screens. To create this association, hook_toolbar() returns one or more render elements of type 'toolbar_item', containing the toggle and tray elements in its 'tab' and 'tray' properties.

The following properties are available:

  • 'tab': A renderable array.
  • 'tray': Optional. A renderable array.
  • '#weight': Optional. Integer weight used for sorting toolbar items in administration bar area.

This hook is invoked in toolbar_pre_render().

Returns
An array of toolbar items, keyed by unique identifiers such as 'home' or 'administration', or the short name of the module implementing the hook. The corresponding value is a render element of type 'toolbar_item'.
See Also
toolbar_pre_render()

References t().

Here is the call graph for this function:

hook_toolbar_alter ( $items)

Alter the toolbar menu after hook_toolbar() is invoked.

This hook is invoked by toolbar_view() immediately after hook_toolbar(). The toolbar definitions are passed in by reference. Each element of the $items array is one item returned by a module from hook_toolbar(). Additional items may be added, or existing items altered.

Parameters
$itemsAssociative array of toolbar menu definitions returned from hook_toolbar().
hook_tour_tips_alter ( array &  $tour_tips,
Drupal\Core\Entity\EntityInterface  $entity 
)

Allow modules to alter tour items before render.

Parameters
array$tour_tipsArray of items.
\Drupal\Core\Entity\EntityInterface$entityThe tour which contains the $tour_tips.
hook_tour_tips_info_alter ( $info)

Allow modules to alter tip plugin definitions.

Parameters
array$infoThe array of tip plugin definitions, keyed by plugin ID.
See Also
hook_transliteration_overrides_alter ( $overrides,
  $langcode 
)

Provide language-specific overrides for transliteration.

If the overrides you want to provide are standard for your language, consider providing a patch for the Drupal Core transliteration system instead of using this hook. This hook can be used temporarily until Drupal Core's transliteration tables are fixed, or for sites that want to use a non-standard transliteration system.

Parameters
array$overridesAssociative array of language-specific overrides whose keys are integer Unicode character codes, and whose values are the transliterations of those characters in the given language, to override default transliterations.
string$langcodeThe code for the language that is being transliterated.
hook_uninstall ( )

Remove any information that the module sets.

The information that the module should remove includes:

  • state that the module has set using ::state()
  • modifications to existing tables

The module should not remove its entry from the module configuration. Database tables defined by hook_schema() will be removed automatically.

The uninstall hook must be implemented in the module's .install file. It will fire when the module gets uninstalled but before the module's database tables are removed, allowing your module to query its own tables during this routine.

See Also
hook_install()
hook_schema()
hook_modules_uninstalled()

References file_default_scheme(), and file_unmanaged_delete_recursive().

Here is the call graph for this function:

hook_update_projects_alter ( $projects)

Alter the list of projects before fetching data and comparing versions.

Most modules will never need to implement this hook. It is for advanced interaction with the Update Manager module. The primary use-case for this hook is to add projects to the list; for example, to provide update status data on disabled modules and themes. A contributed module might want to hide projects from the list; for example, if there is a site-specific module that doesn't have any official releases, that module could remove itself from this list to avoid "No available releases found" warnings on the available updates report. In rare cases, a module might want to alter the data associated with a project already in the list.

Parameters
$projectsReference to an array of the projects installed on the system. This includes all the metadata documented in the comments below for each project (either module or theme) that is currently enabled. The array is initially populated inside ::getProjects() with the help of ->processInfoList(), so look there for examples of how to populate the array with real values.
See Also
::getProjects()
->processInfoList()
hook_update_status_alter ( $projects)

Alter the information about available updates for projects.

Parameters
$projectsReference to an array of information about available updates to each project installed on the system.
See Also
update_calculate_project_data()

References Drupal\config(), and t().

Here is the call graph for this function:

hook_user_cancel (   $edit,
  $account,
  $method 
)

Act on user account cancellations.

This hook is invoked from user_cancel() before a user account is canceled. Depending on the account cancellation method, the module should either do nothing, unpublish content, or anonymize content. See user_cancel_methods() for the list of default account cancellation methods provided by User module. Modules may add further methods via hook_user_cancel_methods_alter().

This hook is NOT invoked for the 'user_cancel_delete' account cancellation method. To react to that method, implement hook_ENTITY_TYPE_predelete() or hook_ENTITY_TYPE_delete() for user entities instead.

Expensive operations should be added to the global account cancellation batch by using batch_set().

Parameters
array$editThe array of form values submitted by the user.
\Drupal\Core\Session\AccountInterface$accountThe user object on which the operation is being performed.
string$methodThe account cancellation method.
See Also
user_cancel_methods()
hook_user_cancel_methods_alter()

References db_update(), and Drupal\entityQuery().

Here is the call graph for this function:

hook_user_cancel_methods_alter ( $methods)

Modify account cancellation methods.

By implementing this hook, modules are able to add, customize, or remove account cancellation methods. All defined methods are turned into radio button form elements by user_cancel_methods() after this hook is invoked. The following properties can be defined for each method:

  • title: The radio button's title.
  • description: (optional) A description to display on the confirmation form if the user is not allowed to select the account cancellation method. The description is NOT used for the radio button, but instead should provide additional explanation to the user seeking to cancel their account.
  • access: (optional) A boolean value indicating whether the user can access a method. If 'access' is defined, the method cannot be configured as default method.
Parameters
array$methodsAn array containing user account cancellation methods, keyed by method id.
See Also
user_cancel_methods()

References Drupal\currentUser(), and t().

Here is the call graph for this function:

hook_user_format_name_alter ( $name,
  $account 
)

Alter the username that is displayed for a user.

Called by $account->getDisplayName() to allow modules to alter the username that is displayed. Can be used to ensure user privacy in situations where $account->name is too revealing.

Parameters
string$nameThe string that $account->getDisplayName() will return.
$accountThe account object passed to user_format_name().
See Also
$account->getDisplayName()

References t().

Here is the call graph for this function:

hook_user_login (   $account)

The user just logged in.

Parameters
object$accountThe user object on which the operation was just performed.

References Drupal\config(), Drupal\destination(), and t().

Here is the call graph for this function:

hook_user_logout (   $account)

The user just logged out.

Parameters
$accountThe user object on which the operation was just performed.

References db_insert().

Here is the call graph for this function:

hook_validation_constraint_alter ( array &  $definitions)

Alter validation constraint plugin definitions.

Parameters
array[]$definitions The array of validation constraint definitions, keyed by plugin ID.
See Also
hook_verify_update_archive (   $project,
  $archive_file,
  $directory 
)

Verify an archive after it has been downloaded and extracted.

Parameters
string$projectThe short name of the project that has been downloaded.
string$archive_fileThe filename of the unextracted archive.
string$directoryThe directory that the archive was extracted into.
Returns
If there are any problems, return an array of error messages. If there are no problems, return an empty array.
See Also
update_manager_archive_verify()

References t().

Here is the call graph for this function:

hook_views_analyze ( Drupal\views\ViewExecutable  $view)

Analyze a view to provide warnings about its configuration.

Parameters
\Drupal\views\ViewExecutable$viewThe view being executed.
Returns
array Array of warning messages built by Analyzer::formatMessage to be displayed to the user following analysis of the view.

References Analyzer\formatMessage(), and t().

Here is the call graph for this function:

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 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 ::viewsData()->get().

Returns
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.
See Also
hook_views_data_alter()

References t().

Here is the call graph for this function:

hook_views_data_alter ( array &  $data)

Alter the table and field information from hook_views_data().

Parameters
array$dataAn array of all information about Views tables and fields, collected from hook_views_data(), passed by reference.
See Also
hook_views_data()

References t().

Here is the call graph for this function:

hook_views_form_substitutions ( )

Replace special strings when processing a view with form elements.

Returns
array An associative array where each key is a string to be replaced, and the corresponding value is its replacement. The value will be escaped unless it is already marked safe.
hook_views_post_build ( ViewExecutable  $view)

Act on the view immediately after the query is built.

Output can be added to the view by setting $view->attachment_before and $view->attachment_after.

Parameters
\Drupal\views\ViewExecutable$viewThe view object about to be processed.
See Also
hook_views_post_execute ( ViewExecutable  $view)

Act on the view immediately after the query has been executed.

At this point the query has been executed, but the preRender() phase has not yet happened for handlers.

Output can be added to the view by setting $view->attachment_before and $view->attachment_after.

Parameters
\Drupal\views\ViewExecutable$viewThe view object about to be processed.
See Also

References t().

Here is the call graph for this function:

hook_views_pre_build ( ViewExecutable  $view)

Act on the view before the query is built, but after displays are attached.

Output can be added to the view by setting $view->attachment_before and $view->attachment_after.

Parameters
\Drupal\views\ViewExecutable$viewThe view object about to be processed.
See Also
hook_views_pre_execute ( ViewExecutable  $view)

Act on the view after the query is built and just before it is executed.

Output can be added to the view by setting $view->attachment_before and $view->attachment_after.

Parameters
\Drupal\views\ViewExecutable$viewThe view object about to be processed.
See Also

References Drupal\currentUser(), and t().

Here is the call graph for this function:

hook_views_pre_render ( ViewExecutable  $view)

Act on the view immediately before rendering it.

At this point the query has been executed, and the preRender() phase has already happened for handlers, so all data should be available. This hook can be used by themes.

Output can be added to the view by setting $view->attachment_before and $view->attachment_after.

Parameters
\Drupal\views\ViewExecutable$viewThe view object about to be processed.
See Also
hook_views_pre_view ( ViewExecutable  $view,
  $display_id,
array &  $args 
)

Alter a view at the very beginning of Views processing.

Output can be added to the view by setting $view->attachment_before and $view->attachment_after.

Parameters
\Drupal\views\ViewExecutable$viewThe view object about to be processed.
string$display_idThe machine name of the active display.
array$argsAn array of arguments passed into the view.
See Also

References Drupal\currentUser().

Here is the call graph for this function:

hook_views_query_substitutions ( ViewExecutable  $view)

Replace special strings in the query before it is executed.

The idea is that certain dynamic values can be placed in a query when it is built, and substituted at run-time, allowing the query to be cached and still work correctly when executed.

Parameters
\Drupal\views\ViewExecutable$viewThe View being executed.
Returns
array An associative array where each key is a string to be replaced, and the corresponding value is its replacement. The strings to replace are often surrounded with '***', as illustrated in the example implementation, to avoid collisions with other values in the query.

References Drupal\languageManager(), and Drupal\VERSION.

Here is the call graph for this function: