Follow-up to(borrowing some of alexpott's commentary)
The migrate_drupal module, when enabled, installs almost 100 configuration entities supporting migration from Drupal 6. When Drupal 7 support is committed, that will double. And eventual contrib support for migration from other Drupal versions, if it follows this model, will inflate the numbers further. This presents the following problems:
- As installed, these configuration entities are incomplete - they cannot be actually used without adding configuration for the source database.
- On any given site, only a subset of the config entities will ever be used. In a straight upgrade scenario, only those applicable to the source site's Drupal version are needed, and among those only the ones with applicable sources and destinations (e.g., the book-related config entities are only needed when the book module is enabled on both the source and destination sites).
- They pollute config export - putting them into your site config git repo - does that make sense
- Contrib tools for managing migrations will operate on fully-configured (runnable) migrations - if active configuration is full of what are really hypothetical migrations, they will need to deal with filtering them out somehow.
Implement a configuration template system - a means of managing default configurations which are not in the site's active config but can be discovered and used to build configuration entities that will be further configured and saved dynamically to active configuration. Use this template system in migrate_drupal.
The way I visualize this working with the upgrade UI is:
- User enters credentials for a Drupal database, and the site address (needed for finding public files), and submits the form.
- migrate_upgrade identifies the version (let's say Drupal 6) and queries the template system for relevant templates (currently, that means those with migration_tags containing "Drupal 6").
- (postponed) It creates a migration group containing the db credentials, and constructs the migration configuration entity for each template pointing it to the group.
- At least for now (pending either group support or a state-based means of saving db credentials), the db credentials are merged into each migration.
- The site address is set as the source_base_path for any file migrations.
- For each migration, if its requirements are met (e.g., for the d6_book migration, the book module is enabled in both the source D6 and destination D8 sites), it is saved to active configuration. Otherwise, it is discarded.
- The migration process is run for all migrations in active configuration assigned to the newly-constructed group.
- Once the migrated content is validated, migrate_upgrade and migrate_drupal can be uninstalled, uninstalling the associated configuration entities.
- Proposed solution is awaiting RTBC and commit.
User interface changes
Service migrate.template_storage added, with a findTemplatesByTag($tag) method which retrieves all templates matching the specified tag (having it under the 'migration_tags' key) indexed by template name with values consisting of the parsed template.
ConfigInstaller::validateDependencies() made public; parameter $additional_config added (names of templates being instantiated in the same operation, so config dependencies among them are resolved) - this allows consumers of the template service to validate prospective migration entities before attempting to create them.
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,124 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,246 pass(es). View