diff --git a/core/modules/system/core.api.php b/core/modules/system/core.api.php
deleted file mode 100644
index 14c894a..0000000
--- a/core/modules/system/core.api.php
+++ /dev/null
@@ -1,2230 +0,0 @@
-get('system.cron_last');
- * // Set the cron run time to the current request time.
- * $state->set('system.cron_last', REQUEST_TIME);
- * @endcode
- *
- * For more on the State API, see https://drupal.org/developing/api/8/state
- * @}
- */
-
-/**
- * @defgroup config_api Configuration API
- * @{
- * Information about the Configuration API.
- *
- * The Configuration API is one of several methods in Drupal for storing
- * information. See the @link info_types Information types topic @endlink for
- * an overview of the different types of information. The sections below have
- * more information about the configuration API; see
- * https://drupal.org/developing/api/8/configuration for more details.
- *
- * @section sec_storage Configuration storage
- * In Drupal, there is a concept of the "active" configuration, which is the
- * configuration that is currently in use for a site. The storage used for the
- * active configuration is configurable: it could be in the database, in files
- * in a particular directory, or in other storage backends; the default storage
- * is in the database. Module developers must use the configuration API to
- * access the active configuration, rather than being concerned about the
- * details of where and how it is stored.
- *
- * Configuration is divided into individual objects, each of which has a
- * unique name or key. Some modules will have only one configuration object,
- * typically called 'mymodule.settings'; some modules will have many. Within
- * a configuration object, configuration settings have data types (integer,
- * string, Boolean, etc.) and settings can also exist in a nested hierarchy,
- * known as a "mapping".
- *
- * Configuration can also be overridden on a global, per-language, or
- * per-module basis. See https://www.drupal.org/node/1928898 for more
- * information.
- *
- * @section sec_yaml Configuration YAML files
- * Whether or not configuration files are being used for the active
- * configuration storage on a particular site, configuration files are always
- * used for:
- * - Defining the default configuration for a module, which is imported to the
- * active storage when the module is enabled. Note that changes to this
- * default configuration after a module is already enabled have no effect;
- * to make a configuration change after a module is enabled, you would need
- * to uninstall/reinstall or use a hook_update_N() function.
- * - Exporting and importing configuration.
- *
- * The file storage format for configuration information in Drupal is
- * @link http://en.wikipedia.org/wiki/YAML YAML files. @endlink Configuration is
- * divided into files, each containing one configuration object. The file name
- * for a configuration object is equal to the unique name of the configuration,
- * with a '.yml' extension. The default configuration files for each module are
- * placed in the config/install directory under the top-level module directory,
- * so look there in most Core modules for examples.
- *
- * @section sec_schema Configuration schema and translation
- * Each configuration file has a specific structure, which is expressed as a
- * YAML-based configuration schema. The configuration schema details the
- * structure of the configuration, its data types, and which of its values need
- * to be translatable. Each module needs to define its configuration schema in
- * files in the config/schema directory under the top-level module directory, so
- * look there in most Core modules for examples.
- *
- * Configuration can be internationalized; see the
- * @link i18n Internationalization topic @endlink for more information. Data
- * types label, text, and date_format in configuration schema are translatable;
- * string is non-translatable text (the 'translatable' property on a schema
- * data type definition indicates that it is translatable).
- *
- * @section sec_simple Simple configuration
- * The simple configuration API should be used for information that will always
- * have exactly one copy or version. For instance, if your module has a
- * setting that is either on or off, then this is only defined once, and it
- * would be a Boolean-valued simple configuration setting.
- *
- * The first task in using the simple configuration API is to define the
- * configuration file structure, file name, and schema of your settings (see
- * @ref sec_yaml above). Once you have done that, you can retrieve the
- * active configuration object that corresponds to configuration file
- * mymodule.foo.yml with a call to:
- * @code
- * $config = \Drupal::config('mymodule.foo');
- * @endcode
- *
- * This will be an object of class \Drupal\Core\Config\Config, which has methods
- * for getting and setting configuration information. For instance, if your
- * YAML file structure looks like this:
- * @code
- * enabled: '0'
- * bar:
- * baz: 'string1'
- * boo: 34
- * @endcode
- * you can make calls such as:
- * @code
- * // Get a single value.
- * $enabled = $config->get('enabled');
- * // Get an associative array.
- * $bar = $config->get('bar');
- * // Get one element of the array.
- * $bar_baz = $config->get('bar.baz');
- * // Update a value. Nesting works the same as get().
- * $config->set('bar.baz', 'string2');
- * // Nothing actually happens with set() until you call save().
- * $config->save();
- * @endcode
- *
- * @section sec_entity Configuration entities
- * In contrast to the simple configuration settings described in the previous
- * section, if your module allows users to create zero or more items (where
- * "items" are things like content type definitions, view definitions, and the
- * like), then you need to define a configuration entity type to store your
- * configuration. Creating an entity type, loading entities, and querying them
- * are outlined in the @link entity_api Entity API topic. @endlink Here are a
- * few additional steps and notes specific to configuration entities:
- * - For examples, look for classes that implement
- * \Drupal\Core\Config\Entity\ConfigEntityInterface -- one good example is
- * the \Drupal\user\Entity\Role entity type.
- * - In the entity type annotation, you will need to define a 'config_prefix'
- * string. When Drupal stores a configuration item, it will be given a name
- * composed of your module name, your chosen config prefix, and the ID of
- * the individual item, separated by '.'. For example, in the Role entity,
- * the config prefix is 'role', so one configuration item might be named
- * user.role.anonymous, with configuration file user.role.anonymous.yml.
- * - You will need to define the schema for your configuration in your
- * modulename.schema.yml file, with an entry for 'modulename.config_prefix.*'.
- * For example, for the Role entity, the file user.schema.yml has an entry
- * user.role.*; see @ref sec_yaml above for more information.
- * - Your module may also provide a few configuration items to be installed by
- * default, by adding configuration files to the module's config/install
- * directory; see @ref sec_yaml above for more information.
- * - Some configuration entities have dependencies on other configuration
- * entities, and module developers need to consider this so that configuration
- * can be imported, uninstalled, and synchronized in the right order. For
- * example, a field display configuration entity would need to depend on
- * field configuration, which depends on field and bundle configuration.
- * Configuration entity classes expose dependencies by overriding the
- * \Drupal\Core\Config\Entity\ConfigEntityInterface::calculateDependencies()
- * method.
- * - On routes for paths staring with '/admin' or otherwise designated as
- * administration paths (such as node editing when it is set as an admin
- * operation), if they have configuration entity placeholders, configuration
- * entities are normally loaded in their original language, without
- * translations or other overrides. This is usually desirable, because most
- * admin paths are for editing configuration, and you need that to be in the
- * source language and to lack possibly dynamic overrides. If for some reason
- * you need to have your configuration entity loaded in the currently-selected
- * language on an admin path (for instance, if you go to
- * example.com/es/admin/your_path and you need the entity to be in Spanish),
- * then you can add a 'with_config_overrides' parameter option to your route.
- * The same applies if you need to load the entity with overrides (or
- * translated) on an admin path like '/node/add/article' (when configured to
- * be an admin path). Here's an example using the configurable_language config
- * entity:
- * @code
- * mymodule.myroute:
- * path: '/admin/mypath/{configurable_language}'
- * defaults:
- * _controller: '\Drupal\mymodule\MyController::myMethod'
- * options:
- * parameters:
- * configurable_language:
- * type: entity:configurable_language
- * with_config_overrides: TRUE
- * @endcode
- * With the route defined this way, the $configurable_language parameter to
- * your controller method will come in translated to the current language.
- * Without the parameter options section, it would be in the original
- * language, untranslated.
- *
- * @see i18n
- *
- * @}
- */
-
-/**
- * @defgroup cache Cache API
- * @{
- * Information about the Drupal Cache API
- *
- * @section basics Basics
- *
- * Note: If not specified, all of the methods mentioned here belong to
- * \Drupal\Core\Cache\CacheBackendInterface.
- *
- * The Cache API is used to store data that takes a long time to
- * compute. Caching can be permanent, temporary, or valid for a certain
- * timespan, and the cache can contain any type of data.
- *
- * To use the Cache API:
- * - Request a cache object through \Drupal::cache() or by injecting a cache
- * service.
- * - Define a Cache ID (cid) value for your data. A cid is a string, which must
- * contain enough information to uniquely identify the data. For example, if
- * your data contains translated strings, then your cid value must include the
- * current interface language.
- * - Call the get() method to attempt a cache read, to see if the cache already
- * contains your data.
- * - If your data is not already in the cache, compute it and add it to the
- * cache using the set() method. The third argument of set() can be used to
- * control the lifetime of your cache item.
- *
- * Example:
- * @code
- * $cid = 'mymodule_example:' . \Drupal::languageManager()->getCurrentLanguage()->getId();
- *
- * $data = NULL;
- * if ($cache = \Drupal::cache()->get($cid)) {
- * $data = $cache->data;
- * }
- * else {
- * $data = my_module_complicated_calculation();
- * \Drupal::cache()->set($cid, $data);
- * }
- * @endcode
- *
- * Note the use of $data and $cache->data in the above example. Calls to
- * \Drupal::cache()->get() return a record that contains the information stored
- * by \Drupal::cache()->set() in the data property as well as additional meta
- * information about the cached data. In order to make use of the cached data
- * you can access it via $cache->data.
- *
- * @section bins Cache bins
- *
- * Cache storage is separated into "bins", each containing various cache items.
- * Each bin can be configured separately; see @ref configuration.
- *
- * When you request a cache object, you can specify the bin name in your call to
- * \Drupal::cache(). Alternatively, you can request a bin by getting service
- * "cache.nameofbin" from the container. The default bin is called "default", with
- * service name "cache.default", it is used to store common and frequently used
- * caches.
- *
- * Other common cache bins are the following:
- * - bootstrap: Small caches needed for the bootstrap on every request.
- * - render: Contains cached HTML strings like cached pages and blocks, can
- * grow to large size.
- * - data: Contains data that can vary by path or similar context.
- * - discovery: Contains cached discovery data for things such as plugins,
- * views_data, or YAML discovered data such as library info.
- *
- * A module can define a cache bin by defining a service in its
- * modulename.services.yml file as follows (substituting the desired name for
- * "nameofbin"):
- * @code
- * cache.nameofbin:
- * class: Drupal\Core\Cache\CacheBackendInterface
- * tags:
- * - { name: cache.bin }
- * factory_method: get
- * factory_service: cache_factory
- * arguments: [nameofbin]
- * @endcode
- * See the @link container Services topic @endlink for more on defining
- * services.
- *
- * @section delete Deletion
- *
- * There are two ways to remove an item from the cache:
- * - Deletion (using delete(), deleteMultiple() or deleteAll()) permanently
- * removes the item from the cache.
- * - Invalidation (using invalidate(), invalidateMultiple() or invalidateAll())
- * is a "soft" delete that only marks items as "invalid", meaning "not fresh"
- * or "not fresh enough". Invalid items are not usually returned from the
- * cache, so in most ways they behave as if they have been deleted. However,
- * it is possible to retrieve invalid items, if they have not yet been
- * permanently removed by the garbage collector, by passing TRUE as the second
- * argument for get($cid, $allow_invalid).
- *
- * Use deletion if a cache item is no longer useful; for instance, if the item
- * contains references to data that has been deleted. Use invalidation if the
- * cached item may still be useful to some callers until it has been updated
- * with fresh data. The fact that it was fresh a short while ago may often be
- * sufficient.
- *
- * Invalidation is particularly useful to protect against stampedes. Rather than
- * having multiple concurrent requests updating the same cache item when it
- * expires or is deleted, there can be one request updating the cache, while the
- * other requests can proceed using the stale value. As soon as the cache item
- * has been updated, all future requests will use the updated value.
- *
- * @section tags Cache Tags
- *
- * The fourth argument of the set() method can be used to specify cache tags,
- * which are used to identify which data is included in each cache item. A cache
- * item can have multiple cache tags (an array of cache tags), and each cache
- * tag is a string. The convention is to generate cache tags of the form
- * [prefix]:[suffix]. Usually, you'll want to associate the cache tags of
- * entities, or entity listings. You won't have to manually construct cache tags
- * for them — just get their cache tags via
- * \Drupal\Core\Entity\EntityInterface::getCacheTags() and
- * \Drupal\Core\Entity\EntityTypeInterface::getListCacheTags().
- * Data that has been tagged can be invalidated as a group: no matter the Cache
- * ID (cid) of the cache item, no matter in which cache bin a cache item lives;
- * as long as it is tagged with a certain cache tag, it will be invalidated.
- *
- * Because of that, cache tags are a solution to the cache invalidation problem:
- * - For caching to be effective, each cache item must only be invalidated when
- * absolutely necessary. (i.e. maximizing the cache hit ratio.)
- * - For caching to be correct, each cache item that depends on a certain thing
- * must be invalidated whenever that certain thing is modified.
- *
- * A typical scenario: a user has modified a node that appears in two views,
- * three blocks and on twelve pages. Without cache tags, we couldn't possibly
- * know which cache items to invalidate, so we'd have to invalidate everything:
- * we had to sacrifice effectiveness to achieve correctness. With cache tags, we
- * can have both.
- *
- * Example:
- * @code
- * // A cache item with nodes, users, and some custom module data.
- * $tags = array(
- * 'my_custom_tag',
- * 'node:1',
- * 'node:3',
- * 'user:7',
- * );
- * \Drupal::cache()->set($cid, $data, CacheBackendInterface::CACHE_PERMANENT, $tags);
- *
- * // Invalidate all cache items with certain tags.
- * \Drupal\Core\Cache\Cache::invalidateTags(array('user:1'));
- * @endcode
- *
- * Drupal is a content management system, so naturally you want changes to your
- * content to be reflected everywhere, immediately. That's why we made sure that
- * every entity type in Drupal 8 automatically has support for cache tags: when
- * you save an entity, you can be sure that the cache items that have the
- * corresponding cache tags will be invalidated.
- * This also is the case when you define your own entity types: you'll get the
- * exact same cache tag invalidation as any of the built-in entity types, with
- * the ability to override any of the default behavior if needed.
- * See \Drupal\Core\Entity\EntityInterface::getCacheTags(),
- * \Drupal\Core\Entity\EntityTypeInterface::getListCacheTags(),
- * \Drupal\Core\Entity\Entity::invalidateTagsOnSave() and
- * \Drupal\Core\Entity\Entity::invalidateTagsOnDelete().
- *
- * @section configuration Configuration
- *
- * By default cached data is stored in the database. This can be configured
- * though so that all cached data, or that of an individual cache bin, uses a
- * different cache backend, such as APC or Memcache, for storage.
- *
- * In a settings.php file, you can override the service used for a particular
- * cache bin. For example, if your service implementation of
- * \Drupal\Core\Cache\CacheBackendInterface was called cache.custom, the
- * following line would make Drupal use it for the 'cache_render' bin:
- * @code
- * $settings['cache']['bins']['render'] = 'cache.custom';
- * @endcode
- *
- * Additionally, you can register your cache implementation to be used by
- * default for all cache bins with:
- * @code
- * $settings['cache']['default'] = 'cache.custom';
- * @endcode
- *
- * @see https://drupal.org/node/1884796
- * @}
- */
-
-/**
- * @defgroup user_api User accounts, permissions, and roles
- * @{
- * API for user accounts, access checking, roles, and permissions.
- *
- * @section sec_overview Overview and terminology
- * Drupal's permission system is based on the concepts of accounts, roles,
- * and permissions.
- *
- * Users (site visitors) have accounts, which include a user name, an email
- * address, a password (or some other means of authentication), and possibly
- * other fields (if defined on the site). Anonymous users have an implicit
- * account that does not have a real user name or any account information.
- *
- * Each user account is assigned one or more roles. The anonymous user account
- * automatically has the anonymous user role; real user accounts
- * automatically have the authenticated user role, plus any roles defined on
- * the site that they have been assigned.
- *
- * Each role, including the special anonymous and authenticated user roles, is
- * granted one or more named permissions, which allow them to perform certain
- * tasks or view certain content on the site. It is possible to designate a
- * role to be the "administrator" role; if this is set up, this role is
- * automatically granted all available permissions whenever a module is
- * enabled that defines permissions.
- *
- * All code in Drupal that allows users to perform tasks or view content must
- * check that the current user has the correct permission before allowing the
- * action. In the standard case, access checking consists of answering the
- * question "Does the current user have permission 'foo'?", and allowing or
- * denying access based on the answer. Note that access checking should nearly
- * always be done at the permission level, not by checking for a particular role
- * or user ID, so that site administrators can set up user accounts and roles
- * appropriately for their particular sites.
- *
- * @section sec_define Defining permissions
- * Modules define permissions via a $module.permissions.yml file. See
- * \Drupal\user\PermissionHandler for documentation of permissions.yml files.
- *
- * @section sec_access Access permission checking
- * Depending on the situation, there are several methods for ensuring that
- * access checks are done properly in Drupal:
- * - Routes: When you register a route, include a 'requirements' section that
- * either gives the machine name of the permission that is needed to visit the
- * URL of the route, or tells Drupal to use an access check method or service
- * to check access. See the @link menu Routing topic @endlink for more
- * information.
- * - Entities: Access for various entity operations is designated either with
- * simple permissions or access control handler classes in the entity
- * annotation. See the @link entity_api Entity API topic @endlink for more
- * information.
- * - Other code: There is a 'current_user' service, which can be injected into
- * classes to provide access to the current user account (see the
- * @link container Services and Dependency Injection topic @endlink for more
- * information on dependency injection). In code that cannot use dependency
- * injection, you can access this service and retrieve the current user
- * account object by calling \Drupal::currentUser(). Once you have a user
- * object for the current user (implementing \Drupal\user\UserInterface), you
- * can call inherited method
- * \Drupal\Core\Session\AccountInterface::hasPermission() to check
- * permissions, or pass this object into other functions/methods.
- * - Forms: Each element of a form array can have a Boolean '#access' property,
- * which determines whether that element is visible and/or usable. This is a
- * common need in forms, so the current user service (described above) is
- * injected into the form base class as method
- * \Drupal\Core\Form\FormBase::currentUser().
- *
- * @section sec_entities User and role objects
- * User objects in Drupal are entity items, implementing
- * \Drupal\user\UserInterface. Role objects in Drupal are also entity items,
- * implementing \Drupal\user\RoleInterface. See the
- * @link entity_api Entity API topic @endlink for more information about
- * entities in general (including how to load, create, modify, and query them).
- *
- * Roles often need to be manipulated in automated test code, such as to add
- * permissions to them. Here's an example:
- * @code
- * $role = \Drupal\user\Entity\Role::load('authenticated');
- * $role->grantPermission('access comments');
- * $role->save();
- * @endcode
- *
- * Other important interfaces:
- * - \Drupal\Core\Session\AccountInterface: The part of UserInterface that
- * deals with access checking. In writing code that checks access, your
- * method parameters should use this interface, not UserInterface.
- * - \Drupal\Core\Session\AccountProxyInterface: The interface for the
- * current_user service (described above).
- * @}
- */
-
-/**
- * @defgroup container Services and Dependency Injection Container
- * @{
- * Overview of the Dependency Injection Container and Services.
- *
- * @section sec_overview Overview of container, injection, and services
- * The Services and Dependency Injection Container concepts have been adopted by
- * Drupal from the @link http://symfony.com/ Symfony framework. @endlink A
- * "service" (such as accessing the database, sending email, or translating user
- * interface text) is defined (given a name and an interface or at least a
- * class that defines the methods that may be called), and a default class is
- * defined to provide the service. These two steps must be done together, and
- * can be done by Drupal Core or a module. Other modules can then define
- * alternative classes to provide the same services, overriding the default
- * classes. Classes and functions that need to use the service should always
- * instantiate the class via the dependency injection container (also known
- * simply as the "container"), rather than instantiating a particular service
- * provider class directly, so that they get the correct class (default or
- * overridden).
- *
- * See https://drupal.org/node/2133171 for more detailed information on
- * services and the dependency injection container.
- *
- * @section sec_discover Discovering existing services
- * Drupal core defines many core services in the core.services.yml file (in the
- * top-level core directory). Some Drupal Core modules and contributed modules
- * also define services in modulename.services.yml files. API reference sites
- * (such as https://api.drupal.org) generate lists of all existing services from
- * these files, or you can look through the individual files manually.
- *
- * A typical service definition in a *.services.yml file looks like this:
- * @code
- * path.alias_manager:
- * class: Drupal\Core\Path\AliasManager
- * arguments: ['@path.crud', '@path.alias_whitelist', '@language_manager']
- * @endcode
- * Some services use other services as factories; a typical service definition
- * is:
- * @code
- * cache.entity:
- * class: Drupal\Core\Cache\CacheBackendInterface
- * tags:
- * - { name: cache.bin }
- * factory_method: get
- * factory_service: cache_factory
- * arguments: [entity]
- * @endcode
- *
- * The first line of a service definition gives the unique machine name of the
- * service. This is often prefixed by the module name if provided by a module;
- * however, by convention some service names are prefixed by a group name
- * instead, such as cache.* for cache bins and plugin.manager.* for plugin
- * managers.
- *
- * The class line either gives the default class that provides the service, or
- * if the service uses a factory class, the interface for the service. If the
- * class depends on other services, the arguments line lists the machine
- * names of the dependencies (preceded by '@'); objects for each of these
- * services are instantiated from the container and passed to the class
- * constructor when the service class is instantiated. Other arguments can also
- * be passed in; see the section at https://drupal.org/node/2133171 for more
- * detailed information.
- *
- * Services using factories can be defined as shown in the above example, if the
- * factory is itself a service. The factory can also be a class; details of how
- * to use service factories can be found in the section at
- * https://drupal.org/node/2133171.
- *
- * @section sec_container Accessing a service through the container
- * As noted above, if you need to use a service in your code, you should always
- * instantiate the service class via a call to the container, using the machine
- * name of the service, so that the default class can be overridden. There are
- * several ways to make sure this happens:
- * - For service-providing classes, see other sections of this documentation
- * describing how to pass services as arguments to the constructor.
- * - Plugin classes, controllers, and similar classes have create() or
- * createInstance() methods that are used to create an instance of the class.
- * These methods come from different interfaces, and have different
- * arguments, but they all include an argument $container of type
- * \Symfony\Component\DependencyInjection\ContainerInterface.
- * If you are defining one of these classes, in the create() or
- * createInstance() method, call $container->get('myservice.name') to
- * instantiate a service. The results of these calls are generally passed to
- * the class constructor and saved as member variables in the class.
- * - For functions and class methods that do not have access to either of
- * the above methods of dependency injection, you can use service location to
- * access services, via a call to the global \Drupal class. This class has
- * special methods for accessing commonly-used services, or you can call a
- * generic method to access any service. Examples:
- * @code
- * // Retrieve the entity.manager service object (special method exists).
- * $manager = \Drupal::entityManager();
- * // Retrieve the service object for machine name 'foo.bar'.
- * $foobar = \Drupal::service('foo.bar');
- * @endcode
- *
- * As a note, you should always use dependency injection (via service arguments
- * or create()/createInstance() methods) if possible to instantiate services,
- * rather than service location (via the \Drupal class), because:
- * - Dependency injection facilitates writing unit tests, since the container
- * argument can be mocked and the create() method can be bypassed by using
- * the class constructor. If you use the \Drupal class, unit tests are much
- * harder to write and your code has more dependencies.
- * - Having the service interfaces on the class constructor and member variables
- * is useful for IDE auto-complete and self-documentation.
- *
- * @section sec_define Defining a service
- * If your module needs to define a new service, here are the steps:
- * - Choose a unique machine name for your service. Typically, this should
- * start with your module name. Example: mymodule.myservice.
- * - Create a PHP interface to define what your service does.
- * - Create a default class implementing your interface that provides your
- * service. If your class needs to use existing services (such as database
- * access), be sure to make these services arguments to your class
- * constructor, and save them in member variables. Also, if the needed
- * services are provided by other modules and not Drupal Core, you'll want
- * these modules to be dependencies of your module.
- * - Add an entry to a modulename.services.yml file for the service. See
- * @ref sec_discover above, or existing *.services.yml files in Core, for the
- * syntax; it will start with your machine name, refer to your default class,
- * and list the services that need to be passed into your constructor.
- *
- * Services can also be defined dynamically, as in the
- * \Drupal\Core\CoreServiceProvider class, but this is less common for modules.
- *
- * @section sec_tags Service tags
- * Some services have tags, which are defined in the service definition. See
- * @link service_tag Service Tags @endlink for usage.
- *
- * @section sec_injection Overriding the default service class
- * Modules can override the default classes used for services. Here are the
- * steps:
- * - Define a class in the top-level namespace for your module
- * (Drupal\my_module), whose name is the camel-case version of your module's
- * machine name followed by "ServiceProvider" (for example, if your module
- * machine name is my_module, the class must be named
- * MyModuleServiceProvider).
- * - The class needs to implement
- * \Drupal\Core\DependencyInjection\ServiceModifierInterface, which is
- * typically done by extending
- * \Drupal\Core\DependencyInjection\ServiceProviderBase.
- * - The class needs to contain one method: alter(). This method does the
- * actual work of telling Drupal to use your class instead of the default.
- * Here's an example:
- * @code
- * public function alter(ContainerBuilder $container) {
- * // Override the language_manager class with a new class.
- * $definition = $container->getDefinition('language_manager');
- * $definition->setClass('Drupal\my_module\MyLanguageManager');
- * }
- * @endcode
- * Note that $container here is an instance of
- * \Drupal\Core\DependencyInjection\ContainerBuilder.
- *
- * @see https://drupal.org/node/2133171
- * @see core.services.yml
- * @see \Drupal
- * @see \Symfony\Component\DependencyInjection\ContainerInterface
- * @see plugin_api
- * @see menu
- * @}
- */
-
-/**
- * @defgroup typed_data Typed Data API
- * @{
- * API for describing data based on a set of available data types.
- *
- * The Typed Data API was created to provide developers with a consistent
- * interface for interacting with data, as well as an API for metadata
- * (information about the data, such as the data type, whether it is
- * translatable, and who can access it). The Typed Data API is used in several
- * Drupal sub-systems, such as the Entity Field API and Configuration API.
- *
- * See https://drupal.org/node/1794140 for more information about the Typed
- * Data API.
- *
- * @section interfaces Interfaces and classes in the Typed Data API
- * There are several basic interfaces in the Typed Data API, representing
- * different types of data:
- * - \Drupal\Core\TypedData\PrimitiveInterface: Used for primitive data, such
- * as strings, numeric types, etc. Drupal provides primitive types for
- * integers, strings, etc. based on this interface, and you should
- * not ever need to create new primitive types.
- * - \Drupal\Core\TypedData\TypedDataInterface: Used for single pieces of data,
- * with some information about its context. Abstract base class
- * \Drupal\Core\TypedData\TypedData is a useful starting point, and contains
- * documentation on how to extend it.
- * - \Drupal\Core\TypedData\ComplexDataInterface: Used for complex data, which
- * contains named and typed properties; extends TypedDataInterface. Examples
- * of complex data include content entities and field items. See the
- * @link entity_api Entity API topic @endlink for more information about
- * entities; for most complex data, developers should use entities.
- * - \Drupal\Core\TypedData\ListInterface: Used for a sequential list of other
- * typed data. Class \Drupal\Core\TypedData\Plugin\DataType\ItemList is a
- * generic implementation of this interface, and it is used by default for
- * data declared as a list of some other data type. You can also define a
- * custom list class, in which case ItemList is a useful base class.
- *
- * @section defining Defining data types
- * To define a new data type:
- * - Create a class that implements one of the Typed Data interfaces.
- * Typically, you will want to extend one of the classes listed in the
- * section above as a starting point.
- * - Make your class into a DataType plugin. To do that, put it in namespace
- * \Drupal\yourmodule\Plugin\DataType (where "yourmodule" is your module's
- * short name), and add annotation of type
- * \Drupal\Core\TypedData\Annotation\DataType to the documentation header.
- * See the @link plugin_api Plugin API topic @endlink and the
- * @link annotation Annotations topic @endlink for more information.
- *
- * @section using Using data types
- * The data types of the Typed Data API can be used in several ways, once they
- * have been defined:
- * - In the Field API, data types can be used as the class in the property
- * definition of the field. See the @link field Field API topic @endlink for
- * more information.
- * - In configuration schema files, you can use the unique ID ('id' annotation)
- * from any DataType plugin class as the 'type' value for an entry. See the
- * @link config_api Confuration API topic @endlink for more information.
- * @}
- */
-
-/**
- * @defgroup testing Automated tests
- * @{
- * Overview of PHPUnit tests and Simpletest tests.
- *
- * The Drupal project has embraced a philosophy of using automated tests,
- * consisting of both unit tests (which test the functionality of classes at a
- * low level) and functional tests (which test the functionality of Drupal
- * systems at a higher level, usually involving web output). The goal is to
- * have test coverage for all or most of the components and features, and to
- * run the automated tests before any code is changed or added, to make sure
- * it doesn't break any existing functionality (regression testing).
- *
- * In order to implement this philosophy, developers need to do the following:
- * - When making a patch to fix a bug, make sure that the bug fix patch includes
- * a test that fails without the code change and passes with the code change.
- * This helps reviewers understand what the bug is, demonstrates that the code
- * actually fixes the bug, and ensures the bug will not reappear due to later
- * code changes.
- * - When making a patch to implement a new feature, include new unit and/or
- * functional tests in the patch. This serves to both demonstrate that the
- * code actually works, and ensure that later changes do not break the new
- * functionality.
- *
- * @section write_unit Writing PHPUnit tests for classes
- * PHPUnit tests for classes are written using the industry-standard PHPUnit
- * framework. Use a PHPUnit test to test functionality of a class if the Drupal
- * environment (database, settings, etc.) and web browser are not needed for the
- * test, or if the Drupal environment can be replaced by a "mock" object. To
- * write a PHPUnit test:
- * - Define a class that extends \Drupal\Tests\UnitTestCase.
- * - The class name needs to end in the word Test.
- * - The namespace must be a subspace/subdirectory of \Drupal\yourmodule\Tests,
- * where yourmodule is your module's machine name.
- * - The test class file must be named and placed under the yourmodule/tests/src
- * directory, according to the PSR-4 standard.
- * - Your test class needs a phpDoc comment block with a description and
- * a @group annotation, which gives information about the test.
- * - Methods in your test class whose names start with 'test' are the actual
- * test cases. Each one should test a logical subset of the functionality.
- * For more details, see:
- * - https://drupal.org/phpunit for full documentation on how to write PHPUnit
- * tests for Drupal.
- * - http://phpunit.de for general information on the PHPUnit framework.
- * - @link oo_conventions Object-oriented programming topic @endlink for more
- * on PSR-4, namespaces, and where to place classes.
- *
- * @section write_functional Writing functional tests
- * Functional tests are written using a Drupal-specific framework that is, for
- * historical reasons, known as "Simpletest". Use a Simpletest test to test the
- * functionality of sub-system of Drupal, if the functionality depends on the
- * Drupal database and settings, or to test the web output of Drupal. To
- * write a Simpletest test:
- * - For functional tests of the web output of Drupal, define a class that
- * extends \Drupal\simpletest\WebTestBase, which contains an internal web
- * browser and defines many helpful test assertion methods that you can use
- * in your tests. You can specify modules to be enabled by defining a
- * $modules member variable -- keep in mind that by default, WebTestBase uses
- * a "testing" install profile, with a minimal set of modules enabled.
- * - For functional tests that do not test web output, define a class that
- * extends \Drupal\simpletest\KernelTestBase. This class is much faster
- * than WebTestBase, because instead of making a full install of Drupal, it
- * uses an in-memory pseudo-installation (similar to what the installer and
- * update scripts use). To use this test class, you will need to create the
- * database tables you need and install needed modules manually.
- * - The namespace must be a subspace/subdirectory of \Drupal\yourmodule\Tests,
- * where yourmodule is your module's machine name.
- * - The test class file must be named and placed under the yourmodule/src/Tests
- * directory, according to the PSR-4 standard.
- * - Your test class needs a phpDoc comment block with a description and
- * a @group annotation, which gives information about the test.
- * - You may also override the default setUp() method, which can set be used to
- * set up content types and similar procedures.
- * - In some cases, you may need to write a test module to support your test;
- * put such modules under the yourmodule/tests/modules directory.
- * - Methods in your test class whose names start with 'test', and which have
- * no arguments, are the actual test cases. Each one should test a logical
- * subset of the functionality, and each one runs in a new, isolated test
- * environment, so it can only rely on the setUp() method, not what has
- * been set up by other test methods.
- * For more details, see:
- * - https://drupal.org/simpletest for full documentation on how to write
- * functional tests for Drupal.
- * - @link oo_conventions Object-oriented programming topic @endlink for more
- * on PSR-4, namespaces, and where to place classes.
- *
- * @section running Running tests
- * You can run both Simpletest and PHPUnit tests by enabling the core Testing
- * module (core/modules/simpletest). Once that module is enabled, tests can be
- * run using the core/scripts/run-tests.sh script, using
- * @link https://drupal.org/project/drush Drush @endlink, or from the Testing
- * module user interface.
- *
- * PHPUnit tests can also be run from the command line, using the PHPUnit
- * framework. See https://drupal.org/node/2116263 for more information.
- * @}
- */
-
-/**
- * @defgroup info_types Information types
- * @{
- * Types of information in Drupal.
- *
- * Drupal has several distinct types of information, each with its own methods
- * for storage and retrieval:
- * - Content: Information meant to be displayed on your site: articles, basic
- * pages, images, files, custom blocks, etc. Content is stored and accessed
- * using @link entity_api Entities @endlink.
- * - Session: Information about individual users' interactions with the site,
- * such as whether they are logged in. This is really "state" information, but
- * it is not stored the same way so it's a separate type here. Session
- * information is managed via the session_manager service in Drupal, which
- * implements \Drupal\Core\Session\SessionManagerInterface. See the
- * @link container Services topic @endlink for more information about
- * services.
- * - State: Information of a temporary nature, generally machine-generated and
- * not human-edited, about the current state of your site. Examples: the time
- * when Cron was last run, whether node access permissions need rebuilding,
- * etc. See @link state_api the State API topic @endlink for more information.
- * - Configuration: Information about your site that is generally (or at least
- * can be) human-edited, but is not Content, and is meant to be relatively
- * permanent. Examples: the name of your site, the content types and views
- * you have defined, etc. See
- * @link config_api the Configuration API topic @endlink for more information.
- *
- * @see cache
- * @see i18n
- * @}
- */
-
-/**
- * @defgroup extending Extending and altering Drupal
- * @{
- * Overview of extensions and alteration methods for Drupal.
- *
- * @section sec_types Types of extensions
- * Drupal's core behavior can be extended and altered via these three basic
- * types of extensions:
- * - Themes: Themes alter the appearance of Drupal sites. They can include
- * template files, which alter the HTML markup and other raw output of the
- * site; CSS files, which alter the styling applied to the HTML; and
- * JavaScript, Flash, images, and other files. For more information, see the
- * @link theme_render Theme system and render API topic @endlink and
- * https://drupal.org/theme-guide/8
- * - Modules: Modules add to or alter the behavior and functionality of Drupal,
- * by using one or more of the methods listed below. For more information
- * about creating modules, see https://drupal.org/developing/modules/8
- * - Installation profiles: Installation profiles can be used to
- * create distributions, which are complete specific-purpose packages of
- * Drupal including additional modules, themes, and data. For more
- * information, see https://www.drupal.org/developing/distributions.
- *
- * @section sec_alter Alteration methods for modules
- * Here is a list of the ways that modules can alter or extend Drupal's core
- * behavior, or the behavior of other modules:
- * - Hooks: Specially-named functions that a module defines, which are
- * discovered and called at specific times, usually to alter behavior or data.
- * See the @link hooks Hooks topic @endlink for more information.
- * - Plugins: Classes that a module defines, which are discovered and
- * instantiated at specific times to add functionality. See the
- * @link plugin_api Plugin API topic @endlink for more information.
- * - Entities: Special plugins that define entity types for storing new types
- * of content or configuration in Drupal. See the
- * @link entity_api Entity API topic @endlink for more information.
- * - Services: Classes that perform basic operations within Drupal, such as
- * accessing the database and sending email. See the
- * @link container Dependency Injection Container and Services topic @endlink
- * for more information.
- * - Routing: Providing or altering "routes", which are URLs that Drupal
- * responds to, or altering routing behavior with event listener classes.
- * See the @link menu Routing and menu topic @endlink for more information.
- * - Events: Modules can register as event subscribers; when an event is
- * dispatched, a method is called on each registered subscriber, allowing each
- * one to react. See the @link events Events topic @endlink for more
- * information.
- *
- * @section sec_sample *.info.yml files
- * Extensions must each be located in a directory whose name matches the short
- * name (or machine name) of the extension, and this directory must contain a
- * file named machine_name.info.yml (where machine_name is the machine name of
- * the extension). See \Drupal\Core\Extension\InfoParserInterface::parse() for
- * documentation of the format of .info.yml files.
- * @}
- */
-
-/**
- * @defgroup plugin_api Plugin API
- * @{
- * Using the Plugin API
- *
- * @section sec_overview Overview and terminology
- *
- * The basic idea of plugins is to allow a particular module or subsystem of
- * Drupal to provide functionality in an extensible, object-oriented way. The
- * controlling module or subsystem defines the basic framework (interface) for
- * the functionality, and other modules can create plugins (implementing the
- * interface) with particular behaviors. The controlling module instantiates
- * existing plugins as needed, and calls methods to invoke their functionality.
- * Examples of functionality in Drupal Core that use plugins include: the block
- * system (block types are plugins), the entity/field system (entity types,
- * field types, field formatters, and field widgets are plugins), the image
- * manipulation system (image effects and image toolkits are plugins), and the
- * search system (search page types are plugins).
- *
- * Plugins are grouped into plugin types, each generally defined by an
- * interface. Each plugin type is managed by a plugin manager service, which
- * uses a plugin discovery method to discover provided plugins of that type and
- * instantiate them using a plugin factory.
- *
- * Some plugin types make use of the following concepts or components:
- * - Plugin derivatives: Allows a single plugin class to present itself as
- * multiple plugins. Example: the Menu module provides a block for each
- * defined menu via a block plugin derivative.
- * - Plugin mapping: Allows a plugin class to map a configuration string to an
- * instance, and have the plugin automatically instantiated without writing
- * additional code.
- * - Plugin collections: Provide a way to lazily instantiate a set of plugin
- * instances from a single plugin definition.
- *
- * There are several things a module developer may need to do with plugins:
- * - Define a completely new plugin type: see @ref sec_define below.
- * - Create a plugin of an existing plugin type: see @ref sec_create below.
- * - Perform tasks that involve plugins: see @ref sec_use below.
- *
- * See https://drupal.org/developing/api/8/plugins for more detailed
- * documentation on the plugin system. There are also topics for a few
- * of the many existing types of plugins:
- * - @link block_api Block API @endlink
- * - @link entity_api Entity API @endlink
- * - @link field Various types of field-related plugins @endlink
- * - @link views_plugins Views plugins @endlink (has links to topics covering
- * various specific types of Views plugins).
- * - @link search Search page plugins @endlink
- *
- * @section sec_define Defining a new plugin type
- * To define a new plugin type:
- * - Define an interface for the plugin. This describes the common set of
- * behavior, and the methods you will call on each plugin class that is
- * instantiated. Usually this interface will extend one or more of the
- * following interfaces:
- * - \Drupal\Component\Plugin\PluginInspectionInterface
- * - \Drupal\Component\Plugin\ConfigurablePluginInterface
- * - \Drupal\Component\Plugin\ContextAwarePluginInterface
- * - \Drupal\Core\Plugin\PluginFormInterface
- * - \Drupal\Core\Executable\ExecutableInterface
- * - (optional) Create a base class that provides a partial implementation of
- * the interface, for the convenience of developers wishing to create plugins
- * of your type. The base class usually extends
- * \Drupal\Core\Plugin\PluginBase, or one of the base classes that extends
- * this class.
- * - Choose a method for plugin discovery, and define classes as necessary.
- * See @ref sub_discovery below.
- * - Create a plugin manager/factory class and service, which will discover and
- * instantiate plugins. See @ref sub_manager below.
- * - Use the plugin manager to instantiate plugins. Call methods on your plugin
- * interface to perform the tasks of your plugin type.
- * - (optional) If appropriate, define a plugin collection. See @ref
- * sub_collection below for more information.
- *
- * @subsection sub_discovery Plugin discovery
- * Plugin discovery is the process your plugin manager uses to discover the
- * individual plugins of your type that have been defined by your module and
- * other modules. Plugin discovery methods are classes that implement
- * \Drupal\Component\Plugin\Discovery\DiscoveryInterface. Most plugin types use
- * one of the following discovery mechanisms:
- * - Annotation: Plugin classes are annotated and placed in a defined namespace
- * subdirectory. Most Drupal Core plugins use this method of discovery.
- * - Hook: Plugin modules need to implement a hook to tell the manager about
- * their plugins.
- * - YAML: Plugins are listed in YAML files. Drupal Core uses this method for
- * discovering local tasks and local actions. This is mainly useful if all
- * plugins use the same class, so it is kind of like a global derivative.
- * - Static: Plugin classes are registered within the plugin manager class
- * itself. Static discovery is only useful if modules cannot define new
- * plugins of this type (if the list of available plugins is static).
- *
- * It is also possible to define your own custom discovery mechanism or mix
- * methods together. And there are many more details, such as annotation
- * decorators, that apply to some of the discovery methods. See
- * https://drupal.org/developing/api/8/plugins for more details.
- *
- * The remainder of this documentation will assume Annotation-based discovery,
- * since this is the most common method.
- *
- * @subsection sub_manager Defining a plugin manager class and service
- * To define an annotation-based plugin manager:
- * - Choose a namespace subdirectory for your plugin. For example, search page
- * plugins go in directory Plugin/Search under the module namespace.
- * - Define an annotation class for your plugin type. This class should extend
- * \Drupal\Component\Annotation\Plugin, and for most plugin types, it should
- * contain member variables corresponding to the annotations plugins will
- * need to provide. All plugins have at least $id: a unique string
- * identifier.
- * - Define an alter hook for altering the discovered plugin definitions. You
- * should document the hook in a *.api.php file.
- * - Define a plugin manager class. This class should implement
- * \Drupal\Component\Plugin\PluginManagerInterface; most plugin managers do
- * this by extending \Drupal\Core\Plugin\DefaultPluginManager. If you do
- * extend the default plugin manager, the only method you will probably need
- * to define is the class constructor, which will need to call the parent
- * constructor to provide information about the annotation class and plugin
- * namespace for discovery, set up the alter hook, and possibly set up
- * caching. See classes that extend DefaultPluginManager for examples.
- * - Define a service for your plugin manager. See the
- * @link container Services topic for more information. @endlink Your service
- * definition should look something like this, referencing your manager
- * class and the parent (default) plugin manager service to inherit
- * constructor arguments:
- * @code
- * plugin.manager.mymodule:
- * class: Drupal\mymodule\MyPluginManager
- * parent: default_plugin_manager
- * @endcode
- * - If your plugin is configurable, you will also need to define the
- * configuration schema and possibly a configuration entity type. See the
- * @link config_api Configuration API topic @endlink for more information.
- *
- * @subsection sub_collection Defining a plugin collection
- * Some configurable plugin types allow administrators to create zero or more
- * instances of each plugin, each with its own configuration. For example,
- * a single block plugin can be configured several times, to display in
- * different regions of a theme, with different visibility settings, a
- * different title, or other plugin-specific settings. To make this possible,
- * a plugin type can make use of what's known as a plugin collection.
- *
- * A plugin collection is a class that extends
- * \Drupal\Component\Plugin\LazyPluginCollection or one of its subclasses; there
- * are several examples in Drupal Core. If your plugin type uses a plugin
- * collection, it will usually also have a configuration entity, and the entity
- * class should implement
- * \Drupal\Core\Entity\EntityWithPluginCollectionInterface. Again, there are
- * several examples in Drupal Core; see also the @link config_api Configuration
- * API topic @endlink for more information about configuration entities.
- *
- * @section sec_create Creating a plugin of an existing type
- * Assuming the plugin type uses annotation-based discovery, in order to create
- * a plugin of an existing type, you will be creating a class. This class must:
- * - Implement the plugin interface, so that it has the required methods
- * defined. Usually, you'll want to extend the plugin base class, if one has
- * been provided.
- * - Have the right annotation in its documentation header. See the
- * @link annotation Annotation topic @endlink for more information about
- * annotation.
- * - Be in the right plugin namespace, in order to be discovered.
- * Often, the easiest way to make sure this happens is to find an existing
- * example of a working plugin class of the desired type, and copy it into your
- * module as a starting point.
- *
- * You can also create a plugin derivative, which allows your plugin class
- * to present itself to the user interface as multiple plugins. To do this,
- * in addition to the plugin class, you'll need to create a separate plugin
- * derivative class implementing
- * \Drupal\Component\Plugin\Derivative\DerivativeInterface. The classes
- * \Drupal\system\Plugin\Block\SystemMenuBlock (plugin class) and
- * \Drupal\system\Plugin\Derivative\SystemMenuBlock (derivative class) are a
- * good example to look at.
- *
- * @section sec_use Performing tasks involving plugins
- * Here are the steps to follow to perform a task that involves plugins:
- * - Locate the machine name of the plugin manager service, and instantiate the
- * service. See the @link container Services topic @endlink for more
- * information on how to do this.
- * - On the plugin manager class, use methods like getDefinition(),
- * getDefinitions(), or other methods specific to particular plugin managers
- * to retrieve information about either specific plugins or the entire list of
- * defined plugins.
- * - Call the createInstance() method on the plugin manager to instantiate
- * individual plugin objects.
- * - Call methods on the plugin objects to perform the desired tasks.
- *
- * @see annotation
- * @}
- */
-
-/**
- * @defgroup oo_conventions Objected-oriented programming conventions
- * @{
- * PSR-4, namespaces, class naming, and other conventions.
- *
- * A lot of the PHP code in Drupal is object oriented (OO), making use of
- * @link http://php.net/manual/language.oop5.php PHP classes, interfaces, and traits @endlink
- * (which are loosely referred to as "classes" in the rest of this topic). The
- * following conventions and standards apply to this version of Drupal:
- * - Each class must be in its own file.
- * - Classes must be namespaced. If a module defines a class, the namespace
- * must start with \Drupal\module_name. If it is defined by Drupal Core for
- * use across many modules, the namespace should be \Drupal\Core or
- * \Drupal\Component, with the exception of the global class \Drupal. See
- * https://www.drupal.org/node/1353118 for more about namespaces.
- * - In order for the PSR-4-based class auto-loader to find the class, it must
- * be located in a directory corresponding to the namespace. For
- * module-defined classes, if the namespace is \Drupal\module_name\foo\bar,
- * then the class goes under the main module directory in directory
- * src/foo/bar. For Drupal-wide classes, if the namespace is
- * \Drupal\Core\foo\bar, then it goes in directory
- * core/lib/Drupal/Core/foo/bar. See https://www.drupal.org/node/2156625 for
- * more information about PSR-4.
- * - Some classes have annotations added to their documentation headers. See
- * the @link annotation Annotation topic @endlink for more information.
- * - Standard plugin discovery requires particular namespaces and annotation
- * for most plugin classes. See the
- * @link plugin_api Plugin API topic @endlink for more information.
- * - There are project-wide coding standards for OO code, including naming:
- * https://drupal.org/node/608152
- * - Documentation standards for classes are covered on:
- * https://www.drupal.org/coding-standards/docs#classes
- * @}
- */
-
-/**
- * @defgroup best_practices Best practices for developers
- * @{
- * Overview of standards and best practices for developers
- *
- * Ideally, all code that is included in Drupal Core and contributed modules,
- * themes, and distributions will be secure, internationalized, maintainable,
- * and efficient. In order to facilitate this, the Drupal community has
- * developed a set of guidelines and standards for developers to follow. Most of
- * these standards can be found under
- * @link https://drupal.org/developing/best-practices Best practices on Drupal.org @endlink
- *
- * Standards and best practices that developers should be aware of include:
- * - Security: https://drupal.org/writing-secure-code and the
- * @link sanitization Sanitization functions topic @endlink
- * - Coding standards: https://drupal.org/coding-standards
- * and https://drupal.org/coding-standards/docs
- * - Accessibility: https://drupal.org/node/1637990 (modules) and
- * https://drupal.org/node/464472 (themes)
- * - Usability: https://drupal.org/ui-standards
- * - Internationalization: @link i18n Internationalization topic @endlink
- * - Automated testing: @link testing Automated tests topic @endlink
- * @}
- */
-
-/**
- * @defgroup utility Utility classes and functions
- * @{
- * Overview of utility classes and functions for developers.
- *
- * Drupal provides developers with a variety of utility functions that make it
- * easier and more efficient to perform tasks that are either really common,
- * tedious, or difficult. Utility functions help to reduce code duplication and
- * should be used in place of one-off code whenever possible.
- *
- * @see common.inc
- * @see file
- * @see format
- * @see php_wrappers
- * @see sanitization
- * @see transliteration
- * @see validation
- * @}
- */
-
-/**
- * @defgroup hooks Hooks
- * @{
- * 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:
- * - Locate the documentation for the hook. Hooks are documented in *.api.php
- * files, by defining functions whose name starts with "hook_" (these
- * files and their functions are never loaded by Drupal -- they exist solely
- * for documentation). The function should have a documentation header, as
- * well as a sample function body. For example, in the core file
- * system.api.php, you can find hooks such as hook_batch_alter(). Also, if
- * you are viewing this documentation on an API reference site, the Core
- * hooks will be listed in this topic.
- * - Copy the function to your module's .module file.
- * - Change the name of the function, substituting your module's short name
- * (name of the module's directory, and .info.yml file without the extension)
- * for the "hook" part of the sample function name. For instance, to implement
- * hook_batch_alter(), you would rename it to my_module_batch_alter().
- * - Edit the documentation for the function (normally, your implementation
- * should just have one line saying "Implements hook_batch_alter().").
- * - Edit the body of the function, substituting in what you need your module
- * to do.
- *
- * To define a hook:
- * - Choose a unique name for your hook. It should start with "hook_", followed
- * by your module's short name.
- * - Provide documentation in a *.api.php file in your module's main
- * directory. See the "implementing" section above for details of what this
- * should contain (parameters, return value, and sample function body).
- * - Invoke the hook in your module's code.
- *
- * To invoke a hook, use methods on
- * \Drupal\Core\Extension\ModuleHandlerInterface such as alter(), invoke(),
- * and invokeAll(). You can obtain a module handler by calling
- * \Drupal::moduleHandler(), or getting the 'module_handler' service on an
- * injected container.
- *
- * @see extending
- * @see themeable
- * @see callbacks
- * @see \Drupal\Core\Extension\ModuleHandlerInterface
- * @see \Drupal::moduleHandler()
- *
- * @}
- */
-
-/**
- * @defgroup callbacks Callbacks
- * @{
- * Callback function signatures.
- *
- * Drupal's API sometimes uses callback functions to allow you to define how
- * some type of processing happens. A callback is a function with a defined
- * signature, which you define in a module. Then you pass the function name as
- * a parameter to a Drupal API function or return it as part of a hook
- * implementation return value, and your function is called at an appropriate
- * time. For instance, when setting up batch processing you might need to
- * provide a callback function for each processing step and/or a callback for
- * when processing is finished; you would do that by defining these functions
- * and passing their names into the batch setup function.
- *
- * Callback function signatures, like hook definitions, are described by
- * creating and documenting dummy functions in a *.api.php file; normally, the
- * dummy callback function's name should start with "callback_", and you should
- * document the parameters and return value and provide a sample function body.
- * Then your API documentation can refer to this callback function in its
- * documentation. A user of your API can usually name their callback function
- * anything they want, although a standard name would be to replace "callback_"
- * with the module name.
- *
- * @see hooks
- * @see themeable
- *
- * @}
- */
-
-/**
- * @defgroup form_api Form generation
- * @{
- * Describes how to generate and manipulate forms and process form submissions.
- *
- * Drupal provides a Form API in order to achieve consistency in its form
- * processing and presentation, while simplifying code and reducing the amount
- * of HTML that must be explicitly generated by a module.
- *
- * @section generating_forms Creating forms
- * Forms are defined as classes that implement the
- * \Drupal\Core\Form\FormInterface and are built using the
- * \Drupal\Core\Form\FormBuilder class. Drupal provides a couple of utility
- * classes that can be extended as a starting point for most basic forms, the
- * most commonly used of which is \Drupal\Core\Form\FormBase. FormBuilder
- * handles the low level processing of forms such as rendering the necessary
- * HTML, initial processing of incoming $_POST data, and delegating to your
- * implementation of FormInterface for validation and processing of submitted
- * data.
- *
- * Here is an example of a Form class:
- * @code
- * namespace Drupal\mymodule\Form;
- *
- * use Drupal\Core\Form\FormBase;
- * use Drupal\Core\Form\FormStateInterface;
- *
- * class ExampleForm extends FormBase {
- * public function getFormId() {
- * // Unique ID of the form.
- * return 'example_form';
- * }
- *
- * public function buildForm(array $form, FormStateInterface $form_state) {
- * // Create a $form API array.
- * $form['phone_number'] = array(
- * '#type' => 'tel',
- * '#title' => $this->t('Your phone number')
- * );
- * return $form;
- * }
- *
- * public function validateForm(array &$form, FormStateInterface $form_state) {
- * // Validate submitted form data.
- * }
- *
- * public function submitForm(array &$form, FormStateInterface $form_state) {
- * // Handle submitted form data.
- * }
- * }
- * @endcode
- *
- * @section retrieving_forms Retrieving and displaying forms
- * \Drupal::formBuilder()->getForm() should be used to handle retrieving,
- * processing, and displaying a rendered HTML form. Given the ExampleForm
- * defined above,
- * \Drupal::formBuilder()->getForm('Drupal\mymodule\Form\ExampleForm') would
- * return the rendered HTML of the form defined by ExampleForm::buildForm(), or
- * call the validateForm() and submitForm(), methods depending on the current
- * processing state.
- *
- * The argument to \Drupal::formBuilder()->getForm() is the name of a class that
- * implements FormBuilderInterface. Any additional arguments passed to the
- * getForm() method will be passed along as additional arguments to the
- * ExampleForm::buildForm() method.
- *
- * For example:
- * @code
- * $extra = '612-123-4567';
- * $form = \Drupal::formBuilder()->getForm('Drupal\mymodule\Form\ExampleForm', $extra);
- * ...
- * public function buildForm(array $form, FormStateInterface $form_state, $extra = NULL)
- * $form['phone_number'] = array(
- * '#type' => 'tel',
- * '#title' => $this->t('Your phone number'),
- * '#value' => $extra,
- * );
- * return $form;
- * }
- * @endcode
- *
- * Alternatively, forms can be built directly via the routing system which will
- * take care of calling \Drupal::formBuilder()->getForm(). The following example
- * demonstrates the use of a routing.yml file to display a form at the given
- * route.
- *
- * @code
- * example.form:
- * path: '/example-form'
- * defaults:
- * _title: 'Example form'
- * _form: '\Drupal\mymodule\Form\ExampleForm'
- * @endcode
- *
- * The $form argument to form-related functions is a structured array containing
- * the elements and properties of the form. For information on the array
- * components and format, and more detailed explanations of the Form API
- * workflow, see the
- * @link forms_api_reference.html Form API reference @endlink
- * and the
- * @link https://drupal.org/node/2117411 Form API documentation section. @endlink
- * In addition, there is a set of Form API tutorials in
- * @link form_example_tutorial.inc the Form Example Tutorial @endlink which
- * provide basics all the way up through multistep forms.
- *
- * In the form builder, validation, submission, and other form methods,
- * $form_state is the primary influence on the processing of the form and is
- * passed to most methods, so they can use it to communicate with the form
- * system and each other. $form_state is an object that implements
- * \Drupal\Core\Form\FormStateInterface.
- * @}
- */
-
-/**
- * @defgroup queue Queue operations
- * @{
- * Queue items to allow later processing.
- *
- * The queue system allows placing items in a queue and processing them later.
- * The system tries to ensure that only one consumer can process an item.
- *
- * Before a queue can be used it needs to be created by
- * Drupal\Core\Queue\QueueInterface::createQueue().
- *
- * Items can be added to the queue by passing an arbitrary data object to
- * Drupal\Core\Queue\QueueInterface::createItem().
- *
- * To process an item, call Drupal\Core\Queue\QueueInterface::claimItem() and
- * specify how long you want to have a lease for working on that item.
- * When finished processing, the item needs to be deleted by calling
- * Drupal\Core\Queue\QueueInterface::deleteItem(). If the consumer dies, the
- * item will be made available again by the Drupal\Core\Queue\QueueInterface
- * implementation once the lease expires. Another consumer will then be able to
- * receive it when calling Drupal\Core\Queue\QueueInterface::claimItem().
- * Due to this, the processing code should be aware that an item might be handed
- * over for processing more than once.
- *
- * The $item object used by the Drupal\Core\Queue\QueueInterface can contain
- * arbitrary metadata depending on the implementation. Systems using the
- * interface should only rely on the data property which will contain the
- * information passed to Drupal\Core\Queue\QueueInterface::createItem().
- * The full queue item returned by Drupal\Core\Queue\QueueInterface::claimItem()
- * needs to be passed to Drupal\Core\Queue\QueueInterface::deleteItem() once
- * processing is completed.
- *
- * There are two kinds of queue backends available: reliable, which preserves
- * the order of messages and guarantees that every item will be executed at
- * least once. The non-reliable kind only does a best effort to preserve order
- * in messages and to execute them at least once but there is a small chance
- * that some items get lost. For example, some distributed back-ends like
- * Amazon SQS will be managing jobs for a large set of producers and consumers
- * where a strict FIFO ordering will likely not be preserved. Another example
- * would be an in-memory queue backend which might lose items if it crashes.
- * However, such a backend would be able to deal with significantly more writes
- * than a reliable queue and for many tasks this is more important. See
- * aggregator_cron() for an example of how to effectively use a non-reliable
- * queue. Another example is doing Twitter statistics -- the small possibility
- * of losing a few items is insignificant next to power of the queue being able
- * to keep up with writes. As described in the processing section, regardless
- * of the queue being reliable or not, the processing code should be aware that
- * an item might be handed over for processing more than once (because the
- * processing code might time out before it finishes).
- * @}
- */
-
-/**
- * @defgroup annotation Annotations
- * @{
- * Annotations for class discovery and metadata description.
- *
- * The Drupal plugin system has a set of reusable components that developers
- * can use, override, and extend in their modules. Most of the plugins use
- * annotations, which let classes register themselves as plugins and describe
- * their metadata. (Annotations can also be used for other purposes, though
- * at the moment, Drupal only uses them for the plugin system.)
- *
- * To annotate a class as a plugin, add code similar to the following to the
- * end of the documentation block immediately preceding the class declaration:
- * @code
- * * @ContentEntityType(
- * * id = "comment",
- * * label = @Translation("Comment"),
- * * ...
- * * base_table = "comment"
- * * )
- * @endcode
- *
- * Note that you must use double quotes; single quotes will not work in
- * annotations.
- *
- * Some annotation types, which extend the "@ PluginID" annotation class, have
- * only a single 'id' key in their annotation. For these, it is possible to use
- * a shorthand annotation. For example:
- * @code
- * * @ViewsArea("entity")
- * @endcode
- * in place of
- * @code
- * * @ViewsArea(
- * * id = "entity"
- * *)
- * @endcode
- *
- * The available annotation classes are listed in this topic, and can be
- * identified when you are looking at the Drupal source code by having
- * "@ Annotation" in their documentation blocks (without the space after @). To
- * find examples of annotation for a particular annotation class, such as
- * EntityType, look for class files that have an @ annotation section using the
- * annotation class.
- *
- * @see plugin_translatable
- * @see plugin_context
- *
- * @}
- */
-
-/**
- * @addtogroup hooks
- * @{
- */
-
-/**
- * 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 \Drupal\Core\Annotation\QueueWorker plugin. Then, add items
- * that need to be processed to the defined queues.
- */
-function hook_cron() {
- // Short-running operation example, not using a queue:
- // Delete all expired records since the last cron run.
- $expires = \Drupal::state()->get('mymodule.cron_last_run', REQUEST_TIME);
- db_delete('mymodule_table')
- ->condition('expires', $expires, '>=')
- ->execute();
- \Drupal::state()->set('mymodule.cron_last_run', REQUEST_TIME);
-
- // Long-running operation example, leveraging a queue:
- // Fetch feeds from other sites.
- $result = db_query('SELECT * FROM {aggregator_feed} WHERE checked + refresh < :time AND refresh <> :never', array(
- ':time' => REQUEST_TIME,
- ':never' => AGGREGATOR_CLEAR_NEVER,
- ));
- $queue = \Drupal::queue('aggregator_feeds');
- foreach ($result as $feed) {
- $queue->createItem($feed);
- }
-}
-
-/**
- * Alter available data types for typed data wrappers.
- *
- * @param array $data_types
- * An array of data type information.
- *
- * @see hook_data_type_info()
- */
-function hook_data_type_info_alter(&$data_types) {
- $data_types['email']['class'] = '\Drupal\mymodule\Type\Email';
-}
-
-/**
- * Alter cron queue information before cron runs.
- *
- * Called by \Drupal\Core\Cron to allow modules to alter cron queue settings
- * before any jobs are processesed.
- *
- * @param array $queues
- * An array of cron queue information.
- *
- * @see \Drupal\Core\QueueWorker\QueueWorkerInterface
- * @see \Drupal\Core\Annotation\QueueWorker
- * @see \Drupal\Core\Cron
- */
-function hook_queue_info_alter(&$queues) {
- // This site has many feeds so let's spend 90 seconds on each cron run
- // updating feeds instead of the default 60.
- $queues['aggregator_feeds']['cron']['time'] = 90;
-}
-
-/**
- * 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.
- *
- * @param $message
- * An 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 \Drupal\Core\Mail\MailManagerInterface::mail()
- */
-function hook_mail_alter(&$message) {
- if ($message['id'] == 'modulename_messagekey') {
- if (!example_notifications_optin($message['to'], $message['id'])) {
- // If the recipient has opted to not receive such messages, cancel
- // sending.
- $message['send'] = FALSE;
- return;
- }
- $message['body'][] = "--\nMail sent out from " . \Drupal::config('system.site')->get('name');
- }
-}
-
-/**
- * Prepares a message based on parameters;
- *
- * This hook is called from MailManagerInterface->mail(). Note that hook_mail(),
- * unlike hook_mail_alter(), is only called on the $module argument to
- * MailManagerInterface->mail(), not all modules.
- *
- * @param $key
- * An identifier of the mail.
- * @param $message
- * An array to be filled in. Elements in this array include:
- * - id: An ID to identify the mail sent. 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.
- * - subject: Subject of the email to be sent. This must not contain any
- * newline characters, or the mail may not be sent properly.
- * MailManagerInterface->mail() sets this to an empty
- * string when the hook is invoked.
- * - body: An array of lines containing the message to be sent. Drupal will
- * format the correct line endings for you. MailManagerInterface->mail()
- * sets this to an empty array when the hook is invoked.
- * - from: The address the message will be marked as being from, which is
- * set by MailManagerInterface->mail() to either a custom address or the
- * site-wide default email address when the hook is invoked.
- * - headers: Associative array containing mail headers, such as From,
- * Sender, MIME-Version, Content-Type, etc.
- * MailManagerInterface->mail() pre-fills several headers in this array.
- * @param $params
- * An array of parameters supplied by the caller of
- * MailManagerInterface->mail().
- *
- * @see \Drupal\Core\Mail\MailManagerInterface->mail()
- */
-function hook_mail($key, &$message, $params) {
- $account = $params['account'];
- $context = $params['context'];
- $variables = array(
- '%site_name' => \Drupal::config('system.site')->get('name'),
- '%username' => user_format_name($account),
- );
- if ($context['hook'] == 'taxonomy') {
- $entity = $params['entity'];
- $vocabulary = Vocabulary::load($entity->id());
- $variables += array(
- '%term_name' => $entity->name,
- '%term_description' => $entity->description,
- '%term_id' => $entity->id(),
- '%vocabulary_name' => $vocabulary->label(),
- '%vocabulary_description' => $vocabulary->getDescription(),
- '%vocabulary_id' => $vocabulary->id(),
- );
- }
-
- // Node-based variable translation is only available if we have a node.
- if (isset($params['node'])) {
- /** @var \Drupal\node\NodeInterface $node */
- $node = $params['node'];
- $variables += array(
- '%uid' => $node->getOwnerId(),
- '%url' => $node->url('canonical', array('absolute' => TRUE)),
- '%node_type' => node_get_type_label($node),
- '%title' => $node->getTitle(),
- '%teaser' => $node->teaser,
- '%body' => $node->body,
- );
- }
- $subject = strtr($context['subject'], $variables);
- $body = strtr($context['message'], $variables);
- $message['subject'] .= str_replace(array("\r", "\n"), '', $subject);
- $message['body'][] = MailFormatHelper::htmlToText($body);
-}
-
-/**
- * Alter the list of mail backend plugin definitions.
- *
- * @param array $info
- * The mail backend plugin definitions to be altered.
- *
- * @see \Drupal\Core\Annotation\Mail
- * @see \Drupal\Core\Mail\MailManager
- */
-function hook_mail_backend_info_alter(&$info) {
- unset($info['test_mail_collector']);
-}
-
-/**
- * Alter the default country list.
- *
- * @param $countries
- * The associative array of countries keyed by two-letter country code.
- *
- * @see \Drupal\Core\Locale\CountryManager::getList().
- */
-function hook_countries_alter(&$countries) {
- // Elbonia is now independent, so add it to the country list.
- $countries['EB'] = 'Elbonia';
-}
-
-/**
- * Alter display variant plugin definitions.
- *
- * @param array $definitions
- * The array of display variant definitions, keyed by plugin ID.
- *
- * @see \Drupal\Core\Display\VariantManager
- * @see \Drupal\Core\Display\Annotation\DisplayVariant
- */
-function hook_display_variant_plugin_alter(array &$definitions) {
- $definitions['full_page']['admin_label'] = t('Block layout');
-}
-
-/**
- * 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 drupal_flush_all_caches()
- * @see hook_rebuild()
- */
-function hook_cache_flush() {
- if (defined('MAINTENANCE_MODE') && MAINTENANCE_MODE == 'update') {
- _update_cache_clear();
- }
-}
-
-/**
- * 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 hook_cache_flush()
- * @see drupal_flush_all_caches()
- */
-function hook_rebuild() {
- $themes = \Drupal::service('theme_handler')->listInfo();
- foreach ($themes as $theme) {
- _block_rehash($theme->getName());
- }
-}
-
-/**
- * Alter the configuration synchronization steps.
- *
- * @param array $sync_steps
- * A one-dimensional array of \Drupal\Core\Config\ConfigImporter 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
- * @link batch Batch operations @endlink documentation.
- *
- * @see callback_batch_operation()
- * @see \Drupal\Core\Config\ConfigImporter::initialize()
- */
-function hook_config_import_steps_alter(&$sync_steps, \Drupal\Core\Config\ConfigImporter $config_importer) {
- $deletes = $config_importer->getUnprocessedConfiguration('delete');
- if (isset($deletes['field.storage.node.body'])) {
- $sync_steps[] = '_additional_configuration_step';
- }
-}
-
-/**
- * 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.
- *
- * @param $definitions
- * Associative array of configuration type definitions keyed by schema type
- * names. The elements are themselves array with information about the type.
- *
- * @see \Drupal\Core\Config\TypedConfigManager
- * @see \Drupal\Core\Config\Schema\ConfigSchemaAlterException
- */
-function hook_config_schema_info_alter(&$definitions) {
- // Enhance the text and date type definitions with classes to generate proper
- // form elements in ConfigTranslationFormBase. Other translatable types will
- // appear as a one line textfield.
- $definitions['text']['form_element_class'] = '\Drupal\config_translation\FormElement\Textarea';
- $definitions['date_format']['form_element_class'] = '\Drupal\config_translation\FormElement\DateFormat';
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
-
-/**
- * @defgroup ajax Ajax API
- * @{
- * Overview for Drupal's Ajax API.
- *
- * @section sec_overview Overview of Ajax
- * Ajax is the process of dynamically updating parts of a page's HTML based on
- * data from the server. When a specified event takes place, a PHP callback is
- * triggered, which performs server-side logic and may return updated markup or
- * JavaScript commands to run. After the return, the browser runs the JavaScript
- * or updates the markup on the fly, with no full page refresh necessary.
- *
- * Many different events can trigger Ajax responses, including:
- * - Clicking a button
- * - Pressing a key
- * - Moving the mouse
- *
- * @section sec_framework Ajax responses in forms
- * Forms that use the Drupal Form API (see the
- * @link form_api Form API topic @endlink for more information about forms) can
- * trigger AJAX responses. Here is an outline of the steps:
- * - Add property '#ajax' to a form element in your form array, to trigger an
- * Ajax response.
- * - Write an Ajax callback to process the input and respond.
- * See sections below for details on these two steps.
- *
- * @subsection sub_form Adding Ajax triggers to a form
- * As an example of adding Ajax triggers to a form, consider editing a date
- * format, where the user is provided with a sample of the generated date output
- * as they type. To accomplish this, typing in the text field should trigger an
- * Ajax response. This is done in the text field form array element
- * in \Drupal\config_translation\FormElement\DateFormat::getFormElement():
- * @code
- * '#ajax' => array(
- * 'callback' => 'Drupal\config_translation\FormElement\DateFormat::ajaxSample',
- * 'event' => 'keyup',
- * 'progress' => array(
- * 'type' => 'throbber',
- * 'message' => NULL,
- * ),
- * ),
- * @endcode
- *
- * As you can see from this example, the #ajax property for a form element is
- * an array. Here are the details of its elements, all of which are optional:
- * - callback: The callback to invoke to handle the server side of the
- * Ajax event. More information on callbacks is below in @ref sub_callback.
- * - path: The URL path to use for the request. If omitted, defaults to
- * 'system/ajax', which invokes the default Drupal Ajax processing (this will
- * call the callback supplied in the 'callback' element). If you supply a
- * path, you must set up a routing entry to handle the request yourself and
- * return output described in @ref sub_callback below. See the
- * @link menu Routing topic @endlink for more information on routing.
- * - wrapper: The HTML 'id' attribute of the area where the content returned by
- * the callback should be placed. Note that callbacks have a choice of
- * returning content or JavaScript commands; 'wrapper' is used for content
- * returns.
- * - method: The jQuery method for placing the new content (used with
- * 'wrapper'). Valid options are 'replaceWith' (default), 'append', 'prepend',
- * 'before', 'after', or 'html'. See
- * http://api.jquery.com/category/manipulation/ for more information on these
- * methods.
- * - effect: The jQuery effect to use when placing the new HTML (used with
- * 'wrapper'). Valid options are 'none' (default), 'slide', or 'fade'.
- * - speed: The effect speed to use (used with 'effect' and 'wrapper'). Valid
- * options are 'slow' (default), 'fast', or the number of milliseconds the
- * effect should run.
- * - event: The JavaScript event to respond to. This is selected automatically
- * for the type of form element; provide a value to override the default.
- * - prevent: A JavaScript event to prevent when the event is triggered. For
- * example, if you use event 'mousedown' on a button, you might want to
- * prevent 'click' events from also being triggered.
- * - progress: An array indicating how to show Ajax processing progress. Can
- * contain one or more of these elements:
- * - type: Type of indicator: 'throbber' (default) or 'bar'.
- * - message: Translated message to display.
- * - url: For a bar progress indicator, URL path for determining progress.
- * - interval: For a bar progress indicator, how often to update it.
- *
- * @subsection sub_callback Setting up a callback to process Ajax
- * Once you have set up your form to trigger an Ajax response (see @ref sub_form
- * above), you need to write some PHP code to process the response. If you use
- * 'path' in your Ajax set-up, your route controller will be triggered with only
- * the information you provide in the URL. If you use 'callback', your callback
- * method is a function, which will receive the $form and $form_state from the
- * triggering form. You can use $form_state to get information about the
- * data the user has entered into the form. For instance, in the above example
- * for the date format preview,
- * \Drupal\config_translation\FormElement\DateFormat\ajaxSample() does this to
- * get the format string entered by the user:
- * @code
- * $format_value = \Drupal\Component\Utility\NestedArray::getValue(
- * $form_state->getValues(),
- * $form_state->getTriggeringElement()['#array_parents']);
- * @endcode
- *
- * Once you have processed the input, you have your choice of returning HTML
- * markup or a set of Ajax commands. If you choose to return HTML markup, you
- * can return it as a string or a renderable array, and it will be placed in
- * the defined 'wrapper' element (see documentation above in @ref sub_form).
- * In addition, any messages returned by drupal_get_messages(), themed as in
- * status-messages.html.twig, will be prepended.
- *
- * To return commands, you need to set up an object of class
- * \Drupal\Core\Ajax\AjaxResponse, and then use its addCommand() method to add
- * individual commands to it. In the date format preview example, the format
- * output is calculated, and then it is returned as replacement markup for a div
- * like this:
- * @code
- * $response = new AjaxResponse();
- * $response->addCommand(new ReplaceCommand(
- * '#edit-date-format-suffix',
- * '' . $format . ''));
- * return $response;
- * @endcode
- *
- * The individual commands that you can return implement interface
- * \Drupal\Core\Ajax\CommandInterface. Available commands provide the ability
- * to pop up alerts, manipulate text and markup in various ways, redirect
- * to a new URL, and the generic \Drupal\Core\Ajax\InvokeCommand, which
- * invokes an arbitrary jQuery command.
- *
- * As noted above, status messages are prepended automatically if you use the
- * 'wrapper' method and return HTML markup. This is not the case if you return
- * commands, but if you would like to show status messages, you can add
- * @code
- * array('#type' => 'status_messages')
- * @endcode
- * to a render array, use drupal_render() to render it, and add a command to
- * place the messages in an appropriate location.
- *
- * @section sec_other Other methods for triggering Ajax
- * Here are some additional methods you can use to trigger Ajax responses in
- * Drupal:
- * - Add class 'use-ajax' to a link. The link will be loaded using an Ajax
- * call. When using this method, the href of the link can contain '/nojs/' as
- * part of the path. When the Ajax JavaScript processes the page, it will
- * convert this to '/ajax/'. The server is then able to easily tell if this
- * request was made through an actual Ajax request or in a degraded state, and
- * respond appropriately.
- * - Add class 'use-ajax-submit' to a submit button in a form. The form will
- * then be submitted via Ajax to the path specified in the #action. Like the
- * ajax-submit class on links, this path will have '/nojs/' replaced with
- * '/ajax/' so that the submit handler can tell if the form was submitted in a
- * degraded state or not.
- * - Add property '#autocomplete_route_name' to a text field in a form. The
- * route controller for this route must return an array of options for
- * autocomplete, as a \Symfony\Component\HttpFoundation\JsonResponse object.
- * See the @link menu Routing topic @endlink for more information about
- * routing.
- */
-
-/**
- * @} End of "defgroup ajax".
- */
-
-/**
- * @defgroup service_tag Service Tags
- * @{
- * Service tags overview
- *
- * Some services have tags, which are defined in the service definition. Tags
- * are used to define a group of related services, or to specify some aspect of
- * how the service behaves. Typically, if you tag a service, your service class
- * must also implement a corresponding interface. Some common examples:
- * - access_check: Indicates a route access checking service; see the
- * @link menu Menu and routing system topic @endlink for more information.
- * - cache.bin: Indicates a cache bin service; see the
- * @link cache Cache topic @endlink for more information.
- * - event_subscriber: Indicates an event subscriber service. Event subscribers
- * can be used for dynamic routing and route altering; see the
- * @link menu Menu and routing system topic @endlink for more information.
- * They can also be used for other purposes; see
- * http://symfony.com/doc/current/cookbook/doctrine/event_listeners_subscribers.html
- * for more information.
- * - needs_destruction: Indicates that a destruct() method needs to be called
- * at the end of a request to finalize operations, if this service was
- * instantiated.
- *
- * Creating a tag for a service does not do anything on its own, but tags
- * can be discovered or queried in a compiler pass when the container is built,
- * and a corresponding action can be taken. See
- * \Drupal\Core\Render\MainContent\MainContentRenderersPass for an example of
- * finding tagged services.
- *
- * See @link container Services and Dependency Injection Container @endlink for
- * information on services and the dependency injection container.
- *
- * @}
- */
-
-/**
- * @defgroup events Events
- * @{
- * Overview of event dispatch and subscribing
- *
- * @section sec_intro Introduction and terminology
- * Events are part of the Symfony framework: they allow for different components
- * of the system to interact and communicate with each other. Each event has a
- * unique string name. One system component dispatches the event at an
- * appropriate time; many events are dispatched by Drupal core and the Symfony
- * framework in every request. Other system components can register as event
- * subscribers; when an event is dispatched, a method is called on each
- * registered subscriber, allowing each one to react. For more on the general
- * concept of events, see
- * http://symfony.com/doc/current/components/event_dispatcher/introduction.html
- *
- * @section sec_dispatch Dispatching events
- * To dispatch an event, call the
- * \Symfony\Component\EventDispatcher\EventDispatchInterface::dispatch() method
- * on the 'event_dispatcher' service (see the
- * @link container Services topic @endlink for more information about how to
- * interact with services). The first argument is the unique event name, which
- * you should normally define as a constant in a separate static class (see
- * \Symfony\Component\HttpKernel\KernelEvents and
- * \Drupal\Core\Config\ConfigEvents for examples). The second argument is a
- * \Symfony\Component\EventDispatcher\Event object; normally you will need to
- * extend this class, so that your event class can provide data to the event
- * subscribers.
- *
- * @section sec_subscribe Registering event subscribers
- * Here are the steps to register an event subscriber:
- * - Define a service in your module, tagged with 'event_subscriber' (see the
- * @link container Services topic @endlink for instructions).
- * - Define a class for your subscriber service that implements
- * \Symfony\Component\EventDispatcher\EventSubscriberInterface
- * - In your class, the getSubscribedEvents method returns a list of the events
- * this class is subscribed to, and which methods on the class should be
- * called for each one. Example:
- * @code
- * public function getSubscribedEvents() {
- * // Subscribe to kernel terminate with priority 100.
- * $events[KernelEvents::TERMINATE][] = array('onTerminate', 100);
- * // Subscribe to kernel request with default priority of 0.
- * $events[KernelEvents::REQUEST][] = array('onRequest');
- * return $events;
- * }
- * @endcode
- * - Write the methods that respond to the events; each one receives the
- * event object provided in the dispatch as its one argument. In the above
- * example, you would need to write onTerminate() and onRequest() methods.
- *
- * Note that in your getSubscribedEvents() method, you can optionally set the
- * priority of your event subscriber (see terminate example above). Event
- * subscribers with higher priority numbers get executed first; the default
- * priority is zero. If two event subscribers for the same event have the same
- * priority, the one defined in a module with a lower module weight will fire
- * first. Subscribers defined in the same services file are fired in
- * definition order. If order matters defining a priority is strongly advised
- * instead of relying on these two tie breaker rules as they might change in a
- * minor release.
- * @}
- */
diff --git a/core/modules/system/database.api.php b/core/modules/system/database.api.php
deleted file mode 100644
index f3d7fe2..0000000
--- a/core/modules/system/database.api.php
+++ /dev/null
@@ -1,564 +0,0 @@
- $uid));
- * foreach ($result as $record) {
- * // Perform operations on $record->title, etc. here.
- * }
- * @endcode
- *
- * Note that if your query has a string condition, like:
- * @code
- * WHERE e.my_field = 'foo'
- * @endcode
- * when you convert it to placeholders, omit the quotes:
- * @code
- * WHERE e.my_field = :my_field
- * ... array(':my_field' => 'foo') ...
- * @endcode
- *
- * @section sec_dynamic Dynamic SELECT queries
- * For SELECT queries where the simple query API described in @ref sec_simple
- * will not work well, you need to use the dynamic query API. However, you
- * should still use the Entity Query API if your query involves entities or
- * fields (see the @link entity_api Entity API topic @endlink for more on
- * entity queries).
- *
- * As a note, db_select() and similar functions are wrappers on connection
- * object methods. In most classes, you should use dependency injection and the
- * database connection object instead of these wrappers; See @ref sec_connection
- * below for details.
- *
- * The dynamic query API lets you build up a query dynamically using method
- * calls. As an illustration, the query example from @ref sec_simple above
- * would be:
- * @code
- * $result = db_select('example', 'e')
- * ->fields('e', array('id', 'title', 'created'))
- * ->condition('e.uid', $uid)
- * ->orderBy('e.created', 'DESC')
- * ->range(0, 10)
- * ->execute();
- * @endcode
- *
- * There are also methods to join to other tables, add fields with aliases,
- * isNull() to have a @code WHERE e.foo IS NULL @endcode condition, etc. See
- * https://drupal.org/developing/api/database for many more details.
- *
- * One note on chaining: It is common in the dynamic database API to chain
- * method calls (as illustrated here), because most of the query methods modify
- * the query object and then return the modified query as their return
- * value. However, there are some important exceptions; these methods (and some
- * others) do not support chaining:
- * - join(), innerJoin(), etc.: These methods return the joined table alias.
- * - addField(): This method returns the field alias.
- * Check the documentation for the query method you are using to see if it
- * returns the query or something else, and only chain methods that return the
- * query.
- *
- * @section_insert INSERT, UPDATE, and DELETE queries
- * INSERT, UPDATE, and DELETE queries need special care in order to behave
- * consistently across databases; you should never use db_query() to run
- * an INSERT, UPDATE, or DELETE query. Instead, use functions db_insert(),
- * db_update(), and db_delete() to obtain a base query on your table, and then
- * add dynamic conditions (as illustrated in @ref sec_dynamic above).
- *
- * As a note, db_insert() and similar functions are wrappers on connection
- * object methods. In most classes, you should use dependency injection and the
- * database connection object instead of these wrappers; See @ref sec_connection
- * below for details.
- *
- * For example, if your query is:
- * @code
- * INSERT INTO example (id, uid, path, name) VALUES (1, 2, 'path', 'Name');
- * @endcode
- * You can execute it via:
- * @code
- * $fields = array('id' => 1, 'uid' => 2, 'path' => 'path', 'name' => 'Name');
- * db_insert('example')
- * ->fields($fields)
- * ->execute();
- * @endcode
- *
- * @section sec_transaction Transactions
- * Drupal supports transactions, including a transparent fallback for
- * databases that do not support transactions. To start a new transaction,
- * call @code $txn = db_transaction(); @endcode The transaction will
- * remain open for as long as the variable $txn remains in scope; when $txn is
- * destroyed, the transaction will be committed. If your transaction is nested
- * inside of another then Drupal will track each transaction and only commit
- * the outer-most transaction when the last transaction object goes out out of
- * scope (when all relevant queries have completed successfully).
- *
- * Example:
- * @code
- * function my_transaction_function() {
- * // The transaction opens here.
- * $txn = db_transaction();
- *
- * try {
- * $id = db_insert('example')
- * ->fields(array(
- * 'field1' => 'mystring',
- * 'field2' => 5,
- * ))
- * ->execute();
- *
- * my_other_function($id);
- *
- * return $id;
- * }
- * catch (Exception $e) {
- * // Something went wrong somewhere, so roll back now.
- * $txn->rollback();
- * // Log the exception to watchdog.
- * watchdog_exception('type', $e);
- * }
- *
- * // $txn goes out of scope here. Unless the transaction was rolled back, it
- * // gets automatically committed here.
- * }
- *
- * function my_other_function($id) {
- * // The transaction is still open here.
- *
- * if ($id % 2 == 0) {
- * db_update('example')
- * ->condition('id', $id)
- * ->fields(array('field2' => 10))
- * ->execute();
- * }
- * }
- * @endcode
- *
- * @section sec_connection Database connection objects
- * The examples here all use functions like db_select() and db_query(), which
- * can be called from any Drupal method or function code. In some classes, you
- * may already have a database connection object in a member variable, or it may
- * be passed into a class constructor via dependency injection. If that is the
- * case, you can look at the code for db_select() and the other functions to see
- * how to get a query object from your connection variable. For example:
- * @code
- * $query = $connection->select('example', 'e');
- * @endcode
- * would be the equivalent of
- * @code
- * $query = db_select('example', 'e');
- * @endcode
- * if you had a connection object variable $connection available to use. See
- * also the @link container Services and Dependency Injection topic. @endlink
- *
- * @see http://drupal.org/developing/api/database
- * @see entity_api
- * @see schemaapi
- *
- * @}
- */
-
-/**
- * @defgroup schemaapi Schema API
- * @{
- * API to handle database schemas.
- *
- * A Drupal schema definition is an array structure representing one or
- * more tables and their related keys and indexes. A schema is defined by
- * hook_schema(), which usually lives in a modulename.install file.
- *
- * By implementing hook_schema() and specifying the tables your module
- * declares, you can easily create and drop these tables on all
- * supported database engines. You don't have to deal with the
- * different SQL dialects for table creation and alteration of the
- * supported database engines.
- *
- * hook_schema() should return an array with a key for each table that
- * the module defines.
- *
- * The following keys are defined:
- * - 'description': A string in non-markup plain text describing this table
- * and its purpose. References to other tables should be enclosed in
- * curly-brackets. For example, the node_field_revision table
- * description field might contain "Stores per-revision title and
- * body data for each {node}."
- * - 'fields': An associative array ('fieldname' => specification)
- * that describes the table's database columns. The specification
- * is also an array. The following specification parameters are defined:
- * - 'description': A string in non-markup plain text describing this field
- * and its purpose. References to other tables should be enclosed in
- * curly-brackets. For example, the node table vid field
- * description might contain "Always holds the largest (most
- * recent) {node_field_revision}.vid value for this nid."
- * - 'type': The generic datatype: 'char', 'varchar', 'text', 'blob', 'int',
- * 'float', 'numeric', or 'serial'. Most types just map to the according
- * database engine specific datatypes. Use 'serial' for auto incrementing
- * fields. This will expand to 'INT auto_increment' on MySQL.
- * A special 'varchar_ascii' type is also available for limiting machine
- * name field to US ASCII characters.
- * - 'mysql_type', 'pgsql_type', 'sqlite_type', etc.: If you need to
- * use a record type not included in the officially supported list
- * of types above, you can specify a type for each database
- * backend. In this case, you can leave out the type parameter,
- * but be advised that your schema will fail to load on backends that
- * do not have a type specified. A possible solution can be to
- * use the "text" type as a fallback.
- * - 'serialize': A boolean indicating whether the field will be stored as
- * a serialized string.
- * - 'size': The data size: 'tiny', 'small', 'medium', 'normal',
- * 'big'. This is a hint about the largest value the field will
- * store and determines which of the database engine specific
- * datatypes will be used (e.g. on MySQL, TINYINT vs. INT vs. BIGINT).
- * 'normal', the default, selects the base type (e.g. on MySQL,
- * INT, VARCHAR, BLOB, etc.).
- * Not all sizes are available for all data types. See
- * DatabaseSchema::getFieldTypeMap() for possible combinations.
- * - 'not null': If true, no NULL values will be allowed in this
- * database column. Defaults to false.
- * - 'default': The field's default value. The PHP type of the
- * value matters: '', '0', and 0 are all different. If you
- * specify '0' as the default value for a type 'int' field it
- * will not work because '0' is a string containing the
- * character "zero", not an integer.
- * - 'length': The maximal length of a type 'char', 'varchar' or 'text'
- * field. Ignored for other field types.
- * - 'unsigned': A boolean indicating whether a type 'int', 'float'
- * and 'numeric' only is signed or unsigned. Defaults to
- * FALSE. Ignored for other field types.
- * - 'precision', 'scale': For type 'numeric' fields, indicates
- * the precision (total number of significant digits) and scale
- * (decimal digits right of the decimal point). Both values are
- * mandatory. Ignored for other field types.
- * - 'binary': A boolean indicating that MySQL should force 'char',
- * 'varchar' or 'text' fields to use case-sensitive binary collation.
- * This has no effect on other database types for which case sensitivity
- * is already the default behavior.
- * All parameters apart from 'type' are optional except that type
- * 'numeric' columns must specify 'precision' and 'scale', and type
- * 'varchar' must specify the 'length' parameter.
- * - 'primary key': An array of one or more key column specifiers (see below)
- * that form the primary key.
- * - 'unique keys': An associative array of unique keys ('keyname' =>
- * specification). Each specification is an array of one or more
- * key column specifiers (see below) that form a unique key on the table.
- * - 'foreign keys': An associative array of relations ('my_relation' =>
- * specification). Each specification is an array containing the name of
- * the referenced table ('table'), and an array of column mappings
- * ('columns'). Column mappings are defined by key pairs ('source_column' =>
- * 'referenced_column').
- * - 'indexes': An associative array of indexes ('indexname' =>
- * specification). Each specification is an array of one or more
- * key column specifiers (see below) that form an index on the
- * table.
- *
- * A key column specifier is either a string naming a column or an
- * array of two elements, column name and length, specifying a prefix
- * of the named column.
- *
- * As an example, here is a SUBSET of the schema definition for
- * Drupal's 'node' table. It show four fields (nid, vid, type, and
- * title), the primary key on field 'nid', a unique key named 'vid' on
- * field 'vid', and two indexes, one named 'nid' on field 'nid' and
- * one named 'node_title_type' on the field 'title' and the first four
- * bytes of the field 'type':
- *
- * @code
- * $schema['node'] = array(
- * 'description' => 'The base table for nodes.',
- * 'fields' => array(
- * 'nid' => array('type' => 'serial', 'unsigned' => TRUE, 'not null' => TRUE),
- * 'vid' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE,'default' => 0),
- * 'type' => array('type' => 'varchar','length' => 32,'not null' => TRUE, 'default' => ''),
- * 'language' => array('type' => 'varchar','length' => 12,'not null' => TRUE,'default' => ''),
- * 'title' => array('type' => 'varchar','length' => 255,'not null' => TRUE, 'default' => ''),
- * 'uid' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
- * 'status' => array('type' => 'int', 'not null' => TRUE, 'default' => 1),
- * 'created' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
- * 'changed' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
- * 'comment' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
- * 'promote' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
- * 'moderate' => array('type' => 'int', 'not null' => TRUE,'default' => 0),
- * 'sticky' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
- * 'translate' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
- * ),
- * 'indexes' => array(
- * 'node_changed' => array('changed'),
- * 'node_created' => array('created'),
- * 'node_moderate' => array('moderate'),
- * 'node_frontpage' => array('promote', 'status', 'sticky', 'created'),
- * 'node_status_type' => array('status', 'type', 'nid'),
- * 'node_title_type' => array('title', array('type', 4)),
- * 'node_type' => array(array('type', 4)),
- * 'uid' => array('uid'),
- * 'translate' => array('translate'),
- * ),
- * 'unique keys' => array(
- * 'vid' => array('vid'),
- * ),
- * 'foreign keys' => array(
- * 'node_revision' => array(
- * 'table' => 'node_field_revision',
- * 'columns' => array('vid' => 'vid'),
- * ),
- * 'node_author' => array(
- * 'table' => 'users',
- * 'columns' => array('uid' => 'uid'),
- * ),
- * ),
- * 'primary key' => array('nid'),
- * );
- * @endcode
- *
- * @see drupal_install_schema()
- *
- * @}
- */
-
-/**
- * @addtogroup hooks
- * @{
- */
-
-/**
- * Perform alterations to a structured query.
- *
- * Structured (aka dynamic) queries that have tags associated may be altered by any module
- * before the query is executed.
- *
- * @param $query
- * A Query object describing the composite parts of a SQL query.
- *
- * @see hook_query_TAG_alter()
- * @see node_query_node_access_alter()
- * @see AlterableInterface
- * @see SelectInterface
- *
- * @ingroup database
- */
-function hook_query_alter(Drupal\Core\Database\Query\AlterableInterface $query) {
- if ($query->hasTag('micro_limit')) {
- $query->range(0, 2);
- }
-}
-
-/**
- * Perform alterations to a structured query for a given tag.
- *
- * @param $query
- * An Query object describing the composite parts of a SQL query.
- *
- * @see hook_query_alter()
- * @see node_query_node_access_alter()
- * @see AlterableInterface
- * @see SelectInterface
- *
- * @ingroup database
- */
-function hook_query_TAG_alter(Drupal\Core\Database\Query\AlterableInterface $query) {
- // Skip the extra expensive alterations if site has no node access control modules.
- if (!node_access_view_all_nodes()) {
- // Prevent duplicates records.
- $query->distinct();
- // The recognized operations are 'view', 'update', 'delete'.
- if (!$op = $query->getMetaData('op')) {
- $op = 'view';
- }
- // Skip the extra joins and conditions for node admins.
- if (!\Drupal::currentUser()->hasPermission('bypass node access')) {
- // The node_access table has the access grants for any given node.
- $access_alias = $query->join('node_access', 'na', '%alias.nid = n.nid');
- $or = db_or();
- // If any grant exists for the specified user, then user has access to the node for the specified operation.
- foreach (node_access_grants($op, $query->getMetaData('account')) as $realm => $gids) {
- foreach ($gids as $gid) {
- $or->condition(db_and()
- ->condition($access_alias . '.gid', $gid)
- ->condition($access_alias . '.realm', $realm)
- );
- }
- }
-
- if (count($or->conditions())) {
- $query->condition($or);
- }
-
- $query->condition($access_alias . 'grant_' . $op, 1, '>=');
- }
- }
-}
-
-/**
- * Define the current version of the database schema.
- *
- * A Drupal schema definition is an array structure representing one or more
- * tables and their related keys and indexes. A schema is defined by
- * hook_schema() which must live in your module's .install file.
- *
- * The tables declared by this hook will be automatically created when the
- * module is installed, and removed when the module is uninstalled. This happens
- * before hook_install() is invoked, and after hook_uninstall() is invoked,
- * respectively.
- *
- * By declaring the tables used by your module via an implementation of
- * hook_schema(), these tables will be available on all supported database
- * engines. You don't have to deal with the different SQL dialects for table
- * creation and alteration of the supported database engines.
- *
- * See the Schema API Handbook at http://drupal.org/node/146843 for details on
- * schema definition structures.
- *
- * @return array
- * A schema definition structure array. For each element of the
- * array, the key is a table name and the value is a table structure
- * definition.
- *
- * @see hook_schema_alter()
- *
- * @ingroup schemaapi
- */
-function hook_schema() {
- $schema['node'] = array(
- // Example (partial) specification for table "node".
- 'description' => 'The base table for nodes.',
- 'fields' => array(
- 'nid' => array(
- 'description' => 'The primary identifier for a node.',
- 'type' => 'serial',
- 'unsigned' => TRUE,
- 'not null' => TRUE,
- ),
- 'vid' => array(
- 'description' => 'The current {node_field_revision}.vid version identifier.',
- 'type' => 'int',
- 'unsigned' => TRUE,
- 'not null' => TRUE,
- 'default' => 0,
- ),
- 'type' => array(
- 'description' => 'The type of this node.',
- 'type' => 'varchar',
- 'length' => 32,
- 'not null' => TRUE,
- 'default' => '',
- ),
- 'title' => array(
- 'description' => 'The node title.',
- 'type' => 'varchar',
- 'length' => 255,
- 'not null' => TRUE,
- 'default' => '',
- ),
- ),
- 'indexes' => array(
- 'node_changed' => array('changed'),
- 'node_created' => array('created'),
- ),
- 'unique keys' => array(
- 'nid_vid' => array('nid', 'vid'),
- 'vid' => array('vid'),
- ),
- 'foreign keys' => array(
- 'node_revision' => array(
- 'table' => 'node_field_revision',
- 'columns' => array('vid' => 'vid'),
- ),
- 'node_author' => array(
- 'table' => 'users',
- 'columns' => array('uid' => 'uid'),
- ),
- ),
- 'primary key' => array('nid'),
- );
- return $schema;
-}
-
-/**
- * Perform alterations to existing database schemas.
- *
- * When a module modifies the database structure of another module (by
- * changing, adding or removing fields, keys or indexes), it should
- * implement hook_schema_alter() to update the default $schema to take its
- * changes into account.
- *
- * See hook_schema() for details on the schema definition structure.
- *
- * @param $schema
- * Nested array describing the schemas for all modules.
- *
- * @ingroup schemaapi
- */
-function hook_schema_alter(&$schema) {
- // Add field to existing schema.
- $schema['users']['fields']['timezone_id'] = array(
- 'type' => 'int',
- 'not null' => TRUE,
- 'default' => 0,
- 'description' => 'Per-user timezone configuration.',
- );
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
diff --git a/core/modules/system/entity.api.php b/core/modules/system/entity.api.php
deleted file mode 100644
index 9d9b33e..0000000
--- a/core/modules/system/entity.api.php
+++ /dev/null
@@ -1,1954 +0,0 @@
-create();
- *
- * // Add code here to set properties on the entity.
- *
- * // Until you call save(), the entity is just in memory.
- * $entity->save();
- * @endcode
- * There is also a shortcut method on entity classes, which creates an entity
- * with an array of provided property values: \Drupal\Core\Entity::create().
- *
- * Hooks invoked during the create operation:
- * - hook_ENTITY_TYPE_create()
- * - hook_entity_create()
- *
- * See @ref save below for the save portion of the operation.
- *
- * @section load Read/Load operations
- * To load (read) a single entity:
- * @code
- * $entity = $storage->load($id);
- * @endcode
- * To load multiple entities:
- * @code
- * $entities = $storage->loadMultiple($ids);
- * @endcode
- * Since load() calls loadMultiple(), these are really the same operation.
- * Here is the order of hooks and other operations that take place during
- * entity loading:
- * - Entity is loaded from storage.
- * - postLoad() is called on the entity class, passing in all of the loaded
- * entities.
- * - hook_entity_load()
- * - hook_ENTITY_TYPE_load()
- *
- * When an entity is loaded, normally the default entity revision is loaded.
- * It is also possible to load a different revision, for entities that support
- * revisions, with this code:
- * @code
- * $entity = $storage->loadRevision($revision_id);
- * @endcode
- * This involves the same hooks and operations as regular entity loading.
- *
- * @section save Save operations
- * To update an existing entity, you will need to load it, change properties,
- * and then save; as described above, when creating a new entity, you will also
- * need to save it. Here is the order of hooks and other events that happen
- * during an entity save:
- * - preSave() is called on the entity object, and field objects.
- * - hook_ENTITY_TYPE_presave()
- * - hook_entity_presave()
- * - Entity is saved to storage.
- * - For updates on content entities, if there is a translation added that
- * was not previously present:
- * - hook_ENTITY_TYPE_translation_insert()
- * - hook_entity_translation_insert()
- * - For updates on content entities, if there was a translation removed:
- * - hook_ENTITY_TYPE_translation_delete()
- * - hook_entity_translation_delete()
- * - postSave() is called on the entity object.
- * - hook_ENTITY_TYPE_insert() (new) or hook_ENTITY_TYPE_update() (update)
- * - hook_entity_insert() (new) or hook_entity_update() (update)
- *
- * Some specific entity types invoke hooks during preSave() or postSave()
- * operations. Examples:
- * - Field configuration preSave(): hook_field_storage_config_update_forbid()
- * - Node postSave(): hook_node_access_records() and
- * hook_node_access_records_alter()
- * - Config entities that are acting as entity bundles, in postSave():
- * hook_entity_bundle_create() or hook_entity_bundle_rename() as appropriate
- * - Comment: hook_comment_publish() and hook_comment_unpublish() as
- * appropriate.
- *
- * @section edit Editing operations
- * When an entity's add/edit form is used to add or edit an entity, there
- * are several hooks that are invoked:
- * - hook_entity_prepare_form()
- * - hook_ENTITY_TYPE_prepare_form()
- * - hook_entity_form_display_alter() (for content entities only)
- *
- * @section delete Delete operations
- * To delete one or more entities, load them and then delete them:
- * @code
- * $entities = $storage->loadMultiple($ids);
- * $storage->delete($entities);
- * @endcode
- *
- * During the delete operation, the following hooks and other events happen:
- * - preDelete() is called on the entity class.
- * - hook_ENTITY_TYPE_predelete()
- * - hook_entity_predelete()
- * - Entity and field information is removed from storage.
- * - postDelete() is called on the entity class.
- * - hook_ENTITY_TYPE_delete()
- * - hook_entity_delete()
- *
- * Some specific entity types invoke hooks during the delete process. Examples:
- * - Entity bundle postDelete(): hook_entity_bundle_delete()
- *
- * Individual revisions of an entity can also be deleted:
- * @code
- * $storage->deleteRevision($revision_id);
- * @endcode
- * This operation invokes the following operations and hooks:
- * - Revision is loaded (see @ref load above).
- * - Revision and field information is removed from the database.
- * - hook_ENTITY_TYPE_revision_delete()
- * - hook_entity_revision_delete()
- *
- * @section view View/render operations
- * To make a render array for a loaded entity:
- * @code
- * // You can omit the language ID if the default language is being used.
- * $build = $view_builder->view($entity, 'view_mode_name', $language->getId());
- * @endcode
- * You can also use the viewMultiple() method to view multiple entities.
- *
- * Hooks invoked during the operation of building a render array:
- * - hook_entity_view_mode_alter()
- * - hook_ENTITY_TYPE_build_defaults_alter()
- * - hook_entity_build_defaults_alter()
- *
- * View builders for some types override these hooks, notably:
- * - The Tour view builder does not invoke any hooks.
- * - The Block view builder invokes hook_block_view_alter() and
- * hook_block_view_BASE_BLOCK_ID_alter(). Note that in other view builders,
- * the view alter hooks are run later in the process.
- *
- * During the rendering operation, the default entity viewer runs the following
- * hooks and operations in the pre-render step:
- * - hook_entity_view_display_alter()
- * - hook_entity_prepare_view()
- * - Entity fields are loaded, and render arrays are built for them using
- * their formatters.
- * - hook_entity_display_build_alter()
- * - hook_ENTITY_TYPE_view()
- * - hook_entity_view()
- * - hook_ENTITY_TYPE_view_alter()
- * - hook_entity_view_alter()
- *
- * Some specific builders have specific hooks:
- * - The Node view builder invokes hook_node_links_alter().
- * - The Comment view builder invokes hook_comment_links_alter().
- *
- * After this point in rendering, the theme system takes over. See the
- * @link theme_render Theme system and render API topic @endlink for more
- * information.
- *
- * @section misc Other entity hooks
- * Some types of entities invoke hooks for specific operations:
- * - Searching nodes:
- * - hook_ranking()
- * - Query is executed to find matching nodes
- * - Resulting node is loaded
- * - Node render array is built
- * - comment_node_update_index() is called (this adds "N comments" text)
- * - hook_node_search_result()
- * - Search indexing nodes:
- * - Node is loaded
- * - Node render array is built
- * - hook_node_update_index()
- * @}
- */
-
-/**
- * @defgroup entity_api Entity API
- * @{
- * Describes how to define and manipulate content and configuration entities.
- *
- * Entities, in Drupal, are objects that are used for persistent storage of
- * content and configuration information. See the
- * @link info_types Information types topic @endlink for an overview of the
- * different types of information, and the
- * @link config_api Configuration API topic @endlink for more about the
- * configuration API.
- *
- * Each entity is an instance of a particular "entity type". Some content entity
- * types have sub-types, which are known as "bundles", while for other entity
- * types, there is only a single bundle. For example, the Node content entity
- * type, which is used for the main content pages in Drupal, has bundles that
- * are known as "content types", while the User content type, which is used for
- * user accounts, has only one bundle.
- *
- * The sections below have more information about entities and the Entity API;
- * for more detailed information, see https://drupal.org/developing/api/entity
- *
- * @section define Defining an entity type
- * Entity types are defined by modules, using Drupal's Plugin API (see the
- * @link plugin_api Plugin API topic @endlink for more information about plugins
- * in general). Here are the steps to follow to define a new entity type:
- * - Choose a unique machine name, or ID, for your entity type. This normally
- * starts with (or is the same as) your module's machine name. It should be
- * as short as possible, and may not exceed 32 characters.
- * - Define an interface for your entity's get/set methods, usually extending
- * either \Drupal\Core\Config\Entity\ConfigEntityInterface or
- * \Drupal\Core\Entity\ContentEntityInterface.
- * - Define a class for your entity, implementing your interface and extending
- * either \Drupal\Core\Config\Entity\ConfigEntityBase or
- * \Drupal\Core\Entity\ContentEntityBase, with annotation for
- * \@ConfigEntityType or \@ContentEntityType in its documentation block.
- * - The 'id' annotation gives the entity type ID, and the 'label' annotation
- * gives the human-readable name of the entity type. If you are defining a
- * content entity type that uses bundles, the 'bundle_label' annotation gives
- * the human-readable name to use for a bundle of this entity type (for
- * example, "Content type" for the Node entity).
- * - The annotation will refer to several controller classes, which you will
- * also need to define:
- * - list_builder: Define a class that extends
- * \Drupal\Core\Config\Entity\ConfigEntityListBuilder (for configuration
- * entities) or \Drupal\Core\Entity\EntityListBuilder (for content
- * entities), to provide an administrative overview for your entities.
- * - add and edit forms, or default form: Define a class (or two) that
- * extend(s) \Drupal\Core\Entity\EntityForm to provide add and edit forms
- * for your entities. For content entities, base class
- * \Drupal\Core\Entity\ContentEntityForm is a better starting point.
- * - delete form: Define a class that extends
- * \Drupal\Core\Entity\EntityConfirmFormBase to provide a delete
- * confirmation form for your entities.
- * - view_builder: For content entities and config entities that need to be
- * viewed, define a class that implements
- * \Drupal\Core\Entity\EntityViewBuilderInterface (usually extending
- * \Drupal\Core\Entity\EntityViewBuilder), to display a single entity.
- * - translation: For translatable content entities (if the 'translatable'
- * annotation has value TRUE), define a class that extends
- * \Drupal\content_translation\ContentTranslationHandler, to translate
- * the content. Configuration translation is handled automatically by the
- * Configuration Translation module, without the need of a controller class.
- * - access: If your configuration entity has complex permissions, you might
- * need an access control handling, implementing
- * \Drupal\Core\Entity\EntityAccessControlHandlerInterface, but most entities
- * can just use the 'admin_permission' annotation instead. Note that if you
- * are creating your own access control handler, you should override the
- * checkAccess() and checkCreateAccess() methods, not access().
- * - storage: A class implementing
- * \Drupal\Core\Entity\EntityStorageInterface. If not specified, content
- * entities will use \Drupal\Core\Entity\Sql\SqlContentEntityStorage, and
- * config entities will use \Drupal\Core\Config\Entity\ConfigEntityStorage.
- * You can extend one of these classes to provide custom behavior.
- * - views_data: A class implementing \Drupal\views\EntityViewsDataInterface
- * to provide views data for the entity type. You can autogenerate most of
- * the views data by extending \Drupal\views\EntityViewsData.
- * - For content entities, the annotation will refer to a number of database
- * tables and their fields. These annotation properties, such as 'base_table',
- * 'data_table', 'entity_keys', etc., are documented on
- * \Drupal\Core\Entity\EntityType. Your module will also need to set up its
- * database tables using hook_schema().
- * - For content entities that are displayed on their own pages, the annotation
- * will refer to a 'uri_callback' function, which takes an object of the
- * entity interface you have defined as its parameter, and returns routing
- * information for the entity page; see node_uri() for an example. You will
- * also need to add a corresponding route to your module's routing.yml file;
- * see the entity.node.canonical route in node.routing.yml for an example, and see
- * @ref sec_routes below for some notes.
- * - Define routes and links for the various URLs associated with the entity.
- * These go into the 'links' annotation, with the link type as the key, and
- * the path of this link template as the value. The corresponding route
- * requires the following route name:
- * "entity.$entity_type_id.$link_template_type". See @ref sec_routes below for
- * some routing notes. Typical link types are:
- * - canonical: Default link, either to view (if entities are viewed on their
- * own pages) or edit the entity.
- * - delete-form: Confirmation form to delete the entity.
- * - edit-form: Editing form.
- * - Other link types specific to your entity type can also be defined.
- * - If your content entity is fieldable, provide 'field_ui_base_route'
- * annotation, giving the name of the route that the Manage Fields, Manage
- * Display, and Manage Form Display pages from the Field UI module will be
- * attached to. This is usually the bundle settings edit page, or an entity
- * type settings page if there are no bundles.
- * - If your content entity has bundles, you will also need to define a second
- * plugin to handle the bundles. This plugin is itself a configuration entity
- * type, so follow the steps here to define it. The machine name ('id'
- * annotation) of this configuration entity class goes into the
- * 'bundle_entity_type' annotation on the entity type class. For example, for
- * the Node entity, the bundle class is \Drupal\node\Entity\NodeType, whose
- * machine name is 'node_type'. This is the annotation value for
- * 'bundle_entity_type' on the \Drupal\node\Entity\Node class. Also, the
- * bundle config entity type annotation must have a 'bundle_of' entry,
- * giving the machine name of the entity type it is acting as a bundle for.
- * - Additional annotations can be seen on entity class examples such as
- * \Drupal\node\Entity\Node (content) and \Drupal\user\Entity\Role
- * (configuration). These annotations are documented on
- * \Drupal\Core\Entity\EntityType.
- *
- * @section sec_routes Entity routes
- * Entity routes, like other routes, are defined in *.routing.yml files; see
- * the @link menu Menu and routing @endlink topic for more information. Here
- * is a typical entry, for the block configure form:
- * @code
- * entity.block.edit_form:
- * path: '/admin/structure/block/manage/{block}'
- * defaults:
- * _entity_form: 'block.default'
- * _title: 'Configure block'
- * requirements:
- * _entity_access: 'block.update'
- * @endcode
- * Some notes:
- * - path: The {block} in the path is a placeholder, which (for an entity) must
- * always take the form of {machine_name_of_entity_type}. In the URL, the
- * placeholder value will be the ID of an entity item. When the route is used,
- * the entity system will load the corresponding entity item and pass it in as
- * an object to the controller for the route.
- * - defaults: For entity form routes, use _entity_form rather than the generic
- * _controller or _form. The value is composed of the entity type machine name
- * and a form controller type from the entity annotation (see @ref define
- * above more more on controllers and annotation). So, in this example,
- * block.default refers to the 'default' form controller on the block entity
- * type, whose annotation contains:
- * @code
- * handlers = {
- * "form" = {
- * "default" = "Drupal\block\BlockForm",
- * @endcode
- *
- * @section bundle Defining a content entity bundle
- * For entity types that use bundles, such as Node (bundles are content types)
- * and Taxonomy (bundles are vocabularies), modules and install profiles can
- * define bundles by supplying default configuration in their config/install
- * directories. (See the @link config_api Configuration API topic @endlink for
- * general information about configuration.)
- *
- * There are several good examples of this in Drupal Core:
- * - The Forum module defines a content type in node.type.forum.yml and a
- * vocabulary in taxonomy.vocabulary.forums.yml
- * - The Book module defines a content type in node.type.book.yml
- * - The Standard install profile defines Page and Article content types in
- * node.type.page.yml and node.type.article.yml, a Tags vocabulary in
- * taxonomy.vocabulary.tags.yml, and a Node comment type in
- * comment.type.comment.yml. This profile's configuration is especially
- * instructive, because it also adds several fields to the Article type, and
- * it sets up view and form display modes for the node types.
- *
- * @section load_query Loading, querying, and rendering entities
- * To load entities, use the entity storage manager, which is an object
- * implementing \Drupal\Core\Entity\EntityStorageInterface that you can
- * retrieve with:
- * @code
- * $storage = \Drupal::entityManager()->getStorage('your_entity_type');
- * // Or if you have a $container variable:
- * $storage = $container->get('entity.manager')->getStorage('your_entity_type');
- * @endcode
- * Here, 'your_entity_type' is the machine name of your entity type ('id'
- * annotation on the entity class), and note that you should use dependency
- * injection to retrieve this object if possible. See the
- * @link container Services and Dependency Injection topic @endlink for more
- * about how to properly retrieve services.
- *
- * To query to find entities to load, use an entity query, which is a object
- * implementing \Drupal\Core\Entity\Query\QueryInterface that you can retrieve
- * with:
- * @code
- * // Simple query:
- * $query = \Drupal::entityQuery('your_entity_type');
- * // Or, if you have a $container variable:
- * $query_service = $container->get('entity.query');
- * $query = $query_service->get('your_entity_type');
- * @endcode
- * If you need aggregation, there is an aggregate query available, which
- * implements \Drupal\Core\Entity\Query\QueryAggregateInterface:
- * @code
- * $query \Drupal::entityQueryAggregate('your_entity_type');
- * // Or:
- * $query = $query_service->getAggregate('your_entity_type');
- * @endcode
- * Also, you should use dependency injection to get this object if
- * possible; the service you need is entity.query, and its methods getQuery()
- * or getAggregateQuery() will get the query object.
- *
- * In either case, you can then add conditions to your query, using methods
- * like condition(), exists(), etc. on $query; add sorting, pager, and range
- * if needed, and execute the query to return a list of entity IDs that match
- * the query.
- *
- * Here is an example, using the core File entity:
- * @code
- * $fids = Drupal::entityQuery('file')
- * ->condition('status', FILE_STATUS_PERMANENT, '<>')
- * ->condition('changed', REQUEST_TIME - $age, '<')
- * ->range(0, 100)
- * ->execute();
- * $files = $storage->loadMultiple($fids);
- * @endcode
- *
- * The normal way of viewing entities is by using a route, as described in the
- * sections above. If for some reason you need to render an entity in code in a
- * particular view mode, you can use an entity view builder, which is an object
- * implementing \Drupal\Core\Entity\EntityViewBuilderInterface that you can
- * retrieve with:
- * @code
- * $view_builder = \Drupal::entityManager()->getViewBuilder('your_entity_type');
- * // Or if you have a $container variable:
- * $view_builder = $container->get('entity.manager')->getViewBuilder('your_entity_type');
- * @endcode
- * Then, to build and render the entity:
- * @code
- * // You can omit the language ID if the default language is being used.
- * $build = $view_builder->view($entity, 'view_mode_name', $language->getId());
- * // $build is a render array.
- * $rendered = drupal_render($build);
- * @endcode
- *
- * @section sec_access Access checking on entities
- * Entity types define their access permission scheme in their annotation.
- * Access permissions can be quite complex, so you should not assume any
- * particular permission scheme. Instead, once you have an entity object
- * loaded, you can check for permission for a particular operation (such as
- * 'view') at the entity or field level by calling:
- * @code
- * $entity->access($operation);
- * $entity->nameOfField->access($operation);
- * @endcode
- * The interface related to access checking in entities and fields is
- * \Drupal\Core\Access\AccessibleInterface.
- *
- * The default entity access control handler invokes two hooks while checking
- * access on a single entity: hook_entity_access() is invoked first, and
- * then hook_ENTITY_TYPE_access() (where ENTITY_TYPE is the machine name
- * of the entity type). If no module returns a TRUE or FALSE value from
- * either of these hooks, then the entity's default access checking takes
- * place. For create operations (creating a new entity), the hooks that
- * are invoked are hook_entity_create_access() and
- * hook_ENTITY_TYPE_create_access() instead.
- *
- * The Node entity type has a complex system for determining access, which
- * developers can interact with. This is described in the
- * @link node_access Node access topic. @endlink
- *
- * @see i18n
- * @see entity_crud
- * @}
- */
-
-/**
- * @addtogroup hooks
- * @{
- */
-
-/**
- * Control entity operation access.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity to check access to.
- * @param string $operation
- * The operation that is to be performed on $entity.
- * @param \Drupal\Core\Session\AccountInterface $account
- * The account trying to access the entity.
- * @param string $langcode
- * The code of the language $entity is accessed in.
- *
- * @return \Drupal\Core\Access\AccessResultInterface
- * The access result.
- *
- * @see \Drupal\Core\Entity\EntityAccessControlHandler
- * @see hook_entity_create_access()
- * @see hook_ENTITY_TYPE_access()
- *
- * @ingroup entity_api
- */
-function hook_entity_access(\Drupal\Core\Entity\EntityInterface $entity, $operation, \Drupal\Core\Session\AccountInterface $account, $langcode) {
- // No opinion.
- return AccessResult::neutral();
-}
-
-/**
- * Control entity operation access for a specific entity type.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity to check access to.
- * @param string $operation
- * The operation that is to be performed on $entity.
- * @param \Drupal\Core\Session\AccountInterface $account
- * The account trying to access the entity.
- * @param string $langcode
- * The code of the language $entity is accessed in.
- *
- * @return \Drupal\Core\Access\AccessResultInterface
- * The access result.
- *
- * @see \Drupal\Core\Entity\EntityAccessControlHandler
- * @see hook_ENTITY_TYPE_create_access()
- * @see hook_entity_access()
- *
- * @ingroup entity_api
- */
-function hook_ENTITY_TYPE_access(\Drupal\Core\Entity\EntityInterface $entity, $operation, \Drupal\Core\Session\AccountInterface $account, $langcode) {
- // No opinion.
- return AccessResult::neutral();
-}
-
-/**
- * Control entity create access.
- *
- * @param \Drupal\Core\Session\AccountInterface $account
- * The account trying to access the entity.
- * @param array $context
- * An associative array of additional context values. By default it contains
- * language:
- * - langcode - the current language code.
- * @param string $entity_bundle
- * The entity bundle name.
- *
- * @return \Drupal\Core\Access\AccessResultInterface
- * The access result.
- *
- * @see \Drupal\Core\Entity\EntityAccessControlHandler
- * @see hook_entity_access()
- * @see hook_ENTITY_TYPE_create_access()
- *
- * @ingroup entity_api
- */
-function hook_entity_create_access(\Drupal\Core\Session\AccountInterface $account, array $context, $entity_bundle) {
- // No opinion.
- return AccessResult::neutral();
-}
-
-/**
- * Control entity create access for a specific entity type.
- *
- * @param \Drupal\Core\Session\AccountInterface $account
- * The account trying to access the entity.
- * @param array $context
- * An associative array of additional context values. By default it contains
- * language:
- * - langcode - the current language code.
- * @param string $entity_bundle
- * The entity bundle name.
- *
- * @return \Drupal\Core\Access\AccessResultInterface
- * The access result.
- *
- * @see \Drupal\Core\Entity\EntityAccessControlHandler
- * @see hook_ENTITY_TYPE_access()
- * @see hook_entity_create_access()
- *
- * @ingroup entity_api
- */
-function hook_ENTITY_TYPE_create_access(\Drupal\Core\Session\AccountInterface $account, array $context, $entity_bundle) {
- // No opinion.
- return AccessResult::neutral();
-}
-
-/**
- * Add to entity type definitions.
- *
- * Modules may implement this hook to add information to defined entity types,
- * as defined in \Drupal\Core\Entity\EntityTypeInterface.
- *
- * @param \Drupal\Core\Entity\EntityTypeInterface[] $entity_types
- * An associative array of all entity type definitions, keyed by the entity
- * type name. Passed by reference.
- *
- * @see \Drupal\Core\Entity\Entity
- * @see \Drupal\Core\Entity\EntityTypeInterface
- */
-function hook_entity_type_build(array &$entity_types) {
- /** @var $entity_types \Drupal\Core\Entity\EntityTypeInterface[] */
- // Add a form for a custom node form without overriding the default
- // node form. To override the default node form, use hook_entity_type_alter().
- $entity_types['node']->setFormClass('mymodule_foo', 'Drupal\mymodule\NodeFooForm');
-}
-
-/**
- * Alter the entity type definitions.
- *
- * Modules may implement this hook to alter the information that defines an
- * entity type. All properties that are available in
- * \Drupal\Core\Entity\Annotation\EntityType and all the ones additionally
- * provided by modules can be altered here.
- *
- * Do not use this hook to add information to entity types, unless you are just
- * filling-in default values. Use hook_entity_type_build() instead.
- *
- * @param \Drupal\Core\Entity\EntityTypeInterface[] $entity_types
- * An associative array of all entity type definitions, keyed by the entity
- * type name. Passed by reference.
- *
- * @see \Drupal\Core\Entity\Entity
- * @see \Drupal\Core\Entity\EntityTypeInterface
- */
-function hook_entity_type_alter(array &$entity_types) {
- /** @var $entity_types \Drupal\Core\Entity\EntityTypeInterface[] */
- // Set the controller class for nodes to an alternate implementation of the
- // Drupal\Core\Entity\EntityStorageInterface interface.
- $entity_types['node']->setStorageClass('Drupal\mymodule\MyCustomNodeStorage');
-}
-
-/**
- * Alter the view modes for entity types.
- *
- * @param array $view_modes
- * An array of view modes, keyed first by entity type, then by view mode name.
- *
- * @see \Drupal\Core\Entity\EntityManagerInterface::getAllViewModes()
- * @see \Drupal\Core\Entity\EntityManagerInterface::getViewModes()
- * @see hook_entity_view_mode_info()
- */
-function hook_entity_view_mode_info_alter(&$view_modes) {
- $view_modes['user']['full']['status'] = TRUE;
-}
-
-/**
- * Describe the bundles for entity types.
- *
- * @return 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 entity_get_bundles()
- * @see hook_entity_bundle_info_alter()
- */
-function hook_entity_bundle_info() {
- $bundles['user']['user']['label'] = t('User');
- return $bundles;
-}
-
-/**
- * Alter the bundles for entity types.
- *
- * @param array $bundles
- * An array of bundles, keyed first by entity type, then by bundle name.
- *
- * @see entity_get_bundles()
- * @see hook_entity_bundle_info()
- */
-function hook_entity_bundle_info_alter(&$bundles) {
- $bundles['user']['user']['label'] = t('Full account');
-}
-
-/**
- * Act on entity_bundle_create().
- *
- * This hook is invoked after the operation has been performed.
- *
- * @param string $entity_type_id
- * The type of $entity; e.g. 'node' or 'user'.
- * @param string $bundle
- * The name of the bundle.
- *
- * @see entity_crud
- */
-function hook_entity_bundle_create($entity_type_id, $bundle) {
- // When a new bundle is created, the menu needs to be rebuilt to add the
- // Field UI menu item tabs.
- \Drupal::service('router.builder')->setRebuildNeeded();
-}
-
-/**
- * Act on entity_bundle_rename().
- *
- * This hook is invoked after the operation has been performed.
- *
- * @param string $entity_type_id
- * The entity type to which the bundle is bound.
- * @param string $bundle_old
- * The previous name of the bundle.
- * @param string $bundle_new
- * The new name of the bundle.
- *
- * @see entity_crud
- */
-function hook_entity_bundle_rename($entity_type_id, $bundle_old, $bundle_new) {
- // Update the settings associated with the bundle in my_module.settings.
- $config = \Drupal::config('my_module.settings');
- $bundle_settings = $config->get('bundle_settings');
- if (isset($bundle_settings[$entity_type_id][$bundle_old])) {
- $bundle_settings[$entity_type_id][$bundle_new] = $bundle_settings[$entity_type_id][$bundle_old];
- unset($bundle_settings[$entity_type_id][$bundle_old]);
- $config->set('bundle_settings', $bundle_settings);
- }
-}
-
-/**
- * Act on entity_bundle_delete().
- *
- * This hook is invoked after the operation has been performed.
- *
- * @param string $entity_type_id
- * The type of entity; for example, 'node' or 'user'.
- * @param string $bundle
- * The bundle that was just deleted.
- *
- * @ingroup entity_crud
- */
-function hook_entity_bundle_delete($entity_type_id, $bundle) {
- // Remove the settings associated with the bundle in my_module.settings.
- $config = \Drupal::config('my_module.settings');
- $bundle_settings = $config->get('bundle_settings');
- if (isset($bundle_settings[$entity_type_id][$bundle])) {
- unset($bundle_settings[$entity_type_id][$bundle]);
- $config->set('bundle_settings', $bundle_settings);
- }
-}
-
-/**
- * Act on a newly created entity.
- *
- * This hook runs after a new entity object has just been instantiated. It can
- * be used to set initial values, e.g. to provide defaults.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_create()
- */
-function hook_entity_create(\Drupal\Core\Entity\EntityInterface $entity) {
- if ($entity instanceof FieldableEntityInterface && !$entity->foo->value) {
- $entity->foo->value = 'some_initial_value';
- }
-}
-
-/**
- * Act on a newly created entity of a specific type.
- *
- * This hook runs after a new entity object has just been instantiated. It can
- * be used to set initial values, e.g. to provide defaults.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_entity_create()
- */
-function hook_ENTITY_TYPE_create(\Drupal\Core\Entity\EntityInterface $entity) {
- if (!$entity->foo->value) {
- $entity->foo->value = 'some_initial_value';
- }
-}
-
-/**
- * Act on entities when loaded.
- *
- * This is a generic load hook called for all entity types loaded via the
- * entity API.
- *
- * hook_entity_storage_load() should be used to load additional data for
- * content entities.
- *
- * @param \Drupal\Core\Entity\EntityInterface[] $entities
- * The entities keyed by entity ID.
- * @param string $entity_type_id
- * The type of entities being loaded (i.e. node, user, comment).
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_load()
- */
-function hook_entity_load(array $entities, $entity_type_id) {
- foreach ($entities as $entity) {
- $entity->foo = mymodule_add_something($entity);
- }
-}
-
-/**
- * Act on entities of a specific type when loaded.
- *
- * @param array $entities
- * The entities keyed by entity ID.
- *
- * @ingroup entity_crud
- * @see hook_entity_load()
- */
-function hook_ENTITY_TYPE_load($entities) {
- foreach ($entities as $entity) {
- $entity->foo = mymodule_add_something($entity);
- }
-}
-
-/**
- * Act on content entities when loaded from the storage.
- *
- * The results of this hook will be cached.
- *
- * @param \Drupal\Core\Entity\EntityInterface[] $entities
- * The entities keyed by entity ID.
- * @param string $entity_type
- * The type of entities being loaded (i.e. node, user, comment).
- *
- * @see hook_entity_load()
- */
-function hook_entity_storage_load(array $entities, $entity_type) {
- foreach ($entities as $entity) {
- $entity->foo = mymodule_add_something_uncached($entity);
- }
-}
-
-/**
- * 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.
- *
- * @param \Drupal\Core\Entity\EntityInterface[] $entities
- * The entities keyed by entity ID.
- *
- * @see hook_entity_storage_load()
- */
-function hook_ENTITY_TYPE_storage_load(array $entities) {
- foreach ($entities as $entity) {
- $entity->foo = mymodule_add_something_uncached($entity);
- }
-}
-
-/**
- * Act on an entity before it is created or updated.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_presave()
- */
-function hook_entity_presave(Drupal\Core\Entity\EntityInterface $entity) {
- if ($entity instanceof ContentEntityInterface && $entity->isTranslatable()) {
- $route_match = \Drupal::routeMatch();
- \Drupal::service('content_translation.synchronizer')->synchronizeFields($entity, $entity->language()->getId(), $route_match->getParameter('source_langcode'));
- }
-}
-
-/**
- * Act on a specific type of entity before it is created or updated.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_entity_presave()
- */
-function hook_ENTITY_TYPE_presave(Drupal\Core\Entity\EntityInterface $entity) {
- if ($entity->isTranslatable()) {
- $route_match = \Drupal::routeMatch();
- \Drupal::service('content_translation.synchronizer')->synchronizeFields($entity, $entity->language()->getId(), $route_match->getParameter('source_langcode'));
- }
-}
-
-/**
- * Respond to creation of a new entity.
- *
- * This hook runs once the entity has been stored. Note that hook
- * implementations may not alter the stored entity data.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_insert()
- */
-function hook_entity_insert(Drupal\Core\Entity\EntityInterface $entity) {
- // Insert the new entity into a fictional table of all entities.
- db_insert('example_entity')
- ->fields(array(
- 'type' => $entity->getEntityTypeId(),
- 'id' => $entity->id(),
- 'created' => REQUEST_TIME,
- 'updated' => REQUEST_TIME,
- ))
- ->execute();
-}
-
-/**
- * Respond to creation of a new entity of a particular type.
- *
- * This hook runs once the entity has been stored. Note that hook
- * implementations may not alter the stored entity data.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_entity_insert()
- */
-function hook_ENTITY_TYPE_insert(Drupal\Core\Entity\EntityInterface $entity) {
- // Insert the new entity into a fictional table of this type of entity.
- db_insert('example_entity')
- ->fields(array(
- 'id' => $entity->id(),
- 'created' => REQUEST_TIME,
- 'updated' => REQUEST_TIME,
- ))
- ->execute();
-}
-
-/**
- * Respond to updates to an entity.
- *
- * This hook runs once the entity storage has been updated. Note that hook
- * implementations may not alter the stored entity data.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_update()
- */
-function hook_entity_update(Drupal\Core\Entity\EntityInterface $entity) {
- // Update the entity's entry in a fictional table of all entities.
- db_update('example_entity')
- ->fields(array(
- 'updated' => REQUEST_TIME,
- ))
- ->condition('type', $entity->getEntityTypeId())
- ->condition('id', $entity->id())
- ->execute();
-}
-
-/**
- * Respond to updates to an entity of a particular type.
- *
- * This hook runs once the entity storage has been updated. Note that hook
- * implementations may not alter the stored entity data.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- *
- * @ingroup entity_crud
- * @see hook_entity_update()
- */
-function hook_ENTITY_TYPE_update(Drupal\Core\Entity\EntityInterface $entity) {
- // Update the entity's entry in a fictional table of this type of entity.
- db_update('example_entity')
- ->fields(array(
- 'updated' => REQUEST_TIME,
- ))
- ->condition('id', $entity->id())
- ->execute();
-}
-
-/**
- * Respond to creation of a new entity translation.
- *
- * This hook runs once the entity translation has been stored. Note that hook
- * implementations may not alter the stored entity translation data.
- *
- * @param \Drupal\Core\Entity\EntityInterface $translation
- * The entity object of the translation just stored.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_translation_insert()
- */
-function hook_entity_translation_insert(\Drupal\Core\Entity\EntityInterface $translation) {
- $variables = array(
- '@language' => $translation->language()->name,
- '@label' => $translation->getUntranslated()->label(),
- );
- \Drupal::logger('example')->notice('The @language translation of @label has just been stored.', $variables);
-}
-
-/**
- * Respond to creation of a new entity translation of a particular type.
- *
- * This hook runs once the entity translation has been stored. Note that hook
- * implementations may not alter the stored entity translation data.
- *
- * @param \Drupal\Core\Entity\EntityInterface $translation
- * The entity object of the translation just stored.
- *
- * @ingroup entity_crud
- * @see hook_entity_translation_insert()
- */
-function hook_ENTITY_TYPE_translation_insert(\Drupal\Core\Entity\EntityInterface $translation) {
- $variables = array(
- '@language' => $translation->language()->name,
- '@label' => $translation->getUntranslated()->label(),
- );
- \Drupal::logger('example')->notice('The @language translation of @label has just been stored.', $variables);
-}
-
-/**
- * Respond to entity translation deletion.
- *
- * This hook runs once the entity translation has been deleted from storage.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The original entity object.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_translation_delete()
- */
-function hook_entity_translation_delete(\Drupal\Core\Entity\EntityInterface $translation) {
- $languages = \Drupal::languageManager()->getLanguages();
- $variables = array(
- '@language' => $languages[$langcode]->name,
- '@label' => $entity->label(),
- );
- \Drupal::logger('example')->notice('The @language translation of @label has just been deleted.', $variables);
-}
-
-/**
- * Respond to entity translation deletion of a particular type.
- *
- * This hook runs once the entity translation has been deleted from storage.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The original entity object.
- *
- * @ingroup entity_crud
- * @see hook_entity_translation_delete()
- */
-function hook_ENTITY_TYPE_translation_delete(\Drupal\Core\Entity\EntityInterface $translation) {
- $languages = \Drupal::languageManager()->getLanguages();
- $variables = array(
- '@language' => $languages[$langcode]->name,
- '@label' => $entity->label(),
- );
- \Drupal::logger('example')->notice('The @language translation of @label has just been deleted.', $variables);
-}
-
-/**
- * Act before entity deletion.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object for the entity that is about to be deleted.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_predelete()
- */
-function hook_entity_predelete(Drupal\Core\Entity\EntityInterface $entity) {
- // Count references to this entity in a custom table before they are removed
- // upon entity deletion.
- $id = $entity->id();
- $type = $entity->getEntityTypeId();
- $count = db_select('example_entity_data')
- ->condition('type', $type)
- ->condition('id', $id)
- ->countQuery()
- ->execute()
- ->fetchField();
-
- // Log the count in a table that records this statistic for deleted entities.
- db_merge('example_deleted_entity_statistics')
- ->key(array('type' => $type, 'id' => $id))
- ->fields(array('count' => $count))
- ->execute();
-}
-
-/**
- * Act before entity deletion of a particular entity type.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object for the entity that is about to be deleted.
- *
- * @ingroup entity_crud
- * @see hook_entity_predelete()
- */
-function hook_ENTITY_TYPE_predelete(Drupal\Core\Entity\EntityInterface $entity) {
- // Count references to this entity in a custom table before they are removed
- // upon entity deletion.
- $id = $entity->id();
- $type = $entity->getEntityTypeId();
- $count = db_select('example_entity_data')
- ->condition('type', $type)
- ->condition('id', $id)
- ->countQuery()
- ->execute()
- ->fetchField();
-
- // Log the count in a table that records this statistic for deleted entities.
- db_merge('example_deleted_entity_statistics')
- ->key(array('type' => $type, 'id' => $id))
- ->fields(array('count' => $count))
- ->execute();
-}
-
-/**
- * Respond to entity deletion.
- *
- * This hook runs once the entity has been deleted from the storage.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object for the entity that has been deleted.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_delete()
- */
-function hook_entity_delete(Drupal\Core\Entity\EntityInterface $entity) {
- // Delete the entity's entry from a fictional table of all entities.
- db_delete('example_entity')
- ->condition('type', $entity->getEntityTypeId())
- ->condition('id', $entity->id())
- ->execute();
-}
-
-/**
- * Respond to entity deletion of a particular type.
- *
- * This hook runs once the entity has been deleted from the storage.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object for the entity that has been deleted.
- *
- * @ingroup entity_crud
- * @see hook_entity_delete()
- */
-function hook_ENTITY_TYPE_delete(Drupal\Core\Entity\EntityInterface $entity) {
- // Delete the entity's entry from a fictional table of all entities.
- db_delete('example_entity')
- ->condition('type', $entity->getEntityTypeId())
- ->condition('id', $entity->id())
- ->execute();
-}
-
-/**
- * Respond to entity revision deletion.
- *
- * This hook runs once the entity revision has been deleted from the storage.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object for the entity revision that has been deleted.
- *
- * @ingroup entity_crud
- * @see hook_ENTITY_TYPE_revision_delete()
- */
-function hook_entity_revision_delete(Drupal\Core\Entity\EntityInterface $entity) {
- $referenced_files_by_field = _editor_get_file_uuids_by_field($entity);
- foreach ($referenced_files_by_field as $field => $uuids) {
- _editor_delete_file_usage($uuids, $entity, 1);
- }
-}
-
-/**
- * Respond to entity revision deletion of a particular type.
- *
- * This hook runs once the entity revision has been deleted from the storage.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object for the entity revision that has been deleted.
- *
- * @ingroup entity_crud
- * @see hook_entity_revision_delete()
- */
-function hook_ENTITY_TYPE_revision_delete(Drupal\Core\Entity\EntityInterface $entity) {
- $referenced_files_by_field = _editor_get_file_uuids_by_field($entity);
- foreach ($referenced_files_by_field as $field => $uuids) {
- _editor_delete_file_usage($uuids, $entity, 1);
- }
-}
-
-/**
- * Alter or execute an Drupal\Core\Entity\Query\EntityQueryInterface.
- *
- * @param \Drupal\Core\Entity\Query\QueryInterface $query
- * Note 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.
- */
-function hook_entity_query_alter(\Drupal\Core\Entity\Query\QueryInterface $query) {
- // @todo: code example.
-}
-
-/**
- * Act on entities being assembled before rendering.
- *
- * @param &$build
- * A renderable array representing the entity content.
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- * @param \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display
- * The entity view display holding the display options configured for the
- * entity components.
- * @param $view_mode
- * The view mode the entity is rendered in.
- * @param $langcode
- * The language code used for rendering.
- *
- * The module may add elements to $build prior to rendering. The
- * structure of $build is a renderable array as expected by
- * drupal_render().
- *
- * @see hook_entity_view_alter()
- * @see hook_ENTITY_TYPE_view()
- *
- * @ingroup entity_crud
- */
-function hook_entity_view(array &$build, \Drupal\Core\Entity\EntityInterface $entity, \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display, $view_mode, $langcode) {
- // Only do the extra work if the component is configured to be displayed.
- // This assumes a 'mymodule_addition' extra field has been defined for the
- // entity bundle in hook_entity_extra_field_info().
- if ($display->getComponent('mymodule_addition')) {
- $build['mymodule_addition'] = array(
- '#markup' => mymodule_addition($entity),
- '#theme' => 'mymodule_my_additional_field',
- );
- }
-}
-
-/**
- * Act on entities of a particular type being assembled before rendering.
- *
- * @param &$build
- * A renderable array representing the entity content.
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object.
- * @param \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display
- * The entity view display holding the display options configured for the
- * entity components.
- * @param $view_mode
- * The view mode the entity is rendered in.
- * @param $langcode
- * The language code used for rendering.
- *
- * The module may add elements to $build prior to rendering. The
- * structure of $build is a renderable array as expected by
- * drupal_render().
- *
- * @see hook_ENTITY_TYPE_view_alter()
- * @see hook_entity_view()
- *
- * @ingroup entity_crud
- */
-function hook_ENTITY_TYPE_view(array &$build, \Drupal\Core\Entity\EntityInterface $entity, \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display, $view_mode, $langcode) {
- // Only do the extra work if the component is configured to be displayed.
- // This assumes a 'mymodule_addition' extra field has been defined for the
- // entity bundle in hook_entity_extra_field_info().
- if ($display->getComponent('mymodule_addition')) {
- $build['mymodule_addition'] = array(
- '#markup' => mymodule_addition($entity),
- '#theme' => 'mymodule_my_additional_field',
- );
- }
-}
-
-/**
- * Alter the results of the entity build array.
- *
- * This hook is called after the content has been assembled in a structured
- * array and may be used for doing processing which requires that the complete
- * entity content structure has been built.
- *
- * If a module wishes to act on the rendered HTML of the entity rather than the
- * structured content array, it may use this hook to add a #post_render
- * callback. Alternatively, it could also implement hook_preprocess_HOOK() for
- * the particular entity type template, if there is one (e.g., node.html.twig).
- * See drupal_render() and _theme() for details.
- *
- * @param array &$build
- * A renderable array representing the entity content.
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object being rendered.
- * @param \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display
- * The entity view display holding the display options configured for the
- * entity components.
- *
- * @see hook_entity_view()
- * @see hook_ENTITY_TYPE_view_alter()
- *
- * @ingroup entity_crud
- */
-function hook_entity_view_alter(array &$build, Drupal\Core\Entity\EntityInterface $entity, \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display) {
- if ($build['#view_mode'] == 'full' && isset($build['an_additional_field'])) {
- // Change its weight.
- $build['an_additional_field']['#weight'] = -10;
-
- // Add a #post_render callback to act on the rendered HTML of the entity.
- $build['#post_render'][] = 'my_module_node_post_render';
- }
-}
-
-/**
- * Alter the results of the entity build array for a particular entity type.
- *
- * This hook is called after the content has been assembled in a structured
- * array and may be used for doing processing which requires that the complete
- * entity content structure has been built.
- *
- * If a module wishes to act on the rendered HTML of the entity rather than the
- * structured content array, it may use this hook to add a #post_render
- * callback. Alternatively, it could also implement hook_preprocess_HOOK() for
- * the particular entity type template, if there is one (e.g., node.html.twig).
- * See drupal_render() and _theme() for details.
- *
- * @param array &$build
- * A renderable array representing the entity content.
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity object being rendered.
- * @param \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display
- * The entity view display holding the display options configured for the
- * entity components.
- *
- * @see hook_ENTITY_TYPE_view()
- * @see hook_entity_view_alter()
- *
- * @ingroup entity_crud
- */
-function hook_ENTITY_TYPE_view_alter(array &$build, Drupal\Core\Entity\EntityInterface $entity, \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display) {
- if ($build['#view_mode'] == 'full' && isset($build['an_additional_field'])) {
- // Change its weight.
- $build['an_additional_field']['#weight'] = -10;
-
- // Add a #post_render callback to act on the rendered HTML of the entity.
- $build['#post_render'][] = 'my_module_node_post_render';
- }
-}
-
-/**
- * Act on entities as they are being prepared for view.
- *
- * Allows you to operate on multiple entities as they are being prepared for
- * view. Only use this if attaching the data during the entity loading phase
- * is not appropriate, for example when attaching other 'entity' style objects.
- *
- * @param string $entity_type_id
- * The type of entities being viewed (i.e. node, user, comment).
- * @param array $entities
- * The entities keyed by entity ID.
- * @param \Drupal\Core\Entity\Display\EntityViewDisplayInterface[] $displays
- * The array of entity view displays holding the display options configured
- * for the entity components, keyed by bundle name.
- * @param string $view_mode
- * The view mode.
- *
- * @ingroup entity_crud
- */
-function hook_entity_prepare_view($entity_type_id, array $entities, array $displays, $view_mode) {
- // Load a specific node into the user object for later theming.
- if (!empty($entities) && $entity_type_id == 'user') {
- // Only do the extra work if the component is configured to be
- // displayed. This assumes a 'mymodule_addition' extra field has been
- // defined for the entity bundle in hook_entity_extra_field_info().
- $ids = array();
- foreach ($entities as $id => $entity) {
- if ($displays[$entity->bundle()]->getComponent('mymodule_addition')) {
- $ids[] = $id;
- }
- }
- if ($ids) {
- $nodes = mymodule_get_user_nodes($ids);
- foreach ($ids as $id) {
- $entities[$id]->user_node = $nodes[$id];
- }
- }
- }
-}
-
-/**
- * Change the view mode of an entity that is being displayed.
- *
- * @param string $view_mode
- * The view_mode that is to be used to display the entity.
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity that is being viewed.
- * @param array $context
- * Array with additional context information, currently only contains the
- * langcode the entity is viewed in.
- *
- * @ingroup entity_crud
- */
-function hook_entity_view_mode_alter(&$view_mode, Drupal\Core\Entity\EntityInterface $entity, $context) {
- // For nodes, change the view mode when it is teaser.
- if ($entity->getEntityTypeId() == 'node' && $view_mode == 'teaser') {
- $view_mode = 'my_custom_view_mode';
- }
-}
-
-/**
- * Alter entity renderable values before cache checking in drupal_render().
- *
- * Invoked for a specific entity type.
- *
- * The values in the #cache key of the renderable array are used to determine if
- * a cache entry exists for the entity's rendered output. Ideally only values
- * that pertain to caching should be altered in this hook.
- *
- * @param array &$build
- * A renderable array containing the entity's caching and view mode values.
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity that is being viewed.
- * @param string $view_mode
- * The view_mode that is to be used to display the entity.
- * @param string $langcode
- * The code of the language $entity is accessed in.
- *
- * @see drupal_render()
- * @see \Drupal\Core\Entity\EntityViewBuilder
- * @see hook_entity_build_defaults_alter()
- *
- * @ingroup entity_crud
- */
-function hook_ENTITY_TYPE_build_defaults_alter(array &$build, \Drupal\Core\Entity\EntityInterface $entity, $view_mode, $langcode) {
-
-}
-
-/**
- * Alter entity renderable values before cache checking in drupal_render().
- *
- * The values in the #cache key of the renderable array are used to determine if
- * a cache entry exists for the entity's rendered output. Ideally only values
- * that pertain to caching should be altered in this hook.
- *
- * @param array &$build
- * A renderable array containing the entity's caching and view mode values.
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity that is being viewed.
- * @param string $view_mode
- * The view_mode that is to be used to display the entity.
- * @param string $langcode
- * The code of the language $entity is accessed in.
- *
- * @see drupal_render()
- * @see \Drupal\Core\Entity\EntityViewBuilder
- * @see hook_ENTITY_TYPE_build_defaults_alter()
- *
- * @ingroup entity_crud
- */
-function hook_entity_build_defaults_alter(array &$build, \Drupal\Core\Entity\EntityInterface $entity, $view_mode, $langcode) {
-
-}
-
-/**
- * Alter the settings used for displaying an entity.
- *
- * @param \Drupal\Core\Entity\Display\EntityViewDisplayInterface $display
- * The entity view display that will be used to display the entity
- * components.
- * @param array $context
- * An associative array containing:
- * - entity_type: The entity type, e.g., 'node' or 'user'.
- * - bundle: The bundle, e.g., 'page' or 'article'.
- * - view_mode: The view mode, e.g. 'full', 'teaser'...
- *
- * @ingroup entity_crud
- */
-function hook_entity_view_display_alter(\Drupal\Core\Entity\Display\EntityViewDisplayInterface $display, array $context) {
- // Leave field labels out of the search index.
- if ($context['entity_type'] == 'node' && $context['view_mode'] == 'search_index') {
- foreach ($display->getComponents() as $name => $options) {
- if (isset($options['label'])) {
- $options['label'] = 'hidden';
- $display->setComponent($name, $options);
- }
- }
- }
-}
-
-/**
- * Alter the render array generated by an EntityDisplay for an entity.
- *
- * @param array $build
- * The renderable array generated by the EntityDisplay.
- * @param array $context
- * An associative array containing:
- * - entity: The entity being rendered.
- * - view_mode: The view mode; for example, 'full' or 'teaser'.
- * - display: The EntityDisplay holding the display options.
- *
- * @ingroup entity_crud
- */
-function hook_entity_display_build_alter(&$build, $context) {
- // Append RDF term mappings on displayed taxonomy links.
- foreach (Element::children($build) as $field_name) {
- $element = &$build[$field_name];
- if ($element['#field_type'] == 'entity_reference' && $element['#formatter'] == 'entity_reference_label') {
- foreach ($element['#items'] as $delta => $item) {
- $term = $item->entity;
- if (!empty($term->rdf_mapping['rdftype'])) {
- $element[$delta]['#options']['attributes']['typeof'] = $term->rdf_mapping['rdftype'];
- }
- if (!empty($term->rdf_mapping['name']['predicates'])) {
- $element[$delta]['#options']['attributes']['property'] = $term->rdf_mapping['name']['predicates'];
- }
- }
- }
- }
-}
-
-/**
- * Acts on an entity object about to be shown on an entity form.
- *
- * This can be typically used to pre-fill entity values or change the form state
- * before the entity form is built. It is invoked just once when first building
- * the entity form. Rebuilds will not trigger a new invocation.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity that is about to be shown on the form.
- * @param $operation
- * The current operation.
- * @param \Drupal\Core\Form\FormStateInterface $form_state
- * The current state of the form.
- *
- * @see \Drupal\Core\Entity\EntityForm::prepareEntity()
- * @see hook_ENTITY_TYPE_prepare_form()
- *
- * @ingroup entity_crud
- */
-function hook_entity_prepare_form(\Drupal\Core\Entity\EntityInterface $entity, $operation, \Drupal\Core\Form\FormStateInterface $form_state) {
- if ($operation == 'edit') {
- $entity->label->value = 'Altered label';
- $form_state->set('label_altered', TRUE);
- }
-}
-
-/**
- * Acts on a particular type of entity object about to be in an entity form.
- *
- * This can be typically used to pre-fill entity values or change the form state
- * before the entity form is built. It is invoked just once when first building
- * the entity form. Rebuilds will not trigger a new invocation.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity that is about to be shown on the form.
- * @param $operation
- * The current operation.
- * @param \Drupal\Core\Form\FormStateInterface $form_state
- * The current state of the form.
- *
- * @see \Drupal\Core\Entity\EntityForm::prepareEntity()
- * @see hook_entity_prepare_form()
- *
- * @ingroup entity_crud
- */
-function hook_ENTITY_TYPE_prepare_form(\Drupal\Core\Entity\EntityInterface $entity, $operation, \Drupal\Core\Form\FormStateInterface $form_state) {
- if ($operation == 'edit') {
- $entity->label->value = 'Altered label';
- $form_state->set('label_altered', TRUE);
- }
-}
-
-/**
- * Alter the settings used for displaying an entity form.
- *
- * @param \Drupal\Core\Entity\Display\EntityFormDisplayInterface $form_display
- * The entity_form_display object that will be used to display the entity form
- * components.
- * @param array $context
- * An associative array containing:
- * - entity_type: The entity type, e.g., 'node' or 'user'.
- * - bundle: The bundle, e.g., 'page' or 'article'.
- * - form_mode: The form mode, e.g. 'default', 'profile', 'register'...
- *
- * @ingroup entity_crud
- */
-function hook_entity_form_display_alter(\Drupal\Core\Entity\Display\EntityFormDisplayInterface $form_display, array $context) {
- // Hide the 'user_picture' field from the register form.
- if ($context['entity_type'] == 'user' && $context['form_mode'] == 'register') {
- $form_display->setComponent('user_picture', array(
- 'type' => 'hidden',
- ));
- }
-}
-
-/**
- * Provides custom base field definitions for a content entity type.
- *
- * @param \Drupal\Core\Entity\EntityTypeInterface $entity_type
- * The entity type definition.
- *
- * @return \Drupal\Core\Field\FieldDefinitionInterface[]
- * An array of field definitions, keyed by field name.
- *
- * @see hook_entity_base_field_info_alter()
- * @see hook_entity_bundle_field_info()
- * @see hook_entity_bundle_field_info_alter()
- * @see \Drupal\Core\Field\FieldDefinitionInterface
- * @see \Drupal\Core\Entity\EntityManagerInterface::getFieldDefinitions()
- */
-function hook_entity_base_field_info(\Drupal\Core\Entity\EntityTypeInterface $entity_type) {
- if ($entity_type->id() == 'node') {
- $fields = array();
- $fields['mymodule_text'] = BaseFieldDefinition::create('string')
- ->setLabel(t('The text'))
- ->setDescription(t('A text property added by mymodule.'))
- ->setComputed(TRUE)
- ->setClass('\Drupal\mymodule\EntityComputedText');
-
- return $fields;
- }
-}
-
-/**
- * Alter base field definitions for a content entity type.
- *
- * @param \Drupal\Core\Field\FieldDefinitionInterface[] $fields
- * The array of base field definitions for the entity type.
- * @param \Drupal\Core\Entity\EntityTypeInterface $entity_type
- * The entity type definition.
- *
- * @see hook_entity_base_field_info()
- * @see hook_entity_bundle_field_info()
- * @see hook_entity_bundle_field_info_alter()
- *
- * @todo WARNING: This hook will be changed in
- * https://www.drupal.org/node/2346329.
- */
-function hook_entity_base_field_info_alter(&$fields, \Drupal\Core\Entity\EntityTypeInterface $entity_type) {
- // Alter the mymodule_text field to use a custom class.
- if ($entity_type->id() == 'node' && !empty($fields['mymodule_text'])) {
- $fields['mymodule_text']->setClass('\Drupal\anothermodule\EntityComputedText');
- }
-}
-
-/**
- * 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.
- *
- * @param \Drupal\Core\Entity\EntityTypeInterface $entity_type
- * The entity type definition.
- * @param string $bundle
- * The bundle.
- * @param \Drupal\Core\Field\FieldDefinitionInterface[] $base_field_definitions
- * The list of base field definitions for the entity type.
- *
- * @return \Drupal\Core\Field\FieldDefinitionInterface[]
- * An array of bundle field definitions, keyed by field name.
- *
- * @see hook_entity_base_field_info()
- * @see hook_entity_base_field_info_alter()
- * @see hook_entity_field_storage_info()
- * @see hook_entity_field_storage_info_alter()
- * @see hook_entity_bundle_field_info_alter()
- * @see \Drupal\Core\Field\FieldDefinitionInterface
- * @see \Drupal\Core\Entity\EntityManagerInterface::getFieldDefinitions()
- *
- * @todo WARNING: This hook will be changed in
- * https://www.drupal.org/node/2346347.
- */
-function hook_entity_bundle_field_info(\Drupal\Core\Entity\EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) {
- // Add a property only to nodes of the 'article' bundle.
- if ($entity_type->id() == 'node' && $bundle == 'article') {
- $fields = array();
- $fields['mymodule_text_more'] = BaseFieldDefinition::create('string')
- ->setLabel(t('More text'))
- ->setComputed(TRUE)
- ->setClass('\Drupal\mymodule\EntityComputedMoreText');
- return $fields;
- }
-}
-
-/**
- * Alter bundle field definitions.
- *
- * @param \Drupal\Core\Field\FieldDefinitionInterface[] $fields
- * The array of bundle field definitions.
- * @param \Drupal\Core\Entity\EntityTypeInterface $entity_type
- * The entity type definition.
- * @param string $bundle
- * The bundle.
- *
- * @see hook_entity_base_field_info()
- * @see hook_entity_base_field_info_alter()
- * @see hook_entity_bundle_field_info()
- *
- * @todo WARNING: This hook will be changed in
- * https://www.drupal.org/node/2346347.
- */
-function hook_entity_bundle_field_info_alter(&$fields, \Drupal\Core\Entity\EntityTypeInterface $entity_type, $bundle) {
- if ($entity_type->id() == 'node' && $bundle == 'article' && !empty($fields['mymodule_text'])) {
- // Alter the mymodule_text field to use a custom class.
- $fields['mymodule_text']->setClass('\Drupal\anothermodule\EntityComputedText');
- }
-}
-
-/**
- * Provides field storage definitions for a content entity type.
- *
- * @param \Drupal\Core\Entity\EntityTypeInterface $entity_type
- * The entity type definition.
- *
- * @return \Drupal\Core\Field\FieldStorageDefinitionInterface[]
- * An array of field storage definitions, keyed by field name.
- *
- * @see hook_entity_field_storage_info_alter()
- * @see \Drupal\Core\Field\FieldStorageDefinitionInterface
- * @see \Drupal\Core\Entity\EntityManagerInterface::getFieldStorageDefinitions()
- */
-function hook_entity_field_storage_info(\Drupal\Core\Entity\EntityTypeInterface $entity_type) {
- if (\Drupal::entityManager()->getStorage($entity_type->id()) instanceof DynamicallyFieldableEntityStorageInterface) {
- // Query by filtering on the ID as this is more efficient than filtering
- // on the entity_type property directly.
- $ids = \Drupal::entityQuery('field_storage_config')
- ->condition('id', $entity_type->id() . '.', 'STARTS_WITH')
- ->execute();
- // Fetch all fields and key them by field name.
- $field_storages = FieldStorageConfig::loadMultiple($ids);
- $result = array();
- foreach ($field_storages as $field_storage) {
- $result[$field_storage->getName()] = $field_storage;
- }
-
- return $result;
- }
-}
-
-/**
- * Alter field storage definitions for a content entity type.
- *
- * @param \Drupal\Core\Field\FieldStorageDefinitionInterface[] $fields
- * The array of field storage definitions for the entity type.
- * @param \Drupal\Core\Entity\EntityTypeInterface $entity_type
- * The entity type definition.
- *
- * @see hook_entity_field_storage_info()
- */
-function hook_entity_field_storage_info_alter(&$fields, \Drupal\Core\Entity\EntityTypeInterface $entity_type) {
- // Alter the max_length setting.
- if ($entity_type->id() == 'node' && !empty($fields['mymodule_text'])) {
- $fields['mymodule_text']->setSetting('max_length', 128);
- }
-}
-
-/**
- * Declares entity operations.
- *
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity on which the linked operations will be performed.
- *
- * @return array
- * An operations array as returned by
- * \Drupal\Core\Entity\EntityListBuilderInterface::getOperations().
- */
-function hook_entity_operation(\Drupal\Core\Entity\EntityInterface $entity) {
- $operations = array();
- $operations['translate'] = array(
- 'title' => t('Translate'),
- 'route_name' => 'foo_module.entity.translate',
- 'weight' => 50,
- );
-
- return $operations;
-}
-
-/**
- * Alter entity operations.
- *
- * @param array $operations
- * Operations array as returned by
- * \Drupal\Core\Entity\EntityListBuilderInterface::getOperations().
- * @param \Drupal\Core\Entity\EntityInterface $entity
- * The entity on which the linked operations will be performed.
- */
-function hook_entity_operation_alter(array &$operations, \Drupal\Core\Entity\EntityInterface $entity) {
- // Alter the title and weight.
- $operations['translate']['title'] = t('Translate @entity_type', array(
- '@entity_type' => $entity->getEntityTypeId(),
- ));
- $operations['translate']['weight'] = 99;
-}
-
-/**
- * Control access to fields.
- *
- * This hook is invoked from
- * \Drupal\Core\Entity\EntityAccessControlHandler::fieldAccess() to let modules
- * grant or deny operations on fields.
- *
- * @param string $operation
- * The operation to be performed. See
- * \Drupal\Core\Access\AccessibleInterface::access() for possible values.
- * @param \Drupal\Core\Field\FieldDefinitionInterface $field_definition
- * The field definition.
- * @param \Drupal\Core\Session\AccountInterface $account
- * The user account to check.
- * @param \Drupal\Core\Field\FieldItemListInterface $items
- * (optional) The entity field object on which the operation is to be
- * performed.
- *
- * @return \Drupal\Core\Access\AccessResultInterface
- * The access result.
- */
-function hook_entity_field_access($operation, \Drupal\Core\Field\FieldDefinitionInterface $field_definition, \Drupal\Core\Session\AccountInterface $account, \Drupal\Core\Field\FieldItemListInterface $items = NULL) {
- if ($field_definition->getName() == 'field_of_interest' && $operation == 'edit') {
- return AccessResult::allowedIfHasPermission($account, 'update field of interest');
- }
- return AccessResult::neutral();
-}
-
-/**
- * Alter the default access behavior for a given field.
- *
- * Use this hook to override access grants from another module. Note that the
- * original default access flag is masked under the ':default' key.
- *
- * @param \Drupal\Core\Access\AccessResultInterface[] $grants
- * An array of grants gathered by hook_entity_field_access(). The array is
- * keyed by the module that defines the field's access control; the values are
- * grant responses for each module (\Drupal\Core\Access\AccessResult).
- * @param array $context
- * Context array on the performed operation with the following keys:
- * - operation: The operation to be performed (string).
- * - field_definition: The field definition object
- * (\Drupal\Core\Field\FieldDefinitionInterface)
- * - account: The user account to check access for
- * (Drupal\user\Entity\User).
- * - items: (optional) The entity field items
- * (\Drupal\Core\Field\FieldItemListInterface).
- */
-function hook_entity_field_access_alter(array &$grants, array $context) {
- /** @var \Drupal\Core\Field\FieldDefinitionInterface $field_definition */
- $field_definition = $context['field_definition'];
- if ($field_definition->getName() == 'field_of_interest' && $grants['node']->isForbidden()) {
- // Override node module's restriction to no opinion (neither allowed nor
- // forbidden). We don't want to provide our own access hook, we only want to
- // take out node module's part in the access handling of this field. We also
- // don't want to switch node module's grant to
- // AccessResultInterface::isAllowed() , because the grants of other modules
- // should still decide on their own if this field is accessible or not
- $grants['node'] = AccessResult::neutral()->inheritCacheability($grants['node']);
- }
-}
-
-/**
- * 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 hook_entity_extra_field_info_alter()
- *
- * @return array
- * The array structure is identical to that of the return value of
- * \Drupal\Core\Entity\EntityManagerInterface::getExtraFields().
- */
-function hook_entity_extra_field_info() {
- $extra = array();
- $module_language_enabled = \Drupal::moduleHandler()->moduleExists('language');
- $description = t('Node module element');
-
- foreach (NodeType::loadMultiple() as $bundle) {
-
- // Add also the 'language' select if Language module is enabled and the
- // bundle has multilingual support.
- // Visibility of the ordering of the language selector is the same as on the
- // node/add form.
- if ($module_language_enabled) {
- $configuration = ContentLanguageSettings::loadByEntityTypeBundle('node', $bundle->type);
- if ($configuration->isLanguageAlterable()) {
- $extra['node'][$bundle->type]['form']['language'] = array(
- 'label' => t('Language'),
- 'description' => $description,
- 'weight' => 0,
- );
- }
- }
- $extra['node'][$bundle->type]['display']['language'] = array(
- 'label' => t('Language'),
- 'description' => $description,
- 'weight' => 0,
- 'visible' => FALSE,
- );
- }
-
- return $extra;
-}
-
-/**
- * Alter "pseudo-field" components on content entities.
- *
- * @param array $info
- * The array structure is identical to that of the return value of
- * \Drupal\Core\Entity\EntityManagerInterface::getExtraFields().
- *
- * @see hook_entity_extra_field_info()
- */
-function hook_entity_extra_field_info_alter(&$info) {
- // Force node title to always be at the top of the list by default.
- foreach (NodeType::loadMultiple() as $bundle) {
- if (isset($info['node'][$bundle->type]['form']['title'])) {
- $info['node'][$bundle->type]['form']['title']['weight'] = -20;
- }
- }
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
diff --git a/core/modules/system/file.api.php b/core/modules/system/file.api.php
deleted file mode 100644
index a4fd8e4..0000000
--- a/core/modules/system/file.api.php
+++ /dev/null
@@ -1,201 +0,0 @@
- 'attachment; filename="config.tar.gz"',
- );
- }
-}
-
-/**
- * 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.
- *
- * @param $uri
- * The URI to a file for which we need an external URL, or the path to a
- * shipped file.
- */
-function hook_file_url_alter(&$uri) {
- $user = \Drupal::currentUser();
-
- // User 1 will always see the local file in this example.
- if ($user->id() == 1) {
- return;
- }
-
- $cdn1 = 'http://cdn1.example.com';
- $cdn2 = 'http://cdn2.example.com';
- $cdn_extensions = array('css', 'js', 'gif', 'jpg', 'jpeg', 'png');
-
- // Most CDNs don't support private file transfers without a lot of hassle,
- // so don't support this in the common case.
- $schemes = array('public');
-
- $scheme = file_uri_scheme($uri);
-
- // Only serve shipped files and public created files from the CDN.
- if (!$scheme || in_array($scheme, $schemes)) {
- // Shipped files.
- if (!$scheme) {
- $path = $uri;
- }
- // Public created files.
- else {
- $wrapper = file_stream_wrapper_get_instance_by_scheme($scheme);
- $path = $wrapper->getDirectoryPath() . '/' . file_uri_target($uri);
- }
-
- // Clean up Windows paths.
- $path = str_replace('\\', '/', $path);
-
- // Serve files with one of the CDN extensions from CDN 1, all others from
- // CDN 2.
- $pathinfo = pathinfo($path);
- if (isset($pathinfo['extension']) && in_array($pathinfo['extension'], $cdn_extensions)) {
- $uri = $cdn1 . '/' . $path;
- }
- else {
- $uri = $cdn2 . '/' . $path;
- }
- }
-}
-
-/**
- * Alter MIME type mappings used to determine MIME type from a file extension.
- *
- * Invoked by \Drupal\Core\File\MimeType\ExtensionMimeTypeGuesser::guess(). It
- * is used to allow modules to add to or modify the default mapping from
- * \Drupal\Core\File\MimeType\ExtensionMimeTypeGuesser::$defaultMapping.
- *
- * @param $mapping
- * An 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 \Drupal\Core\File\MimeType\ExtensionMimeTypeGuesser::guess()
- * @see \Drupal\Core\File\MimeType\ExtensionMimeTypeGuesser::$defaultMapping
- */
-function hook_file_mimetype_mapping_alter(&$mapping) {
- // Add new MIME type 'drupal/info'.
- $mapping['mimetypes']['example_info'] = 'drupal/info';
- // Add new extension '.info.yml' and map it to the 'drupal/info' MIME type.
- $mapping['extensions']['info'] = 'example_info';
- // Override existing extension mapping for '.ogg' files.
- $mapping['extensions']['ogg'] = 189;
-}
-
-/**
- * Alter archiver information declared by other modules.
- *
- * See hook_archiver_info() for a description of archivers and the archiver
- * information structure.
- *
- * @param $info
- * Archiver information to alter (return values from hook_archiver_info()).
- */
-function hook_archiver_info_alter(&$info) {
- $info['tar']['extensions'][] = 'tgz';
-}
-
-/**
- * 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.
- *
- * @return 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 \Drupal\Core\FileTransfer\FileTransfer
- * @see authorize.php
- * @see hook_filetransfer_info_alter()
- * @see drupal_get_filetransfer_info()
- */
-function hook_filetransfer_info() {
- $info['sftp'] = array(
- 'title' => t('SFTP (Secure FTP)'),
- 'class' => 'Drupal\Core\FileTransfer\SFTP',
- 'weight' => 10,
- );
- return $info;
-}
-
-/**
- * Alter the FileTransfer class registry.
- *
- * @param array $filetransfer_info
- * Reference to a nested array containing information about the FileTransfer
- * class registry.
- *
- * @see hook_filetransfer_info()
- */
-function hook_filetransfer_info_alter(&$filetransfer_info) {
- // Remove the FTP option entirely.
- unset($filetransfer_info['ftp']);
- // Make sure the SSH option is listed first.
- $filetransfer_info['ssh']['weight'] = -10;
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
diff --git a/core/modules/system/form.api.php b/core/modules/system/form.api.php
deleted file mode 100644
index 9173231..0000000
--- a/core/modules/system/form.api.php
+++ /dev/null
@@ -1,316 +0,0 @@
-container->get('entity.manager')->getStorage('node');
-
- if (!isset($context['sandbox']['progress'])) {
- $context['sandbox']['progress'] = 0;
- $context['sandbox']['current_node'] = 0;
- $context['sandbox']['max'] = db_query('SELECT COUNT(DISTINCT nid) FROM {node}')->fetchField();
- }
-
- // For this example, we decide that we can safely process
- // 5 nodes at a time without a timeout.
- $limit = 5;
-
- // With each pass through the callback, retrieve the next group of nids.
- $result = db_query_range("SELECT nid FROM {node} WHERE nid > %d ORDER BY nid ASC", $context['sandbox']['current_node'], 0, $limit);
- while ($row = db_fetch_array($result)) {
-
- // Here we actually perform our processing on the current node.
- $node_storage->resetCache(array($row['nid']));
- $node = $node_storage->load($row['nid']);
- $node->value1 = $options1;
- $node->value2 = $options2;
- node_save($node);
-
- // Store some result for post-processing in the finished callback.
- $context['results'][] = SafeMarkup::checkPlain($node->title);
-
- // Update our progress information.
- $context['sandbox']['progress']++;
- $context['sandbox']['current_node'] = $node->nid;
- $context['message'] = t('Now processing %node', array('%node' => $node->title));
- }
-
- // Inform the batch engine that we are not finished,
- // and provide an estimation of the completion level we reached.
- if ($context['sandbox']['progress'] != $context['sandbox']['max']) {
- $context['finished'] = $context['sandbox']['progress'] / $context['sandbox']['max'];
- }
-}
-
-/**
- * Complete a batch process.
- *
- * Callback for batch_set().
- *
- * This callback may be specified in a batch to perform clean-up operations, or
- * to analyze the results of the batch operations.
- *
- * @param $success
- * A boolean indicating whether the batch has completed successfully.
- * @param $results
- * The value set in $context['results'] by callback_batch_operation().
- * @param $operations
- * If $success is FALSE, contains the operations that remained unprocessed.
- */
-function callback_batch_finished($success, $results, $operations) {
- if ($success) {
- // Here we do something meaningful with the results.
- $message = t("!count items were processed.", array(
- '!count' => count($results),
- ));
- $list = array(
- '#theme' => 'item_list',
- '#items' => $results,
- );
- $message .= drupal_render($list);
- drupal_set_message($message);
- }
- else {
- // An error occurred.
- // $operations contains the operations that remained unprocessed.
- $error_operation = reset($operations);
- $message = t('An error occurred while processing %error_operation with arguments: @arguments', array(
- '%error_operation' => $error_operation[0],
- '@arguments' => print_r($error_operation[1], TRUE)
- ));
- drupal_set_message($message, 'error');
- }
-}
-
-/**
- * @} End of "addtogroup callbacks".
- */
-
-/**
- * @addtogroup hooks
- * @{
- */
-
-/**
- * Alter the Ajax command data that is sent to the client.
- *
- * @param \Drupal\Core\Ajax\CommandInterface[] $data
- * An array of all the rendered commands that will be sent to the client.
- *
- * @see \Drupal\Core\Ajax\AjaxResponse::ajaxRender()
- */
-function hook_ajax_render_alter(array &$data) {
- // Inject any new status messages into the content area.
- $status_messages = array('#type' => 'status_messages');
- $command = new \Drupal\Core\Ajax\PrependCommand('#block-system-main .content', \Drupal::service('renderer')->renderRoot($status_messages));
- $data[] = $command->render();
-}
-
-/**
- * Perform alterations before a form is rendered.
- *
- * One popular use of this hook is to add form elements to the node form. When
- * altering a node form, the node entity can be retrieved by invoking
- * $form_state->getFormObject()->getEntity().
- *
- * In addition to hook_form_alter(), which is called for all forms, there are
- * two more specific form hooks available. The first,
- * hook_form_BASE_FORM_ID_alter(), allows targeting of a form/forms via a base
- * form (if one exists). The second, hook_form_FORM_ID_alter(), can be used to
- * target a specific form directly.
- *
- * The call order is as follows: all existing form alter functions are called
- * for module A, then all for module B, etc., followed by all for any base
- * theme(s), and finally for the theme itself. The module order is determined
- * by system weight, then by module name.
- *
- * Within each module, form alter hooks are called in the following order:
- * first, hook_form_alter(); second, hook_form_BASE_FORM_ID_alter(); third,
- * hook_form_FORM_ID_alter(). So, for each module, the more general hooks are
- * called first followed by the more specific.
- *
- * @param $form
- * Nested array of form elements that comprise the form.
- * @param $form_state
- * The current state of the form. The arguments that
- * \Drupal::formBuilder()->getForm() was originally called with are available
- * in the array $form_state->getBuildInfo()['args'].
- * @param $form_id
- * String representing the name of the form itself. Typically this is the
- * name of the function that generated the form.
- *
- * @see hook_form_BASE_FORM_ID_alter()
- * @see hook_form_FORM_ID_alter()
- * @see forms_api_reference.html
- */
-function hook_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
- if (isset($form['type']) && $form['type']['#value'] . '_node_settings' == $form_id) {
- $upload_enabled_types = \Drupal::config('mymodule.settings')->get('upload_enabled_types');
- $form['workflow']['upload_' . $form['type']['#value']] = array(
- '#type' => 'radios',
- '#title' => t('Attachments'),
- '#default_value' => in_array($form['type']['#value'], $upload_enabled_types) ? 1 : 0,
- '#options' => array(t('Disabled'), t('Enabled')),
- );
- // Add a custom submit handler to save the array of types back to the config file.
- $form['actions']['submit']['#submit'][] = 'mymodule_upload_enabled_types_submit';
- }
-}
-
-/**
- * Provide a form-specific alteration instead of the global hook_form_alter().
- *
- * Modules can implement hook_form_FORM_ID_alter() to modify a specific form,
- * rather than implementing hook_form_alter() and checking the form ID, or
- * using long switch statements to alter multiple forms.
- *
- * Form alter hooks are called in the following order: hook_form_alter(),
- * hook_form_BASE_FORM_ID_alter(), hook_form_FORM_ID_alter(). See
- * hook_form_alter() for more details.
- *
- * @param $form
- * Nested array of form elements that comprise the form.
- * @param $form_state
- * The current state of the form. The arguments that
- * \Drupal::formBuilder()->getForm() was originally called with are available
- * in the array $form_state->getBuildInfo()['args'].
- * @param $form_id
- * String representing the name of the form itself. Typically this is the
- * name of the function that generated the form.
- *
- * @see hook_form_alter()
- * @see hook_form_BASE_FORM_ID_alter()
- * @see \Drupal\Core\Form\FormBuilderInterface::prepareForm()
- * @see forms_api_reference.html
- */
-function hook_form_FORM_ID_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
- // Modification for the form with the given form ID goes here. For example, if
- // FORM_ID is "user_register_form" this code would run only on the user
- // registration form.
-
- // Add a checkbox to registration form about agreeing to terms of use.
- $form['terms_of_use'] = array(
- '#type' => 'checkbox',
- '#title' => t("I agree with the website's terms and conditions."),
- '#required' => TRUE,
- );
-}
-
-/**
- * Provide a form-specific alteration for shared ('base') forms.
- *
- * By default, when \Drupal::formBuilder()->getForm() is called, Drupal looks
- * for a function with the same name as the form ID, and uses that function to
- * build the form. In contrast, base forms allow multiple form IDs to be mapped
- * to a single base (also called 'factory') form function.
- *
- * Modules can implement hook_form_BASE_FORM_ID_alter() to modify a specific
- * base form, rather than implementing hook_form_alter() and checking for
- * conditions that would identify the shared form constructor.
- *
- * To identify the base form ID for a particular form (or to determine whether
- * one exists) check the $form_state. The base form ID is stored under
- * $form_state->getBuildInfo()['base_form_id'].
- *
- * Form alter hooks are called in the following order: hook_form_alter(),
- * hook_form_BASE_FORM_ID_alter(), hook_form_FORM_ID_alter(). See
- * hook_form_alter() for more details.
- *
- * @param $form
- * Nested array of form elements that comprise the form.
- * @param $form_state
- * The current state of the form.
- * @param $form_id
- * String representing the name of the form itself. Typically this is the
- * name of the function that generated the form.
- *
- * @see hook_form_alter()
- * @see hook_form_FORM_ID_alter()
- * @see \Drupal\Core\Form\FormBuilderInterface::prepareForm()
- */
-function hook_form_BASE_FORM_ID_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
- // Modification for the form with the given BASE_FORM_ID goes here. For
- // example, if BASE_FORM_ID is "node_form", this code would run on every
- // node form, regardless of node type.
-
- // Add a checkbox to the node form about agreeing to terms of use.
- $form['terms_of_use'] = array(
- '#type' => 'checkbox',
- '#title' => t("I agree with the website's terms and conditions."),
- '#required' => TRUE,
- );
-}
-
-/**
- * Alter batch information before a batch is processed.
- *
- * Called by batch_process() to allow modules to alter a batch before it is
- * processed.
- *
- * @param $batch
- * The associative array of batch information. See batch_set() for details on
- * what this could contain.
- *
- * @see batch_set()
- * @see batch_process()
- *
- * @ingroup batch
- */
-function hook_batch_alter(&$batch) {
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
diff --git a/core/modules/system/language.api.php b/core/modules/system/language.api.php
deleted file mode 100644
index 107512a..0000000
--- a/core/modules/system/language.api.php
+++ /dev/null
@@ -1,260 +0,0 @@
- 'Long month name');
- * format_plural($count, '1 something', '@count somethings',
- * array(), array('context' => 'My context'));
- *
- * // JavaScript code
- * Drupal.t('May', {}, {'context': 'Long month name'});
- * Drupal.formatPlural(count, '1 something', '@count somethings', {},
- * {'context': 'My context'});
- *
- * // *.links.yml file
- * title: 'May'
- * title_context: 'Long month name'
- *
- * // *.routing.yml file
- * my.route.name:
- * pattern: '/something'
- * defaults:
- * _title: 'May'
- * _title_context: 'Long month name'
- *
- * // Config schema to say that a certain piece of configuration should be
- * // translatable using the Config Translation API. Note that the schema label
- * // is also translatable, but it cannot have context.
- * date_format:
- * type: string
- * label: 'PHP date format'
- * translatable: true
- * translation context: 'PHP date format'
- *
- * // Twig template
- * {% trans with {'context': 'Long month name'} %}
- * May
- * {% endtrans %}
- *
- *
- * @see transliteration
- * @see t()
- * @see format_plural()
- * @}
- */
-
-/**
- * @addtogroup hooks
- * @{
- */
-
-/**
- * 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 _l(), which will just handle the
- * path aliases.
- *
- * @param $links
- * Nested array of links keyed by language code.
- * @param $type
- * The language type the links will switch.
- * @param $path
- * The current path.
- */
-function hook_language_switch_links_alter(array &$links, $type, $path) {
- $language_interface = \Drupal::languageManager()->getCurrentLanguage();
-
- if ($type == LanguageInterface::TYPE_CONTENT && isset($links[$language_interface->getId()])) {
- foreach ($links[$language_interface->getId()] as $link) {
- $link['attributes']['class'][] = 'active-language';
- }
- }
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
-
-/**
- * @defgroup transliteration Transliteration
- * @{
- * Transliterate from Unicode to US-ASCII
- *
- * Transliteration is the process of translating individual non-US-ASCII
- * characters into ASCII characters, which specifically does not transform
- * non-printable and punctuation characters in any way. This process will always
- * be both inexact and language-dependent. For instance, the character Ö (O with
- * an umlaut) is commonly transliterated as O, but in German text, the
- * convention would be to transliterate it as Oe or OE, depending on the context
- * (beginning of a capitalized word, or in an all-capital letter context).
- *
- * The Drupal default transliteration process transliterates text character by
- * character using a database of generic character transliterations and
- * language-specific overrides. Character context (such as all-capitals
- * vs. initial capital letter only) is not taken into account, and in
- * transliterations of capital letters that result in two or more letters, by
- * convention only the first is capitalized in the Drupal transliteration
- * result. Also, only Unicode characters of 4 bytes or less can be
- * transliterated in the base system; language-specific overrides can be made
- * for longer Unicode characters. So, the process has limitations; however,
- * since the reason for transliteration is typically to create machine names or
- * file names, this should not really be a problem. After transliteration,
- * other transformation or validation may be necessary, such as converting
- * spaces to another character, removing non-printable characters,
- * lower-casing, etc.
- *
- * Here is a code snippet to transliterate some text:
- * @code
- * // Use the current default interface language.
- * $langcode = \Drupal::languageManager()->getCurrentLanguage()->getId();
- * // Instantiate the transliteration class.
- * $trans = \Drupal::transliteration();
- * // Use this to transliterate some text.
- * $transformed = $trans->transliterate($string, $langcode);
- * @endcode
- *
- * Drupal Core provides the generic transliteration character tables and
- * overrides for a few common languages; modules can implement
- * hook_transliteration_overrides_alter() to provide further language-specific
- * overrides (including providing transliteration for Unicode characters that
- * are longer than 4 bytes). Modules can also completely override the
- * transliteration classes in \Drupal\Core\CoreServiceProvider.
- */
-
-/**
- * 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.
- *
- * @param array $overrides
- * Associative 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.
- * @param string $langcode
- * The code for the language that is being transliterated.
- *
- * @ingroup hooks
- */
-function hook_transliteration_overrides_alter(&$overrides, $langcode) {
- // Provide special overrides for German for a custom site.
- if ($langcode == 'de') {
- // The core-provided transliteration of Ä is Ae, but we want just A.
- $overrides[0xC4] = 'A';
- }
-}
-
-/**
- * @} End of "defgroup transliteration".
- */
diff --git a/core/modules/system/menu.api.php b/core/modules/system/menu.api.php
deleted file mode 100644
index 95be071..0000000
--- a/core/modules/system/menu.api.php
+++ /dev/null
@@ -1,603 +0,0 @@
- array(
- * 'block' => array(
- * 'route_parameters' => array('block' => $entity->id()),
- * ),
- * ),
- * @endcode
- * In this array, the outer key 'block' defines a "group" for contextual
- * links, and the inner array provides values for the route's placeholder
- * parameters (see @ref sec_placeholders above).
- *
- * To declare that a defined route should be a contextual link for a
- * contextual links group, put lines like the following in a
- * module_name.links.contextual.yml file (in the top-level directory for your
- * module):
- * @code
- * block_configure:
- * title: 'Configure block'
- * route_name: 'entity.block.edit_form'
- * group: 'block'
- * @endcode
- * Some notes:
- * - The first line is the machine name for your contextual link, which usually
- * matches the machine name of the route (given in the 'route_name' line).
- * - group: This needs to match the link group defined in the render array.
- *
- * Contextual links from other modules can be altered using
- * hook_contextual_links_alter().
- *
- * @todo Derivatives are in flux for these; when they are more stable, add
- * documentation here.
- *
- * @section sec_rendering Rendering menus
- * Once you have created menus (that contain menu links), you want to render
- * them. Drupal provides a block (Drupal\system\Plugin\Block\SystemMenuBlock) to
- * do so.
- *
- * However, perhaps you have more advanced needs and you're not satisfied with
- * what the menu blocks offer you. If that's the case, you'll want to:
- * - Instantiate \Drupal\Core\Menu\MenuTreeParameters, and set its values to
- * match your needs. Alternatively, you can use
- * MenuLinkTree::getCurrentRouteMenuTreeParameters() to get a typical
- * default set of parameters, and then customize them to suit your needs.
- * - Call \Drupal\Core\MenuLinkTree::load() with your menu link tree parameters,
- * this will return a menu link tree.
- * - Pass the menu tree to \Drupal\Core\Menu\MenuLinkTree::transform() to apply
- * menu link tree manipulators that transform the tree. You will almost always
- * want to apply access checking. The manipulators that you will typically
- * need can be found in \Drupal\Core\Menu\DefaultMenuTreeManipulators.
- * - Potentially write a custom menu tree manipulator, see
- * \Drupal\Core\Menu\DefaultMenuTreeManipulators for examples. This is only
- * necessary if you want to do things like adding extra metadata to rendered
- * links to display icons next to them.
- * - Pass the menu tree to \Drupal\Core\Menu\MenuLinkTree::build(), this will
- * build a renderable array.
- *
- * Combined, that would look like this:
- * @code
- * $menu_tree = \Drupal::menuTree();
- * $menu_name = 'my_menu';
- *
- * // Build the typical default set of menu tree parameters.
- * $parameters = $menu_tree->getCurrentRouteMenuTreeParameters($menu_name);
- *
- * // Load the tree based on this set of parameters.
- * $tree = $menu_tree->load($menu_name, $parameters);
- *
- * // Transform the tree using the manipulators you want.
- * $manipulators = array(
- * // Only show links that are accessible for the current user.
- * array('callable' => 'menu.default_tree_manipulators:checkAccess'),
- * // Use the default sorting of menu links.
- * array('callable' => 'menu.default_tree_manipulators:generateIndexAndSort'),
- * );
- * $tree = $menu_tree->transform($tree, $manipulators);
- *
- * // Finally, build a renderable array from the transformed tree.
- * $menu = $menu_tree->build($tree);
- *
- * $menu_html = drupal_render($menu);
- * @endcode
- *
- * @}
- */
-
-/**
- * @addtogroup hooks
- * @{
- */
-
-/**
- * Alters all the menu links discovered by the menu link plugin manager.
- *
- * @param array $links
- * The link definitions to be altered.
- *
- * @return array
- * An array of discovered menu links. Each link has a key that is the machine
- * name, which must be unique. By default, use the route name as the
- * machine name. In cases where multiple links use the same route name, such
- * as two links to the same page in different menus, or two links using the
- * same route name but different route parameters, the suggested machine name
- * patten is the route name followed by a dot and a unique suffix. For
- * example, an additional logout link might have a machine name of
- * user.logout.navigation, and default links provided to edit the article and
- * page content types could use machine names
- * entity.node_type.edit_form.article and entity.node_type.edit_form.page.
- * Since the machine name may be arbitrary, you should never write code that
- * assumes it is identical to the route name.
- *
- * The value corresponding to each machine name key is an associative array
- * that may contain the following key-value pairs:
- * - title: (required) The untranslated title of the menu link.
- * - description: The untranslated description of the link.
- * - route_name: (optional) The route name to be used to build the path.
- * Either a route_name or a url must be provided.
- * - route_parameters: (optional) The route parameters to build the path.
- * - url: (optional) If you have an external link use url instead
- * of providing a route_name.
- * - parent: (optional) The machine name of the link that is this link's menu
- * parent.
- * - weight: (optional) An integer that determines the relative position of
- * items in the menu; higher-weighted items sink. Defaults to 0. Menu items
- * with the same weight are ordered alphabetically.
- * - menu_name: (optional) The machine name of a menu to put the link in, if
- * not the default Tools menu.
- * - expanded: (optional) If set to TRUE, and if a menu link is provided for
- * this menu item (as a result of other properties), then the menu link is
- * always expanded, equivalent to its 'always expanded' checkbox being set
- * in the UI.
- * - options: (optional) An array of options to be passed to _l() when
- * generating a link from this menu item.
- *
- * @ingroup menu
- */
-function hook_menu_links_discovered_alter(&$links) {
- // Change the weight and title of the user.logout link.
- $links['user.logout']['weight'] = -10;
- $links['user.logout']['title'] = 'Logout';
-}
-
-/**
- * Alter tabs and actions displayed on the page before they are rendered.
- *
- * This hook is invoked by menu_local_tasks(). The system-determined tabs and
- * actions are passed in by reference. Additional tabs or actions may be added.
- *
- * Each tab or action is an associative array containing:
- * - #theme: The theme function to use to render.
- * - #link: An associative array containing:
- * - title: The localized title of the link.
- * - href: The system path to link to.
- * - localized_options: An array of options to pass to _l().
- * - #weight: The link's weight compared to other links.
- * - #active: Whether the link should be marked as 'active'.
- *
- * @param array $data
- * An associative array containing:
- * - actions: A list of of actions keyed by their href, each one being an
- * associative array as described above.
- * - tabs: A list of (up to 2) tab levels that contain a list of of tabs keyed
- * by their href, each one being an associative array as described above.
- * @param string $route_name
- * The route name of the page.
- *
- * @ingroup menu
- */
-function hook_menu_local_tasks(&$data, $route_name) {
- // Add an action linking to node/add to all pages.
- $data['actions']['node/add'] = array(
- '#theme' => 'menu_local_action',
- '#link' => array(
- 'title' => t('Add content'),
- 'url' => Url::fromRoute('node.add_page'),
- 'localized_options' => array(
- 'attributes' => array(
- 'title' => t('Add content'),
- ),
- ),
- ),
- );
-
- // Add a tab linking to node/add to all pages.
- $data['tabs'][0]['node/add'] = array(
- '#theme' => 'menu_local_task',
- '#link' => array(
- 'title' => t('Example tab'),
- 'url' => Url::fromRoute('node.add_page'),
- 'localized_options' => array(
- 'attributes' => array(
- 'title' => t('Add content'),
- ),
- ),
- ),
- );
-}
-
-/**
- * Alter tabs and actions displayed on the page before they are rendered.
- *
- * This hook is invoked by menu_local_tasks(). The system-determined tabs and
- * actions are passed in by reference. Existing tabs or actions may be altered.
- *
- * @param array $data
- * An associative array containing tabs and actions. See
- * hook_menu_local_tasks() for details.
- * @param string $route_name
- * The route name of the page.
- *
- * @see hook_menu_local_tasks()
- *
- * @ingroup menu
- */
-function hook_menu_local_tasks_alter(&$data, $route_name) {
-}
-
-/**
- * Alter local actions plugins.
- *
- * @param array $local_actions
- * The array of local action plugin definitions, keyed by plugin ID.
- *
- * @see \Drupal\Core\Menu\LocalActionInterface
- * @see \Drupal\Core\Menu\LocalActionManager
- *
- * @ingroup menu
- */
-function hook_menu_local_actions_alter(&$local_actions) {
-}
-
-/**
- * Alter local tasks plugins.
- *
- * @param array $local_tasks
- * The array of local tasks plugin definitions, keyed by plugin ID.
- *
- * @see \Drupal\Core\Menu\LocalTaskInterface
- * @see \Drupal\Core\Menu\LocalTaskManager
- *
- * @ingroup menu
- */
-function hook_local_tasks_alter(&$local_tasks) {
- // Remove a specified local task plugin.
- unset($local_tasks['example_plugin_id']);
-}
-
-/**
- * Alter contextual links before they are rendered.
- *
- * This hook is invoked by
- * \Drupal\Core\Menu\ContextualLinkManager::getContextualLinkPluginsByGroup().
- * The system-determined contextual links are passed in by reference. Additional
- * links may be added and existing links can be altered.
- *
- * Each contextual link contains the following entries:
- * - title: The localized title of the link.
- * - route_name: The route name of the link.
- * - route_parameters: The route parameters of the link.
- * - localized_options: An array of URL options.
- * - (optional) weight: The weight of the link, which is used to sort the links.
- *
- *
- * @param array $links
- * An associative array containing contextual links for the given $group,
- * as described above. The array keys are used to build CSS class names for
- * contextual links and must therefore be unique for each set of contextual
- * links.
- * @param string $group
- * The group of contextual links being rendered.
- * @param array $route_parameters.
- * The route parameters passed to each route_name of the contextual links.
- * For example:
- * @code
- * array('node' => $node->id())
- * @endcode
- *
- * @see \Drupal\Core\Menu\ContextualLinkManager
- *
- * @ingroup menu
- */
-function hook_contextual_links_alter(array &$links, $group, array $route_parameters) {
- if ($group == 'menu') {
- // Dynamically use the menu name for the title of the menu_edit contextual
- // link.
- $menu = \Drupal::entityManager()->getStorage('menu')->load($route_parameters['menu']);
- $links['menu_edit']['title'] = t('Edit menu: !label', array('!label' => $menu->label()));
- }
-}
-
-/**
- * Alter the plugin definition of contextual links.
- *
- * @param array $contextual_links
- * An array of contextual_links plugin definitions, keyed by contextual link
- * ID. Each entry contains the following keys:
- * - title: The displayed title of the link
- * - route_name: The route_name of the contextual link to be displayed
- * - group: The group under which the contextual links should be added to.
- * Possible values are e.g. 'node' or 'menu'.
- *
- * @see \Drupal\Core\Menu\ContextualLinkManager
- *
- * @ingroup menu
- */
-function hook_contextual_links_plugins_alter(array &$contextual_links) {
- $contextual_links['menu_edit']['title'] = 'Edit the menu';
-}
-
-/**
- * Perform alterations to the breadcrumb built by the BreadcrumbManager.
- *
- * @param array $breadcrumb
- * An array of breadcrumb link a tags, returned by the breadcrumb manager
- * build method, for example
- * @code
- * array('Home');
- * @endcode
- * @param \Drupal\Core\Routing\RouteMatchInterface $route_match
- * The current route match.
- * @param array $context
- * May include the following key:
- * - builder: the instance of
- * \Drupal\Core\Breadcrumb\BreadcrumbBuilderInterface that constructed this
- * breadcrumb, or NULL if no builder acted based on the current attributes.
- *
- * @ingroup menu
- */
-function hook_system_breadcrumb_alter(array &$breadcrumb, \Drupal\Core\Routing\RouteMatchInterface $route_match, array $context) {
- // Add an item to the end of the breadcrumb.
- $breadcrumb[] = Drupal::l(t('Text'), 'example_route_name');
-}
-
-/**
- * Alter the parameters for links.
- *
- * @param array $variables
- * An associative array of variables defining a link. The link may be either a
- * "route link" using \Drupal\Core\Utility\LinkGenerator::link(), which is
- * exposed as the 'link_generator' service or a link generated by _l(). 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 as a translated string.
- * - url_is_active: Whether or not the link points to the currently active
- * URL.
- * - url: The \Drupal\Core\Url object.
- * - options: An associative array of additional options that will be passed
- * to either \Drupal\Core\Routing\UrlGenerator::generateFromPath() or
- * \Drupal\Core\Routing\UrlGenerator::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\Core\Template\Attribute($options['attributes']).
- * - html: Whether or not HTML should be allowed as the link text. If FALSE,
- * the text will be run through
- * \Drupal\Component\Utility\SafeMarkup::checkPlain() before being output.
- *
- * @see \Drupal\Core\Routing\UrlGenerator::generateFromPath()
- * @see \Drupal\Core\Routing\UrlGenerator::generateFromRoute()
- */
-function hook_link_alter(&$variables) {
- // Add a warning to the end of route links to the admin section.
- if (isset($variables['route_name']) && strpos($variables['route_name'], 'admin') !== FALSE) {
- $variables['text'] .= ' (Warning!)';
- }
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
diff --git a/core/modules/system/module.api.php b/core/modules/system/module.api.php
deleted file mode 100644
index 9d5005e..0000000
--- a/core/modules/system/module.api.php
+++ /dev/null
@@ -1,783 +0,0 @@
- 'tokens',
- );
- $hooks['tokens'] = array(
- 'group' => 'tokens',
- );
- return $hooks;
-}
-
-/**
- * Alter the registry of modules implementing a hook.
- *
- * This hook is invoked during \Drupal::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 \Drupal::moduleHandler->alter() can have
- * multiple variations(such as hook_form_alter() and hook_form_FORM_ID_alter()).
- * \Drupal::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().
- *
- * @param $implementations
- * An 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.
- * @param $hook
- * The name of the module hook being implemented.
- */
-function hook_module_implements_alter(&$implementations, $hook) {
- if ($hook == 'form_alter') {
- // Move my_module_form_alter() to the end of the list.
- // \Drupal::moduleHandler()->getImplementations()
- // iterates through $implementations with a foreach loop which PHP iterates
- // in the order that the items were added, so to move an item to the end of
- // the array, we remove it and then add it.
- $group = $implementations['my_module'];
- unset($implementations['my_module']);
- $implementations['my_module'] = $group;
- }
-}
-
-/**
- * Alter the information parsed from module and theme .info.yml files
- *
- * This hook is invoked in _system_rebuild_module_data() and in
- * \Drupal\Core\Extension\ThemeHandlerInterface::rebuildThemeData(). A module
- * may implement this hook in order to add to or alter the data generated by
- * reading the .info.yml file with \Drupal\Core\Extension\InfoParser.
- *
- * @param array $info
- * The .info.yml file contents, passed by reference so that it can be altered.
- * @param \Drupal\Core\Extension\Extension $file
- * Full information about the module or theme.
- * @param string $type
- * Either 'module' or 'theme', depending on the type of .info.yml file that
- * was passed.
- */
-function hook_system_info_alter(array &$info, \Drupal\Core\Extension\Extension $file, $type) {
- // Only fill this in if the .info.yml file does not define a 'datestamp'.
- if (empty($info['datestamp'])) {
- $info['datestamp'] = $file->getMTime();
- }
-}
-
-/**
- * Perform necessary actions before a module is installed.
- *
- * @param string $module
- * The name of the module about to be installed.
- */
-function hook_module_preinstall($module) {
- mymodule_cache_clear();
-}
-
-/**
- * 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
- * \Drupal\Core\Extension\ModuleHandler::install() for a detailed description of
- * the order in which install hooks are invoked.
- *
- * @param $modules
- * An array of the modules that were installed.
- *
- * @see \Drupal\Core\Extension\ModuleHandler::install()
- * @see hook_install()
- */
-function hook_modules_installed($modules) {
- if (in_array('lousy_module', $modules)) {
- \Drupal::state()->set('mymodule.lousy_module_compatibility', TRUE);
- }
-}
-
-/**
- * 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 @link http://drupal.org/node/146843 Schema API documentation @endlink
- * 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 hook_schema()
- * @see \Drupal\Core\Extension\ModuleHandler::install()
- * @see hook_uninstall()
- * @see hook_modules_installed()
- */
-function hook_install() {
- // Create the styles directory and ensure it's writable.
- $directory = file_default_scheme() . '://styles';
- $mode = isset($GLOBALS['install_state']['mode']) ? $GLOBALS['install_state']['mode'] : NULL;
- file_prepare_directory($directory, FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS, $mode);
-}
-
-/**
- * Perform necessary actions before a module is uninstalled.
- *
- * @param string $module
- * The name of the module about to be uninstalled.
- */
-function hook_module_preuninstall($module) {
- mymodule_cache_clear();
-}
-
-/**
- * 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.
- *
- * @param $modules
- * An array of the modules that were uninstalled.
- *
- * @see hook_uninstall()
- */
-function hook_modules_uninstalled($modules) {
- if (in_array('lousy_module', $modules)) {
- \Drupal::state()->delete('mymodule.lousy_module_compatibility');
- }
- mymodule_cache_rebuild();
-}
-
-/**
- * Remove any information that the module sets.
- *
- * The information that the module should remove includes:
- * - state that the module has set using \Drupal::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 hook_install()
- * @see hook_schema()
- * @see hook_modules_uninstalled()
- */
-function hook_uninstall() {
- // Remove the styles directory and generated images.
- file_unmanaged_delete_recursive(file_default_scheme() . '://styles');
-}
-
-/**
- * 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 \Drupal::state() to
- * store any data that you may need later in the installation process. Any
- * temporary state must be removed using \Drupal::state()->delete() before
- * your last task has completed and control is handed back to the installer.
- *
- * @param array $install_state
- * An array of information about the current installation state.
- *
- * @return 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 install_state_defaults()
- * @see batch_set()
- * @see hook_install_tasks_alter()
- * @see install_tasks()
- */
-function hook_install_tasks(&$install_state) {
- // Here, we define a variable to allow tasks to indicate that a particular,
- // processor-intensive batch process needs to be triggered later on in the
- // installation.
- $myprofile_needs_batch_processing = \Drupal::state()->get('myprofile.needs_batch_processing', FALSE);
- $tasks = array(
- // This is an example of a task that defines a form which the user who is
- // installing the site will be asked to fill out. To implement this task,
- // your profile would define a function named myprofile_data_import_form()
- // as a normal form API callback function, with associated validation and
- // submit handlers. In the submit handler, in addition to saving whatever
- // other data you have collected from the user, you might also call
- // \Drupal::state()->set('myprofile.needs_batch_processing', TRUE) if the
- // user has entered data which requires that batch processing will need to
- // occur later on.
- 'myprofile_data_import_form' => array(
- 'display_name' => t('Data import options'),
- 'type' => 'form',
- ),
- // Similarly, to implement this task, your profile would define a function
- // named myprofile_settings_form() with associated validation and submit
- // handlers. This form might be used to collect and save additional
- // information from the user that your profile needs. There are no extra
- // steps required for your profile to act as an "installation wizard"; you
- // can simply define as many tasks of type 'form' as you wish to execute,
- // and the forms will be presented to the user, one after another.
- 'myprofile_settings_form' => array(
- 'display_name' => t('Additional options'),
- 'type' => 'form',
- ),
- // This is an example of a task that performs batch operations. To
- // implement this task, your profile would define a function named
- // myprofile_batch_processing() which returns a batch API array definition
- // that the installer will use to execute your batch operations. Due to the
- // 'myprofile.needs_batch_processing' variable used here, this task will be
- // hidden and skipped unless your profile set it to TRUE in one of the
- // previous tasks.
- 'myprofile_batch_processing' => array(
- 'display_name' => t('Import additional data'),
- 'display' => $myprofile_needs_batch_processing,
- 'type' => 'batch',
- 'run' => $myprofile_needs_batch_processing ? INSTALL_TASK_RUN_IF_NOT_COMPLETED : INSTALL_TASK_SKIP,
- ),
- // This is an example of a task that will not be displayed in the list that
- // the user sees. To implement this task, your profile would define a
- // function named myprofile_final_site_setup(), in which additional,
- // automated site setup operations would be performed. Since this is the
- // last task defined by your profile, you should also use this function to
- // call \Drupal::state()->delete('myprofile.needs_batch_processing') and
- // clean up the state that was used above. If you want the user to pass
- // to the final Drupal installation tasks uninterrupted, return no output
- // from this function. Otherwise, return themed output that the user will
- // see (for example, a confirmation page explaining that your profile's
- // tasks are complete, with a link to reload the current page and therefore
- // pass on to the final Drupal installation tasks when the user is ready to
- // do so).
- 'myprofile_final_site_setup' => array(
- ),
- );
- return $tasks;
-}
-
-/**
- * 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().
- *
- * @param $tasks
- * An 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.
- * @param $install_state
- * An array of information about the current installation state.
- *
- * @see hook_install_tasks()
- * @see install_tasks()
- */
-function hook_install_tasks_alter(&$tasks, $install_state) {
- // Replace the entire site configuration form provided by Drupal core
- // with a custom callback function defined by this installation profile.
- $tasks['install_configure_form']['function'] = 'myprofile_install_configure_form';
-}
-
-/**
- * Perform a single update.
- *
- * For each change that requires one or more actions to be performed when
- * updating a site, add a new hook_update_N(), which will be called by
- * update.php. The documentation block preceding this function is stripped of
- * newlines and used as the description for the update on the pending updates
- * task list. Schema updates should adhere to the
- * @link http://drupal.org/node/150215 Schema API. @endlink
- *
- * Implementations of hook_update_N() are named (module name)_update_(number).
- * The numbers are composed of three parts:
- * - 1 digit for Drupal core compatibility.
- * - 1 digit for your module's major release version (e.g., is this the 8.x-1.*
- * (1) or 8.x-2.* (2) series of your module).
- * - 2 digits for sequential counting, starting with 01.
- *
- * Examples:
- * - mymodule_update_8100(): This is the first update to get the database ready
- * to run mymodule 8.x-1.*.
- * - mymodule_update_8200(): This is the first update to get the database ready
- * to run mymodule 8.x-2.*.
- *
- * As of Drupal 8.0, the database upgrade system no longer supports updating a
- * database from an earlier major version of Drupal: update.php can be used to
- * upgrade from 7.x-1.x to 7.x-2.x, or 8.x-1.x to 8.x-2.x, but not from 7.x to
- * 8.x. Therefore, only update hooks numbered 8001 or later will run for
- * Drupal 8. 8000 is reserved for the minimum core schema version and defining
- * mymodule_update_8000() will result in an exception. Use the
- * @link https://drupal.org/node/2127611 Migration API @endlink instead to
- * migrate data from an earlier major version of Drupal.
- *
- * For further information about releases and release numbers see:
- * @link http://drupal.org/node/711070 Maintaining a drupal.org project with Git @endlink
- *
- * Never renumber update functions.
- *
- * Implementations of this hook should be placed in a mymodule.install file in
- * the same directory as mymodule.module. Drupal core's updates are implemented
- * using the system module as a name and stored in database/updates.inc.
- *
- * Not all module functions are available from within a hook_update_N() function.
- * In order to call a function from your mymodule.module or an include file,
- * you need to explicitly load that file first.
- *
- * During database updates the schema of any module could be out of date. For
- * this reason, caution is needed when using any API function within an update
- * function - particularly CRUD functions, functions that depend on the schema
- * (for example by using drupal_write_record()), and any functions that invoke
- * hooks.
- *
- * The $sandbox parameter should be used when a multipass update is needed, in
- * circumstances where running the whole update at once could cause PHP to
- * timeout. Each pass is run in a way that avoids PHP timeouts, provided each
- * pass remains under the timeout limit. To signify that an update requires
- * at least one more pass, set $sandbox['#finished'] to a number less than 1
- * (you need to do this each pass). The value of $sandbox['#finished'] will be
- * unset between passes but all other data in $sandbox will be preserved. The
- * system will stop iterating this update when $sandbox['#finished'] is left
- * unset or set to a number higher than 1. It is recommended that
- * $sandbox['#finished'] is initially set to 0, and then updated each pass to a
- * number between 0 and 1 that represents the overall % completed for this
- * update, finishing with 1.
- *
- * See the @link batch Batch operations topic @endlink for more information on
- * how to use the Batch API.
- *
- * @param array $sandbox
- * Stores information for multipass updates. See above for more information.
- *
- * @throws \Drupal\Core\Utility\UpdateException|PDOException
- * In case of error, update hooks should throw an instance of
- * Drupal\Core\Utility\UpdateException with a meaningful message for the user.
- * If a database query fails for whatever reason, it will throw a
- * PDOException.
- *
- * @return string|null
- * Optionally, update hooks may return a translated string that will be
- * displayed to the user after the update has completed. If no message is
- * returned, no message will be presented to the user.
- *
- * @see batch
- * @see schemaapi
- * @see hook_update_last_removed()
- * @see update_get_update_list()
- */
-function hook_update_N(&$sandbox) {
- // For non-multipass updates, the signature can simply be;
- // function hook_update_N() {
-
- // For most updates, the following is sufficient.
- db_add_field('mytable1', 'newcol', array('type' => 'int', 'not null' => TRUE, 'description' => 'My new integer column.'));
-
- // However, for more complex operations that may take a long time,
- // you may hook into Batch API as in the following example.
-
- // Update 3 users at a time to have an exclamation point after their names.
- // (They're really happy that we can do batch API in this hook!)
- if (!isset($sandbox['progress'])) {
- $sandbox['progress'] = 0;
- $sandbox['current_uid'] = 0;
- // We'll -1 to disregard the uid 0...
- $sandbox['max'] = db_query('SELECT COUNT(DISTINCT uid) FROM {users}')->fetchField() - 1;
- }
-
- $users = db_select('users', 'u')
- ->fields('u', array('uid', 'name'))
- ->condition('uid', $sandbox['current_uid'], '>')
- ->range(0, 3)
- ->orderBy('uid', 'ASC')
- ->execute();
-
- foreach ($users as $user) {
- $user->setUsername($user->getUsername() . '!');
- db_update('users')
- ->fields(array('name' => $user->getUsername()))
- ->condition('uid', $user->id())
- ->execute();
-
- $sandbox['progress']++;
- $sandbox['current_uid'] = $user->id();
- }
-
- $sandbox['#finished'] = empty($sandbox['max']) ? 1 : ($sandbox['progress'] / $sandbox['max']);
-
- if ($some_error_condition_met) {
- // In case of an error, simply throw an exception with an error message.
- throw new UpdateException('Something went wrong; here is what you should do.');
- }
-
- // To display a message to the user when the update is completed, return it.
- // If you do not want to display a completion message, simply return nothing.
- return t('The update did what it was supposed to do.');
-}
-
-/**
- * Return an array of information about module update dependencies.
- *
- * This can be used to indicate update functions from other modules that your
- * module's update functions depend on, or vice versa. It is used by the update
- * system to determine the appropriate order in which updates should be run, as
- * well as to search for missing dependencies.
- *
- * Implementations of this hook should be placed in a mymodule.install file in
- * the same directory as mymodule.module.
- *
- * @return
- * A multidimensional array containing information about the module update
- * dependencies. The first two levels of keys represent the module and update
- * number (respectively) for which information is being returned, and the
- * value is an array of information about that update's dependencies. Within
- * this array, each key represents a module, and each value represents the
- * number of an update function within that module. In the event that your
- * update function depends on more than one update from a particular module,
- * you should always list the highest numbered one here (since updates within
- * a given module always run in numerical order).
- *
- * @see update_resolve_dependencies()
- * @see hook_update_N()
- */
-function hook_update_dependencies() {
- // Indicate that the mymodule_update_8001() function provided by this module
- // must run after the another_module_update_8003() function provided by the
- // 'another_module' module.
- $dependencies['mymodule'][8001] = array(
- 'another_module' => 8003,
- );
- // Indicate that the mymodule_update_8002() function provided by this module
- // must run before the yet_another_module_update_8005() function provided by
- // the 'yet_another_module' module. (Note that declaring dependencies in this
- // direction should be done only in rare situations, since it can lead to the
- // following problem: If a site has already run the yet_another_module
- // module's database updates before it updates its codebase to pick up the
- // newest mymodule code, then the dependency declared here will be ignored.)
- $dependencies['yet_another_module'][8005] = array(
- 'mymodule' => 8002,
- );
- return $dependencies;
-}
-
-/**
- * Return a number which is no longer available as hook_update_N().
- *
- * If you remove some update functions from your mymodule.install file, you
- * should notify Drupal of those missing functions. This way, Drupal can
- * ensure that no update is accidentally skipped.
- *
- * Implementations of this hook should be placed in a mymodule.install file in
- * the same directory as mymodule.module.
- *
- * @return
- * An integer, corresponding to hook_update_N() which has been removed from
- * mymodule.install.
- *
- * @see hook_update_N()
- */
-function hook_update_last_removed() {
- // We've removed the 8.x-1.x version of mymodule, including database updates.
- // The next update function is mymodule_update_8200().
- return 8103;
-}
-
-/**
- * Provide information on Updaters (classes that can update Drupal).
- *
- * Drupal\Core\Updater\Updater is a class that knows how to update various parts
- * of the Drupal file system, for example to update modules that have newer
- * releases, or to install a new theme.
- *
- * @return
- * An associative array of information about the updater(s) being provided.
- * This array is keyed by a unique identifier for each updater, and the
- * values are subarrays that can contain the following keys:
- * - class: The name of the PHP class which implements this updater.
- * - name: Human-readable name of this updater.
- * - weight: Controls what order the Updater classes are consulted to decide
- * which one should handle a given task. When an update task is being run,
- * the system will loop through all the Updater classes defined in this
- * registry in weight order and let each class respond to the task and
- * decide if each Updater wants to handle the task. In general, this
- * doesn't matter, but if you need to override an existing Updater, make
- * sure your Updater has a lighter weight so that it comes first.
- *
- * @see drupal_get_updaters()
- * @see hook_updater_info_alter()
- */
-function hook_updater_info() {
- return array(
- 'module' => array(
- 'class' => 'Drupal\Core\Updater\Module',
- 'name' => t('Update modules'),
- 'weight' => 0,
- ),
- 'theme' => array(
- 'class' => 'Drupal\Core\Updater\Theme',
- 'name' => t('Update themes'),
- 'weight' => 0,
- ),
- );
-}
-
-/**
- * Alter the Updater information array.
- *
- * An Updater is a class that knows how to update various parts of the Drupal
- * file system, for example to update modules that have newer releases, or to
- * install a new theme.
- *
- * @param array $updaters
- * Associative array of updaters as defined through hook_updater_info().
- * Alter this array directly.
- *
- * @see drupal_get_updaters()
- * @see hook_updater_info()
- */
-function hook_updater_info_alter(&$updaters) {
- // Adjust weight so that the theme Updater gets a chance to handle a given
- // update task before module updaters.
- $updaters['theme']['weight'] = -1;
-}
-
-/**
- * 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.
- *
- * @param $phase
- * The 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.
- *
- * @return
- * 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.
- */
-function hook_requirements($phase) {
- $requirements = array();
-
- // Report Drupal version
- if ($phase == 'runtime') {
- $requirements['drupal'] = array(
- 'title' => t('Drupal'),
- 'value' => \Drupal::VERSION,
- 'severity' => REQUIREMENT_INFO
- );
- }
-
- // Test PHP version
- $requirements['php'] = array(
- 'title' => t('PHP'),
- 'value' => ($phase == 'runtime') ? \Drupal::l(phpversion(), new Url('system.php')) : phpversion(),
- );
- if (version_compare(phpversion(), DRUPAL_MINIMUM_PHP) < 0) {
- $requirements['php']['description'] = t('Your PHP installation is too old. Drupal requires at least PHP %version.', array('%version' => DRUPAL_MINIMUM_PHP));
- $requirements['php']['severity'] = REQUIREMENT_ERROR;
- }
-
- // Report cron status
- if ($phase == 'runtime') {
- $cron_last = \Drupal::state()->get('system.cron_last');
-
- if (is_numeric($cron_last)) {
- $requirements['cron']['value'] = t('Last run !time ago', array('!time' => \Drupal::service('date.formatter')->formatInterval(REQUEST_TIME - $cron_last)));
- }
- else {
- $requirements['cron'] = array(
- 'description' => t('Cron has not run. It appears cron jobs have not been setup on your system. Check the help pages for configuring cron jobs.', array('@url' => 'http://drupal.org/cron')),
- 'severity' => REQUIREMENT_ERROR,
- 'value' => t('Never run'),
- );
- }
-
- $requirements['cron']['description'] .= ' ' . t('You can run cron manually.', array('@cron' => \Drupal::url('system.run_cron')));
-
- $requirements['cron']['title'] = t('Cron maintenance tasks');
- }
-
- return $requirements;
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
diff --git a/core/modules/system/theme.api.php b/core/modules/system/theme.api.php
deleted file mode 100644
index eef4f5c..0000000
--- a/core/modules/system/theme.api.php
+++ /dev/null
@@ -1,1183 +0,0 @@
- array(
- * 'variables' => array(
- * 'result' => NULL,
- * 'plugin_id' => NULL,
- * ),
- * 'file' => 'search.pages.inc',
- * ),
- * );
- * @endcode
- * Given this definition, the template file with the default implementation is
- * search-result.html.twig, which can be found in the
- * core/modules/search/templates directory, and the variables for rendering are
- * the search result and the plugin ID. In addition, there is a function
- * template_preprocess_search_result(), located in file search.pages.inc, which
- * preprocesses the information from the input variables so that it can be
- * rendered by the Twig template; the processed variables that the Twig template
- * receives are documented in the header of the default Twig template file.
- *
- * hook_theme() implementations can also specify that a theme hook
- * implementation is a theme function, but that is uncommon. It is only used for
- * special cases, for performance reasons, because rendering using theme
- * functions is somewhat faster than theme templates.
- *
- * @section sec_overriding_theme_hooks Overriding Theme Hooks
- * Themes may register new theme hooks within a hook_theme() implementation, but
- * it is more common for themes to override default implementations provided by
- * modules than to register entirely new theme hooks. Themes can override a
- * default implementation by creating a template file with the same name as the
- * default implementation; for example, to override the display of search
- * results, a theme would add a file called search-result.html.twig to its
- * templates directory. A good starting point for doing this is normally to
- * copy the default implementation template, and then modifying it as desired.
- *
- * In the uncommon case that a theme hook uses a theme function instead of a
- * template file, a module would provide a default implementation function
- * called theme_HOOK, where HOOK is the name of the theme hook (for example,
- * theme_search_result() would be the name of the function for search result
- * theming). In this case, a theme can override the default implementation by
- * defining a function called THEME_HOOK() in its THEME.theme file, where THEME
- * is the machine name of the theme (for example, 'bartik' is the machine name
- * of the core Bartik theme, and it would define a function called
- * bartik_search_result() in the bartik.theme file, if the search_result hook
- * implementation was a function instead of a template). Normally, copying the
- * default function is again a good starting point for overriding its behavior.
- *
- * @section sec_preprocess_templates Preprocessing for Template Files
- * If the theme implementation is a template file, several functions are called
- * before the template file is invoked to modify the variables that are passed
- * to the template. These make up the "preprocessing" phase, and are executed
- * (if they exist), in the following order (note that in the following list,
- * HOOK indicates the theme hook name, MODULE indicates a module name, THEME
- * indicates a theme name, and ENGINE indicates a theme engine name). Modules,
- * themes, and theme engines can provide these functions to modify how the
- * data is preprocessed, before it is passed to the theme template:
- * - template_preprocess(&$variables, $hook): Creates a default set of variables
- * for all theme hooks with template implementations. Provided by Drupal Core.
- * - template_preprocess_HOOK(&$variables): Should be implemented by the module
- * that registers the theme hook, to set up default variables.
- * - MODULE_preprocess(&$variables, $hook): hook_preprocess() is invoked on all
- * implementing modules.
- * - MODULE_preprocess_HOOK(&$variables): hook_preprocess_HOOK() is invoked on
- * all implementing modules, so that modules that didn't define the theme hook
- * can alter the variables.
- * - ENGINE_engine_preprocess(&$variables, $hook): Allows the theme engine to
- * set necessary variables for all theme hooks with template implementations.
- * - ENGINE_engine_preprocess_HOOK(&$variables): Allows the theme engine to set
- * necessary variables for the particular theme hook.
- * - THEME_preprocess(&$variables, $hook): Allows the theme to set necessary
- * variables for all theme hooks with template implementations.
- * - THEME_preprocess_HOOK(&$variables): Allows the theme to set necessary
- * variables specific to the particular theme hook.
- *
- * @section sec_preprocess_functions Preprocessing for Theme Functions
- * If the theming implementation is a function, only the theme-hook-specific
- * preprocess functions (the ones ending in _HOOK) are called from the list
- * above. This is because theme hooks with function implementations need to be
- * fast, and calling the non-theme-hook-specific preprocess functions for them
- * would incur a noticeable performance penalty.
- *
- * @section sec_suggestions Theme hook suggestions
- * In some cases, instead of calling the base theme hook implementation (either
- * the default provided by the module that defined the hook, or the override
- * provided by the theme), the theme system will instead look for "suggestions"
- * of other hook names to look for. Suggestions can be specified in several
- * ways:
- * - In a render array, the '#theme' property (which gives the name of the hook
- * to use) can be an array of theme hook names instead of a single hook name.
- * In this case, the render system will look first for the highest-priority
- * hook name, and if no implementation is found, look for the second, and so
- * on. Note that the highest-priority suggestion is at the end of the array.
- * - In a render array, the '#theme' property can be set to the name of a hook
- * with a '__SUGGESTION' suffix. For example, in search results theming, the
- * hook 'item_list__search_results' is given. In this case, the render system
- * will look for theme templates called item-list--search-results.html.twig,
- * which would only be used for rendering item lists containing search
- * results, and if this template is not found, it will fall back to using the
- * base item-list.html.twig template. This type of suggestion can also be
- * combined with providing an array of theme hook names as described above.
- * - A module can implement hook_theme_suggestions_HOOK(). This allows the
- * module that defines the theme template to dynamically return an array
- * containing specific theme hook names (presumably with '__' suffixes as
- * defined above) to use as suggestions. For example, the Search module
- * does this in search_theme_suggestions_search_result() to suggest
- * search_result__PLUGIN as the theme hook for search result items, where
- * PLUGIN is the machine name of the particular search plugin type that was
- * used for the search (such as node_search or user_search).
- *
- * For further information on overriding theme hooks see
- * https://www.drupal.org/node/2186401
- *
- * @section sec_alternate_suggestions Altering theme hook suggestions
- * Modules can also alter the theme suggestions provided using the mechanisms
- * of the previous section. There are two hooks for this: the
- * theme-hook-specific hook_theme_suggestions_HOOK_alter() and the generic
- * hook_theme_suggestions_alter(). These hooks get the current list of
- * suggestions as input, and can change this array (adding suggestions and
- * removing them).
- *
- * @section assets Assets
- * We can distinguish between three types of assets:
- * - Unconditional page-level assets (loaded on all pages where the theme is in
- * use): these are defined in the theme's *.info.yml file.
- * - Conditional page-level assets (loaded on all pages where the theme is in
- * use and a certain condition is met): these are attached in
- * hook_page_attachments_alter(), e.g.:
- * @code
- * function THEME_page_attachments_alter(array &$page) {
- * if ($some_condition) {
- * $page['#attached']['library'][] = 'mytheme/something';
- * }
- * }
- * @endcode
- * - Template-specific assets (loaded on all pages where a specific template is
- * in use): these can be added by in preprocessing functions, using @code
- * $variables['#attached'] @endcode, e.g.:
- * @code
- * function THEME_preprocess_menu_local_action(array &$variables) {
- * // We require Modernizr's touch test for button styling.
- * $variables['#attached']['library'][] = 'core/modernizr';
- * }
- * @endcode
- *
- * @see hooks
- * @see callbacks
- * @see theme_render
- *
- * @}
- */
-
-/**
- * @defgroup theme_render Render API overview
- * @{
- * Overview of the Theme system and Render API.
- *
- * The main purpose of Drupal's Theme system is to give themes complete control
- * over the appearance of the site, which includes the markup returned from HTTP
- * requests and the CSS files used to style that markup. In order to ensure that
- * a theme can completely customize the markup, module developers should avoid
- * directly writing HTML markup for pages, blocks, and other user-visible output
- * in their modules, and instead return structured "render arrays" (see
- * @ref arrays below). Doing this also increases usability, by ensuring that the
- * markup used for similar functionality on different areas of the site is the
- * same, which gives users fewer user interface patterns to learn.
- *
- * For further information on the Theme and Render APIs, see:
- * - https://drupal.org/documentation/theme
- * - https://www.drupal.org/developing/api/8/render
- * - https://drupal.org/node/722174
- * - https://drupal.org/node/933976
- * - https://drupal.org/node/930760
- *
- * @todo Check these links. Some are for Drupal 7, and might need updates for
- * Drupal 8.
- *
- * @section arrays Render arrays
- * The core structure of the Render API is the render array, which is a
- * hierarchical associative array containing data to be rendered and properties
- * describing how the data should be rendered. A render array that is returned
- * by a function to specify markup to be sent to the web browser or other
- * services will eventually be rendered by a call to drupal_render(), which will
- * recurse through the render array hierarchy if appropriate, making calls into
- * the theme system to do the actual rendering. If a function or method actually
- * needs to return rendered output rather than a render array, the best practice
- * would be to create a render array, render it by calling drupal_render(), and
- * return that result, rather than writing the markup directly. See the
- * documentation of drupal_render() for more details of the rendering process.
- *
- * Each level in the hierarchy of a render array (including the outermost array)
- * has one or more array elements. Array elements whose names start with '#' are
- * known as "properties", and the array elements with other names are "children"
- * (constituting the next level of the hierarchy); the names of children are
- * flexible, while property names are specific to the Render API and the
- * particular type of data being rendered. A special case of render arrays is a
- * form array, which specifies the form elements for an HTML form; see the
- * @link form_api Form generation topic @endlink for more information on forms.
- *
- * Render arrays (at each level in the hierarchy) will usually have one of the
- * following three properties defined:
- * - #type: Specifies that the array contains data and options for a particular
- * type of "render element" (examples: 'form', for an HTML form; 'textfield',
- * 'submit', and other HTML form element types; 'table', for a table with
- * rows, columns, and headers). See @ref elements below for more on render
- * element types.
- * - #theme: Specifies that the array contains data to be themed by a particular
- * theme hook. Modules define theme hooks by implementing hook_theme(), which
- * specifies the input "variables" used to provide data and options; if a
- * hook_theme() implementation specifies variable 'foo', then in a render
- * array, you would provide this data using property '#foo'. Modules
- * implementing hook_theme() also need to provide a default implementation for
- * each of their theme hooks, normally in a Twig file. For more information
- * and to discover available theme hooks, see the documentation of
- * hook_theme() and the
- * @link themeable Default theme implementations topic. @endlink
- * - #markup: Specifies that the array provides HTML markup directly. Unless the
- * markup is very simple, such as an explanation in a paragraph tag, it is
- * normally preferable to use #theme or #type instead, so that the theme can
- * customize the markup.
- *
- * JavaScript and CSS assets are specified in the render array using the
- * #attached property (see @ref sec_attached).
- *
- * @section elements Render elements
- * Render elements are defined by Drupal core and modules. The primary way to
- * define a render element is to create a render element plugin. There are
- * two types of render element plugins:
- * - Generic elements: Generic render element plugins implement
- * \Drupal\Core\Render\Element\ElementInterface, are annotated with
- * \Drupal\Core\Render\Annotation\RenderElement annotation, go in plugin
- * namespace Element, and generally extend the
- * \Drupal\Core\Render\Element\RenderElement base class.
- * - Form input elements: Render elements representing form input elements
- * implement \Drupal\Core\Render\Element\FormElementInterface, are annotated
- * with \Drupal\Core\Render\Annotation\FormElement annotation, go in plugin
- * namespace Element, and generally extend the
- * \Drupal\Core\Render\Element\FormElement base class.
- * See the @link plugin_api Plugin API topic @endlink for general information
- * on plugins, and look for classes with the RenderElement or FormElement
- * annotation to discover what render elements are available.
- *
- * Modules can also currently define render elements by implementing
- * hook_element_info(), although defining a plugin is preferred.
- * properties. Look through implementations of hook_element_info() to discover
- * elements defined this way.
- *
- * @section sec_caching Caching
- * The Drupal rendering process has the ability to cache rendered output at any
- * level in a render array hierarchy. This allows expensive calculations to be
- * done infrequently, and speeds up page loading. See the
- * @link cache Cache API topic @endlink for general information about the cache
- * system.
- *
- * In order to make caching possible, the following information needs to be
- * present:
- * - Cache keys: Identifiers for cacheable portions of render arrays. These
- * should be created and added for portions of a render array that
- * involve expensive calculations in the rendering process.
- * - Cache contexts: Contexts that may affect rendering, such as user role and
- * language. When no context is specified, it means that the render array
- * does not vary by any context.
- * - Cache tags: Tags for data that rendering depends on, such as for
- * individual nodes or user accounts, so that when these change the cache
- * can be automatically invalidated. If the data consists of entities, you
- * can use \Drupal\Core\Entity\EntityInterface::getCacheTags() to generate
- * appropriate tags; configuration objects have a similar method.
- * - Cache max-age: The maximum duration for which a render array may be cached.
- * Defaults to \Drupal\Core\Cache\Cache::PERMANENT (permanently cacheable).
- *
- * Cache information is provided in the #cache property in a render array. In
- * this property, always supply the cache contexts, tags, and max-age if a
- * render array varies by context, depends on some modifiable data, or depends
- * on information that's only valid for a limited time, respectively. Cache keys
- * should only be set on the portions of a render array that should be cached.
- * Contexts are automatically replaced with the value for the current request
- * (e.g. the current language) and combined with the keys to form a cache ID.
- * The cache contexts, tags, and max-age will be propagated up the render array
- * hierarchy to determine cacheability for containing render array sections.
- *
- * Here's an example of what a #cache property might contain:
- * @code
- * '#cache' => [
- * 'keys' => ['entity_view', 'node', $node->id()],
- * 'contexts' => ['language'],
- * 'tags' => ['node:' . $node->id()],
- * 'max-age' => Cache::PERMANENT,
- * ],
- * @endcode
- *
- * At the response level, you'll see X-Drupal-Cache-Contexts and
- * X-Drupal-Cache-Tags headers.
- *
- * See https://www.drupal.org/developing/api/8/render/arrays/cacheability for
- * details.
- *
- * @section sec_attached Attaching libraries in render arrays
- * Libraries, JavaScript settings, feeds, HTML tags and HTML links
- * are attached to elements using the #attached property. The #attached property
- * is an associative array, where the keys are the attachment types and the
- * values are the attached data. For example:
- *
- * The #attached property allows loading of asset libraries (which may contain
- * CSS assets, JavaScript assets, and JavaScript setting assets), JavaScript
- * settings, feeds, HTML tags and HTML links. Specify an array of
- * type => value pairs, where the type (most often 'library' — for libraries, or
- * 'drupalSettings' — for JavaScript settings) to attach these response-level
- * values. Example:
- * @code
- * $build['#attached']['library'][] = 'core/jquery';
- * $build['#attached']['drupalSettings']['foo'] = 'bar';
- * $build['#attached']['feed'][] = ['aggregator/rss', $this->t('Feed title')];
- * @endcode
- *
- * See drupal_process_attached() for additional information.
- *
- * See \Drupal\Core\Asset\LibraryDiscoveryParser::parseLibraryInfo() for more
- * information on how to define libraries.
- *
- * @section render_pipeline The Render Pipeline
- * The term "render pipeline" refers to the process Drupal uses to take
- * information provided by modules and render it into a response. For more
- * details on this process, see https://www.drupal.org/developing/api/8/render;
- * for background on routing concepts, see @ref sec_controller.
- *
- * There are in fact multiple render pipelines:
- * - Drupal always uses the Symfony render pipeline. See
- * http://symfony.com/doc/2.7/components/http_kernel/introduction.html
- * - Within the Symfony render pipeline, there is a Drupal render pipeline,
- * which handles controllers that return render arrays. (Symfony's render
- * pipeline only knows how to deal with Response objects; this pipeline
- * converts render arrays into Response objects.) These render arrays are
- * considered the main content, and can be rendered into multiple formats:
- * HTML, Ajax, dialog, and modal. Modules can add support for more formats, by
- * implementing a main content renderer, which is a service tagged with
- * 'render.main_content_renderer'.
- * - Finally, within the HTML main content renderer, there is another pipeline,
- * to allow for rendering the page containing the main content in multiple
- * ways: no decoration at all (just a page showing the main content) or blocks
- * (a page with regions, with blocks positioned in regions around the main
- * content). Modules can provide additional options, by implementing a page
- * variant, which is a plugin annotated with
- * \Drupal\Core\Display\Annotation\PageDisplayVariant.
- *
- * Routes whose controllers return a \Symfony\Component\HttpFoundation\Response
- * object are fully handled by the Symfony render pipeline.
- *
- * Routes whose controllers return the "main content" as a render array can be
- * requested in multiple formats (HTML, JSON, etc.) and/or in a "decorated"
- * manner, as described above.
- *
- * @see themeable
- * @see \Symfony\Component\HttpKernel\KernelEvents::VIEW
- * @see \Drupal\Core\EventSubscriber\MainContentViewSubscriber
- * @see \Drupal\Core\Render\MainContent\MainContentRendererInterface
- * @see \Drupal\Core\Render\MainContent\HtmlRenderer
- * @see \Drupal\Core\Render\RenderEvents::SELECT_PAGE_DISPLAY_VARIANT
- * @see \Drupal\Core\Render\Plugin\DisplayVariant\SimplePageVariant
- * @see \Drupal\block\Plugin\DisplayVariant\BlockPageVariant
- * @see \Drupal\Core\Render\BareHtmlPageRenderer
- *
- * @}
- */
-
-/**
- * @addtogroup hooks
- * @{
- */
-
-/**
- * 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.
- *
- * @param $form
- * Nested array of form elements that comprise the form.
- * @param $form_state
- * The current state of the form.
- */
-function hook_form_system_theme_settings_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state) {
- // Add a checkbox to toggle the breadcrumb trail.
- $form['toggle_breadcrumb'] = array(
- '#type' => 'checkbox',
- '#title' => t('Display the breadcrumb'),
- '#default_value' => theme_get_setting('features.breadcrumb'),
- '#description' => t('Show a trail of links from the homepage to the current page.'),
- );
-}
-
-/**
- * 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 _theme().
- *
- * @param $variables
- * The variables array (modify in place).
- * @param $hook
- * The name of the theme hook.
- */
-function hook_preprocess(&$variables, $hook) {
- static $hooks;
-
- // Add contextual links to the variables, if the user has permission.
-
- if (!\Drupal::currentUser()->hasPermission('access contextual links')) {
- return;
- }
-
- if (!isset($hooks)) {
- $hooks = theme_get_registry();
- }
-
- // Determine the primary theme function argument.
- if (isset($hooks[$hook]['variables'])) {
- $keys = array_keys($hooks[$hook]['variables']);
- $key = $keys[0];
- }
- else {
- $key = $hooks[$hook]['render element'];
- }
-
- if (isset($variables[$key])) {
- $element = $variables[$key];
- }
-
- if (isset($element) && is_array($element) && !empty($element['#contextual_links'])) {
- $variables['title_suffix']['contextual_links'] = contextual_links_view($element);
- if (!empty($variables['title_suffix']['contextual_links'])) {
- $variables['attributes']['class'][] = 'contextual-links-region';
- }
- }
-}
-
-/**
- * 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 _theme().
- *
- * @param $variables
- * The variables array (modify in place).
- */
-function hook_preprocess_HOOK(&$variables) {
- // This example is from rdf_preprocess_image(). It adds an RDF attribute
- // to the image hook's variables.
- $variables['attributes']['typeof'] = array('foaf:Image');
-}
-
-/**
- * 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 @code 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;
-}
-
-/**
- * Alters named suggestions for all theme hooks.
- *
- * This hook is invoked for all theme hooks, if you are targeting a specific
- * theme hook it's best to use hook_theme_suggestions_HOOK_alter().
- *
- * The call order is as follows: all existing suggestion alter functions are
- * called for module A, then all for module B, etc., followed by all for any
- * base theme(s), and finally for the active theme. The order is
- * determined by system weight, then by extension (module or theme) name.
- *
- * Within each module or theme, suggestion alter hooks are called in the
- * following order: first, hook_theme_suggestions_alter(); second,
- * hook_theme_suggestions_HOOK_alter(). So, for each module or theme, the more
- * general hooks are called first followed by the more specific.
- *
- * In the following example, we provide an alternative template suggestion to
- * node and taxonomy term templates based on the user being logged in.
- * @code
- * function MYMODULE_theme_suggestions_alter(array &$suggestions, array $variables, $hook) {
- * if (\Drupal::currentUser()->isAuthenticated() && in_array($hook, array('node', 'taxonomy_term'))) {
- * $suggestions[] = $hook . '__' . 'logged_in';
- * }
- * }
- *
- * @endcode
- *
- * @param array $suggestions
- * An array of alternate, more specific names for template files or theme
- * functions.
- * @param array $variables
- * An array of variables passed to the theme hook. Note that this hook is
- * invoked before any variable preprocessing.
- * @param string $hook
- * The 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'].
- *
- * @return array
- * An array of theme suggestions.
- *
- * @see hook_theme_suggestions_HOOK_alter()
- */
-function hook_theme_suggestions_alter(array &$suggestions, array $variables, $hook) {
- // Add an interface-language specific suggestion to all theme hooks.
- $suggestions[] = $hook . '__' . \Drupal::languageManager()->getCurrentLanguage()->getId();
-}
-
-/**
- * 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 @code 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_alter()
- * @see hook_theme_suggestions_HOOK()
- */
-function hook_theme_suggestions_HOOK_alter(array &$suggestions, array $variables) {
- if (empty($variables['header'])) {
- $suggestions[] = 'hookname__' . 'no_header';
- }
-}
-
-/**
- * Respond to themes being installed.
- *
- * @param array $theme_list
- * Array containing the names of the themes being installed.
- *
- * @see \Drupal\Core\Extension\ThemeHandler::install()
- */
-function hook_themes_installed($theme_list) {
- foreach ($theme_list as $theme) {
- block_theme_initialize($theme);
- }
-}
-
-/**
- * Respond to themes being uninstalled.
- *
- * @param array $theme_list
- * Array containing the names of the themes being uninstalled.
- *
- * @see \Drupal\Core\Extension\ThemeHandler::uninstall()
- */
-function hook_themes_uninstalled(array $themes) {
- // Remove some state entries depending on the theme.
- foreach ($themes as $theme) {
- \Drupal::state()->delete('example.' . $theme);
- }
-}
-
-/**
- * Declare a template file extension to be used with a theme engine.
- *
- * This hook is used in a theme engine implementation in the format of
- * ENGINE_extension().
- *
- * @return string
- * The file extension the theme engine will recognize.
- */
-function hook_extension() {
- // Extension for template base names in Twig.
- return '.html.twig';
-}
-
-/**
- * Render a template using the theme engine.
- *
- * @param string $template_file
- * The path (relative to the Drupal root directory) to the template to be
- * rendered including its extension in the format 'path/to/TEMPLATE_NAME.EXT'.
- * @param array $variables
- * A keyed array of variables that are available for composing the output. The
- * theme engine is responsible for passing all the variables to the template.
- * Depending on the code in the template, all or just a subset of the
- * variables might be used in the template.
- *
- * @return string
- * The output generated from the template. In most cases this will be a string
- * containing HTML markup.
- */
-function hook_render_template($template_file, $variables) {
- $twig_service = \Drupal::service('twig');
-
- return $twig_service->loadTemplate($template_file)->render($variables);
-}
-
-/**
- * Allows modules to declare their own Form API element types and specify their
- * default values.
- *
- * This hook allows modules to declare their own form element types and to
- * specify their default values. The values returned by this hook will be
- * merged with the elements returned by form constructor implementations and so
- * can return defaults for any Form APIs keys in addition to those explicitly
- * documented by \Drupal\Core\Render\ElementInfoManagerInterface::getInfo().
- *
- * @return array
- * An associative array with structure identical to that of the return value
- * of \Drupal\Core\Render\ElementInfoManagerInterface::getInfo().
- *
- * @deprecated Use an annotated class instead, see
- * \Drupal\Core\Render\Element\ElementInterface.
- *
- * @see hook_element_info_alter()
- */
-function hook_element_info() {
- $types['filter_format'] = array(
- '#input' => TRUE,
- );
- return $types;
-}
-
-/**
- * Alter the element type information returned from modules.
- *
- * A module may implement this hook in order to alter the element type defaults
- * defined by a module.
- *
- * @param array $types
- * An associative array with structure identical to that of the return value
- * of \Drupal\Core\Render\ElementInfoManagerInterface::getInfo().
- *
- * @see hook_element_info()
- */
-function hook_element_info_alter(array &$types) {
- // Decrease the default size of textfields.
- if (isset($types['textfield']['#size'])) {
- $types['textfield']['#size'] = 40;
- }
-}
-
-/**
- * Perform necessary alterations to the JavaScript before it is presented on
- * the page.
- *
- * @param $javascript
- * An array of all JavaScript being presented on the page.
- * @param \Drupal\Core\Asset\AttachedAssetsInterface $assets
- * The assets attached to the current response.
- *
- * @see drupal_js_defaults()
- * @see \Drupal\Core\Asset\AssetResolver
- */
-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';
-}
-
-/**
- * Add dynamic library definitions.
- *
- * Modules may implement this hook to add dynamic library definitions. Static
- * libraries, which do not depend on any runtime information, should be declared
- * in a modulename.libraries.yml file instead.
- *
- * @return array[]
- * An array of library definitions to register, keyed by library ID. The
- * library ID will be prefixed with the module name automatically.
- *
- * @see core.libraries.yml
- * @see hook_library_info_alter()
- */
-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;
-}
-
-/**
- * Perform necessary alterations to the JavaScript settings (drupalSettings).
- *
- * @param array &$settings
- * An array of all JavaScript settings (drupalSettings) being presented on the
- * page.
- * @param \Drupal\Core\Asset\AttachedAssetsInterface $assets
- * The assets attached to the current response.
- *
- * @see \Drupal\Core\Asset\AssetResolver
- */
-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;
- }
-}
-
-/**
- * Alters the JavaScript/CSS library registry.
- *
- * Allows certain, contributed modules to update libraries to newer versions
- * while ensuring backwards compatibility. In general, such manipulations should
- * only be done by designated modules, since most modules that integrate with a
- * certain library also depend on the API of a certain library version.
- *
- * @param $libraries
- * The JavaScript/CSS libraries provided by $module. Keyed by internal library
- * name and passed by reference.
- * @param $module
- * The name of the module that registered the libraries.
- */
-function hook_library_info_alter(&$libraries, $module) {
- // Update Farbtastic to version 2.0.
- if ($module == '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;
- }
- }
-}
-
-/**
- * Alter CSS files before they are output on the page.
- *
- * @param $css
- * An array of all CSS items (files and inline CSS) being requested on the page.
- * @param \Drupal\Core\Asset\AttachedAssetsInterface $assets
- * The assets attached to the current response.
- *
- * @see Drupal\Core\Asset\LibraryResolverInterface::getCssAssets()
- */
-function hook_css_alter(&$css, \Drupal\Core\Asset\AttachedAssetsInterface $assets) {
- // Remove defaults.css file.
- unset($css[drupal_get_path('module', 'system') . '/defaults.css']);
-}
-
-/**
- * Add attachments (typically assets) to a page before it is rendered.
- *
- * Use this hook when you want to conditionally add attachments to a page.
- *
- * If you want to alter the attachments added by other modules or if your module
- * depends on the elements of other modules, use hook_page_attachments_alter()
- * instead, which runs after this hook.
- *
- * If you try to add anything but #attached and #post_render_cache to the array
- * an exception is thrown.
- *
- * @param array &$attachments
- * An array that you can add attachments to.
- *
- * @see hook_page_attachments_alter()
- */
-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';
- }
-}
-
-/**
- * Alter attachments (typically assets) to a page before it is rendered.
- *
- * Use this hook when you want to remove or alter attachments on the page, or
- * add attachments to the page that depend on another module's attachments (this
- * hook runs after hook_page_attachments().
- *
- * If you try to add anything but #attached and #post_render_cache to the array
- * an exception is thrown.
- *
- * @param array &$attachments
- * Array of all attachments provided by hook_page_attachments() implementations.
- *
- * @see hook_page_attachments_alter()
- */
-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]);
- }
-}
-
-/**
- * Add a renderable array to the top of the page.
- *
- * @param array $page_top
- * A renderable array representing the top of the page.
- */
-function hook_page_top(array &$page_top) {
- $page_top['mymodule'] = ['#markup' => 'This is the top.'];
-}
-
-/**
- * Add a renderable array to the bottom of the page.
- *
- * @param array $page_bottom
- * A renderable array representing the bottom of the page.
- */
-function hook_page_bottom(array &$page_bottom) {
- $page_bottom['mymodule'] = ['#markup' => 'This is the bottom.'];
-}
-
-/**
- * Register a module or theme's theme implementations.
- *
- * The implementations declared by this hook have several purposes:
- * - They can specify how a particular render array is to be rendered as HTML.
- * This is usually the case if the theme function is assigned to the render
- * array's #theme property.
- * - They can return HTML for default calls to _theme().
- * - They can return HTML for calls to _theme() for a theme suggestion.
- *
- * @param array $existing
- * An array of existing implementations that may be used for override
- * purposes. This is primarily useful for themes that may wish to examine
- * existing implementations to extract data (such as arguments) so that
- * it may properly register its own, higher priority implementations.
- * @param $type
- * Whether a theme, module, etc. is being processed. This is primarily useful
- * so that themes tell if they are the actual theme being called or a parent
- * theme. May be one of:
- * - 'module': A module is being checked for theme implementations.
- * - 'base_theme_engine': A theme engine is being checked for a theme that is
- * a parent of the actual theme being used.
- * - 'theme_engine': A theme engine is being checked for the actual theme
- * being used.
- * - 'base_theme': A base theme is being checked for theme implementations.
- * - 'theme': The actual theme in use is being checked.
- * @param $theme
- * The actual name of theme, module, etc. that is being being processed.
- * @param $path
- * The directory path of the theme or module, so that it doesn't need to be
- * looked up.
- *
- * @return array
- * An associative array of information about theme implementations. The keys
- * on the outer array are known as "theme hooks". For simple theme
- * implementations for regular calls to _theme(), the theme hook is the first
- * argument. For theme suggestions, instead of the array key being the base
- * theme hook, the key is a theme suggestion name with the format
- * 'base_hook_name__sub_hook_name'. For render elements, the key is the
- * machine name of the render element. The array values are themselves arrays
- * containing information about the theme hook and its implementation. Each
- * information array must contain either a 'variables' element (for _theme()
- * calls) or a 'render element' element (for render elements), but not both.
- * The following elements may be part of each information array:
- * - variables: Used for _theme() call items only: an array of variables,
- * where the array keys are the names of the variables, and the array
- * values are the default values if they are not passed into _theme().
- * Template implementations receive each array key as a variable in the
- * template file (so they must be legal PHP/Twig variable names). Function
- * implementations are passed the variables in a single $variables function
- * argument.
- * - render element: Used for render element items only: the name of the
- * renderable element or element tree to pass to the theme function. This
- * name is used as the name of the variable that holds the renderable
- * element or tree in preprocess and process functions.
- * - file: The file the implementation resides in. This file will be included
- * prior to the theme being rendered, to make sure that the function or
- * preprocess function (as needed) is actually loaded; this makes it
- * possible to split theme functions out into separate files quite easily.
- * - path: Override the path of the file to be used. Ordinarily the module or
- * theme path will be used, but if the file will not be in the default
- * path, include it here. This path should be relative to the Drupal root
- * directory.
- * - template: If specified, the theme implementation is a template file, and
- * this is the template name. Do not add 'html.twig' on the end of the
- * template name. The extension will be added automatically by the default
- * rendering engine (which is Twig.) If 'path' is specified, 'template'
- * should also be specified. If neither 'template' nor 'function' are
- * specified, a default template name will be assumed. For example, if a
- * module registers the 'search_result' theme hook, 'search-result' will be
- * assigned as its template name.
- * - function: If specified, this will be the function name to invoke for
- * this implementation. If neither 'template' nor 'function' are specified,
- * a default template name will be assumed. See above for more details.
- * - base hook: Used for _theme() suggestions only: the base theme hook name.
- * Instead of this suggestion's implementation being used directly, the base
- * hook will be invoked with this implementation as its first suggestion.
- * The base hook's files will be included and the base hook's preprocess
- * functions will be called in place of any suggestion's preprocess
- * functions. If an implementation of hook_theme_suggestions_HOOK() (where
- * HOOK is the base hook) changes the suggestion order, a different
- * suggestion may be used in place of this suggestion. If after
- * hook_theme_suggestions_HOOK() this suggestion remains the first
- * suggestion, then this suggestion's function or template will be used to
- * generate the output for _theme().
- * - pattern: A regular expression pattern to be used to allow this theme
- * implementation to have a dynamic name. The convention is to use __ to
- * differentiate the dynamic portion of the theme. For example, to allow
- * forums to be themed individually, the pattern might be: 'forum__'. Then,
- * when the forum is themed, call:
- * @code
- * _theme(array('forum__' . $tid, 'forum'), $forum)
- * @endcode
- * - 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 hook_theme_registry_alter()
- */
-function hook_theme($existing, $type, $theme, $path) {
- return array(
- 'forum_display' => array(
- 'variables' => array('forums' => NULL, 'topics' => NULL, 'parents' => NULL, 'tid' => NULL, 'sortby' => NULL, 'forum_per_page' => NULL),
- ),
- 'forum_list' => array(
- 'variables' => array('forums' => NULL, 'parents' => NULL, 'tid' => NULL),
- ),
- 'forum_icon' => array(
- 'variables' => array('new_posts' => NULL, 'num_posts' => 0, 'comment_mode' => 0, 'sticky' => 0),
- ),
- 'status_report' => array(
- 'render element' => 'requirements',
- 'file' => 'system.admin.inc',
- ),
- );
-}
-
-/**
- * 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 \Drupal\Core\Theme\Registry::processExtension().
- *
- * For example:
- * @code
- * $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',
- * ),
- * );
- * @endcode
- *
- * @param $theme_registry
- * The entire cache of theme registry information, post-processing.
- *
- * @see hook_theme()
- * @see \Drupal\Core\Theme\Registry::processExtension()
- */
-function hook_theme_registry_alter(&$theme_registry) {
- // Kill the next/previous forum topic navigation links.
- foreach ($theme_registry['forum_topic_navigation']['preprocess functions'] as $key => $value) {
- if ($value == 'template_preprocess_forum_topic_navigation') {
- unset($theme_registry['forum_topic_navigation']['preprocess functions'][$key]);
- }
- }
-}
-
-/**
- * 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:
- * @code
- * drupal_static_reset('template_preprocess');
- * @endcode
- *
- * See user_template_preprocess_default_variables_alter() for an example.
- *
- * @param array $variables
- * An associative array of default template variables, as set up by
- * _template_preprocess_default_variables(). Passed by reference.
- *
- * @see template_preprocess()
- * @see _template_preprocess_default_variables()
- */
-function hook_template_preprocess_default_variables_alter(&$variables) {
- $variables['is_admin'] = \Drupal::currentUser()->hasPermission('access administration pages');
-}
-
-/**
- * @} End of "addtogroup hooks".
- */
diff --git a/core/modules/system/token.api.php b/core/modules/system/token.api.php
deleted file mode 100644
index 51133de..0000000
--- a/core/modules/system/token.api.php
+++ /dev/null
@@ -1,261 +0,0 @@
- TRUE);
- if (isset($options['langcode'])) {
- $url_options['language'] = \Drupal::languageManager()->getLanguage($options['langcode']);
- $langcode = $options['langcode'];
- }
- else {
- $langcode = NULL;
- }
- $sanitize = !empty($options['sanitize']);
-
- $replacements = array();
-
- if ($type == 'node' && !empty($data['node'])) {
- /** @var \Drupal\node\NodeInterface $node */
- $node = $data['node'];
-
- foreach ($tokens as $name => $original) {
- switch ($name) {
- // Simple key values on the node.
- case 'nid':
- $replacements[$original] = $node->nid;
- break;
-
- case 'title':
- $replacements[$original] = $sanitize ? SafeMarkup::checkPlain($node->getTitle()) : $node->getTitle();
- break;
-
- case 'edit-url':
- $replacements[$original] = $node->url('edit-form', $url_options);
- break;
-
- // Default values for the chained tokens handled below.
- case 'author':
- $account = $node->getOwner() ? $node->getOwner() : User::load(0);
- $replacements[$original] = $sanitize ? SafeMarkup::checkPlain($account->label()) : $account->label();
- break;
-
- case 'created':
- $replacements[$original] = format_date($node->getCreatedTime(), 'medium', '', NULL, $langcode);
- break;
- }
- }
-
- if ($author_tokens = $token_service->findWithPrefix($tokens, 'author')) {
- $replacements = $token_service->generate('user', $author_tokens, array('user' => $node->getOwner()), $options);
- }
-
- if ($created_tokens = $token_service->findWithPrefix($tokens, 'created')) {
- $replacements = $token_service->generate('date', $created_tokens, array('date' => $node->getCreatedTime()), $options);
- }
- }
-
- return $replacements;
-}
-
-/**
- * Alter replacement values for placeholder tokens.
- *
- * @param $replacements
- * An associative array of replacements returned by hook_tokens().
- * @param $context
- * The 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'
- *
- * @see hook_tokens()
- */
-function hook_tokens_alter(array &$replacements, array $context) {
- $options = $context['options'];
-
- if (isset($options['langcode'])) {
- $url_options['language'] = \Drupal::languageManager()->getLanguage($options['langcode']);
- $langcode = $options['langcode'];
- }
- else {
- $langcode = NULL;
- }
-
- if ($context['type'] == 'node' && !empty($context['data']['node'])) {
- $node = $context['data']['node'];
-
- // Alter the [node:title] token, and replace it with the rendered content
- // of a field (field_title).
- if (isset($context['tokens']['title'])) {
- $title = $node->field_title->view('default');
- $replacements[$context['tokens']['title']] = drupal_render($title);
- }
- }
-}
-
-/**
- * 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
- * \Drupal\Core\Utility\Token::replace(), which invokes hook_tokens(). Your
- * module will need to implement that hook in order to generate token
- * replacements from the tokens defined here.
- *
- * @return
- * 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
- * \Drupal\Core\Utility\Token::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
- * \Drupal\Core\Utility\Token::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 \Drupal\Core\Utility\Token::replace()
- * without having to supply a separate user object.
- *
- * @see hook_token_info_alter()
- * @see hook_tokens()
- */
-function hook_token_info() {
- $type = array(
- 'name' => t('Nodes'),
- 'description' => t('Tokens related to individual nodes.'),
- 'needs-data' => 'node',
- );
-
- // Core tokens for nodes.
- $node['nid'] = array(
- 'name' => t("Node ID"),
- 'description' => t("The unique ID of the node."),
- );
- $node['title'] = array(
- 'name' => t("Title"),
- );
- $node['edit-url'] = array(
- 'name' => t("Edit URL"),
- 'description' => t("The URL of the node's edit page."),
- );
-
- // Chained tokens for nodes.
- $node['created'] = array(
- 'name' => t("Date created"),
- 'type' => 'date',
- );
- $node['author'] = array(
- 'name' => t("Author"),
- 'type' => 'user',
- );
-
- return array(
- 'types' => array('node' => $type),
- 'tokens' => array('node' => $node),
- );
-}
-
-/**
- * Alter the metadata about available placeholder tokens and token types.
- *
- * @param $data
- * The associative array of token definitions from hook_token_info().
- *
- * @see hook_token_info()
- */
-function hook_token_info_alter(&$data) {
- // Modify description of node tokens for our site.
- $data['tokens']['node']['nid'] = array(
- 'name' => t("Node ID"),
- 'description' => t("The unique ID of the article."),
- );
- $data['tokens']['node']['title'] = array(
- 'name' => t("Title"),
- 'description' => t("The title of the article."),
- );
-
- // Chained tokens for nodes.
- $data['tokens']['node']['created'] = array(
- 'name' => t("Date created"),
- 'description' => t("The date the article was posted."),
- 'type' => 'date',
- );
-}
-
-/**
- * @} End of "addtogroup hooks".
- */