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 */
|