annotate core/modules/migrate/migrate.api.php @ 0:4c8ae668cc8c

Initial import (non-working)
author Chris Cannam
date Wed, 29 Nov 2017 16:09:58 +0000
parents
children 1fec387a4317
rev   line source
Chris@0 1 <?php
Chris@0 2
Chris@0 3 /**
Chris@0 4 * @file
Chris@0 5 * Hooks provided by the Migrate module.
Chris@0 6 */
Chris@0 7
Chris@0 8 use Drupal\migrate\Plugin\MigrationInterface;
Chris@0 9 use Drupal\migrate\Plugin\MigrateSourceInterface;
Chris@0 10 use Drupal\migrate\Row;
Chris@0 11
Chris@0 12 /**
Chris@0 13 * @defgroup migration Migration API
Chris@0 14 * @{
Chris@0 15 * Overview of the Migration API, which migrates data into Drupal.
Chris@0 16 *
Chris@0 17 * @section overview Overview of migration
Chris@0 18 * Migration is an
Chris@0 19 * @link http://wikipedia.org/wiki/Extract,_transform,_load Extract, Transform, Load @endlink
Chris@0 20 * (ETL) process. In the Drupal migration API the extract phase is called
Chris@0 21 * "source", the transform phase is called "process", and the load phase is
Chris@0 22 * called "destination". It is important to understand that the "load" in ETL
Chris@0 23 * means to load data into storage, while traditionally Drupal uses "load" to
Chris@0 24 * mean load data from storage into memory.
Chris@0 25 *
Chris@0 26 * In the source phase, a set of data, called the row, is retrieved from the
Chris@0 27 * data source, typically a database but it can be a CSV, JSON or XML file. The
Chris@0 28 * row is sent to the process phase where it is transformed as needed by the
Chris@0 29 * destination, or marked to be skipped. Processing can also determine that a
Chris@0 30 * stub needs to be created, for example, if a term has a parent term that does
Chris@0 31 * not yet exist. After processing the transformed row is passed to the
Chris@0 32 * destination phase where it is loaded (saved) into the Drupal 8 site.
Chris@0 33 *
Chris@0 34 * The ETL process is configured by the migration plugin. The different phases:
Chris@0 35 * source, process, and destination are also plugins, and are managed by the
Chris@0 36 * Migration plugin. So there are four types of plugins in the migration
Chris@0 37 * process: migration, source, process and destination.
Chris@0 38 *
Chris@0 39 * @section sec_migrations Migration plugins
Chris@0 40 * Migration plugin definitions are stored in a module's 'migrations' directory.
Chris@0 41 * For backwards compatibility we also scan the 'migration_templates' directory.
Chris@0 42 * Examples of migration plugin definitions can be found in
Chris@0 43 * 'core/modules/action/migration_templates'. The plugin class is
Chris@0 44 * \Drupal\migrate\Plugin\Migration, with interface
Chris@0 45 * \Drupal\migrate\Plugin\MigrationInterface. Migration plugins are managed by
Chris@0 46 * the \Drupal\migrate\Plugin\MigrationPluginManager class. Migration plugins
Chris@0 47 * are only available if the providers of their source plugins are installed.
Chris@0 48 *
Chris@0 49 * @section sec_source Source plugins
Chris@0 50 * Migration source plugins implement
Chris@0 51 * \Drupal\migrate\Plugin\MigrateSourceInterface and usually extend
Chris@0 52 * \Drupal\migrate\Plugin\migrate\source\SourcePluginBase. They are annotated
Chris@0 53 * with \Drupal\migrate\Annotation\MigrateSource annotation, and must be in
Chris@0 54 * namespace subdirectory Plugin\migrate\source under the namespace of the
Chris@0 55 * module that defines them. Migration source plugins are managed by the
Chris@0 56 * \Drupal\migrate\Plugin\MigrateSourcePluginManager class. Source plugin
Chris@0 57 * providers are determined by their and their parents namespaces.
Chris@0 58 *
Chris@0 59 * @section sec_process Process plugins
Chris@0 60 * Migration process plugins implement
Chris@0 61 * \Drupal\migrate\Plugin\MigrateProcessInterface and usually extend
Chris@0 62 * \Drupal\migrate\ProcessPluginBase. They are annotated
Chris@0 63 * with \Drupal\migrate\Annotation\MigrateProcessPlugin annotation, and must be
Chris@0 64 * in namespace subdirectory Plugin\migrate\process under the namespace of the
Chris@0 65 * module that defines them. Migration process plugins are managed by the
Chris@0 66 * \Drupal\migrate\Plugin\MigratePluginManager class. The Migrate module
Chris@0 67 * provides process plugins for common operations (setting default values,
Chris@0 68 * mapping values, etc.).
Chris@0 69 *
Chris@0 70 * @section sec_destination Destination plugins
Chris@0 71 * Migration destination plugins implement
Chris@0 72 * \Drupal\migrate\Plugin\MigrateDestinationInterface and usually extend
Chris@0 73 * \Drupal\migrate\Plugin\migrate\destination\DestinationBase. They are
Chris@0 74 * annotated with \Drupal\migrate\Annotation\MigrateDestination annotation, and
Chris@0 75 * must be in namespace subdirectory Plugin\migrate\destination under the
Chris@0 76 * namespace of the module that defines them. Migration destination plugins
Chris@0 77 * are managed by the \Drupal\migrate\Plugin\MigrateDestinationPluginManager
Chris@0 78 * class. The Migrate module provides destination plugins for Drupal core
Chris@0 79 * objects (configuration and entity).
Chris@0 80 *
Chris@0 81 * @section sec_more_info More information
Chris@0 82 * @link https://www.drupal.org/node/2127611 Migration API documentation. @endlink
Chris@0 83 *
Chris@0 84 * @see update_api
Chris@0 85 * @}
Chris@0 86 */
Chris@0 87
Chris@0 88 /**
Chris@0 89 * @addtogroup hooks
Chris@0 90 * @{
Chris@0 91 */
Chris@0 92
Chris@0 93 /**
Chris@0 94 * Allows adding data to a row before processing it.
Chris@0 95 *
Chris@0 96 * For example, filter module used to store filter format settings in the
Chris@0 97 * variables table which now needs to be inside the filter format config
Chris@0 98 * file. So, it needs to be added here.
Chris@0 99 *
Chris@0 100 * hook_migrate_MIGRATION_ID_prepare_row() is also available.
Chris@0 101 *
Chris@0 102 * @ingroup migration
Chris@0 103 */
Chris@0 104 function hook_migrate_prepare_row(Row $row, MigrateSourceInterface $source, MigrationInterface $migration) {
Chris@0 105 if ($migration->id() == 'd6_filter_formats') {
Chris@0 106 $value = $source->getDatabase()->query('SELECT value FROM {variable} WHERE name = :name', [':name' => 'mymodule_filter_foo_' . $row->getSourceProperty('format')])->fetchField();
Chris@0 107 if ($value) {
Chris@0 108 $row->setSourceProperty('settings:mymodule:foo', unserialize($value));
Chris@0 109 }
Chris@0 110 }
Chris@0 111 }
Chris@0 112
Chris@0 113 /**
Chris@0 114 * Allows altering the list of discovered migration plugins.
Chris@0 115 *
Chris@0 116 * Modules are able to alter specific migrations structures or even remove or
Chris@0 117 * append additional migrations to the discovery. For example, this
Chris@0 118 * implementation filters out Drupal 6 migrations from the discovered migration
Chris@0 119 * list. This is done by checking the migration tags.
Chris@0 120 *
Chris@0 121 * @param array[] $migrations
Chris@0 122 * An associative array of migrations keyed by migration ID. Each value is the
Chris@0 123 * migration array, obtained by decoding the migration YAML file and enriched
Chris@0 124 * with some meta information added during discovery phase, like migration
Chris@0 125 * 'class', 'provider' or '_discovered_file_path'.
Chris@0 126 *
Chris@0 127 * @ingroup migration
Chris@0 128 */
Chris@0 129 function hook_migration_plugins_alter(array &$migrations) {
Chris@0 130 $migrations = array_filter($migrations, function (array $migration) {
Chris@0 131 $tags = isset($migration['migration_tags']) ? (array) $migration['migration_tags'] : [];
Chris@0 132 return !in_array('Drupal 6', $tags);
Chris@0 133 });
Chris@0 134 }
Chris@0 135
Chris@0 136 /**
Chris@0 137 * @} End of "addtogroup hooks".
Chris@0 138 */