Posted by chx on October 27, 2013 at 3:00pm
As far as I am concerned, the UI will contain:
- the database credential fields straight out of the installer
- Edit:
A Drupal version select boxit seems we can divine this from the system table. - A file path textfield. (MIght need two for private files in D7)
- A button saying Migrate configuration
- A button saying Migrate content
Comments
A Drupal version picker
Perhaps it would be simpler for the end user for Drupal 8 to detect the version being migrated from?
Simpler for the user
impossible for the developer. Suggestions welcome but I can't see how we would achieve such a miracle.
Edt: Apparently, I am wrong. Congrats jessehs.
how about something like
how about something like this:
<?php$result = $this->database
->select('system', 's', array('fetch' => \PDO::FETCH_ASSOC))
->fields('s', array('schema_version'))
->condition('name', 'system')
->execute();
if ($result['schema_version'] < 7000) {
$form['version_select']['#default_value'] = 'drupal6';
}
elseif ($result['schema_version'] > 7000) {
$form['version_select']['#default_value'] = 'drupal7';
}
Next question, are there
Next question, are there cases where one would want to migrate only configuration and not content? Will the user be able to migrate content without migrating configuration? If not, there don't need to be two buttons for migrating.
Migrating content without
Migrating content without configuration is entirely valid. That's basically the current day migrate module.
I would count content type
I would count content type settings and fields as "configuration". But if that's considered to be "content", then I agree it's valid to import content + content type settings/fields and skip Drupal module core/contrib settings.
The reason
We want to migrate configuration first and separately because you can not migrate content without the configuration in place (content types and fields are just a few that comes to mind) and while content is happily restartable, continously migrateable and stuff , configuration is all or nothing: if it fails, wipe and restart. I think we need to separate these steps.
Agreed that config goes
Agreed that config goes first. I think many sites will not migrate config but will simply build a D8 site from scratch and migrate content. So splitting these makes sense. Migrate module already provides groups for situations like this.
A file path textfield. (MIght
A file path textfield. (MIght need two for private files in D7)Aren't these stored in the variables table of the source database?
Indeed, they are stored
Indeed, they are stored there, but we do not know that they are in the same system than we are running d8 in(can be remote), so local paths are needed(in the remote case, either manually copying the directories or mounting on top of something like ssh fuse).
I think
The http:// stream wrapper might be usable and so we can migrate from another server. I will strive to get the file handling work with it.
D7 (and beyond) are
D7 (and beyond) are hyper-alterable and pluggable. It won't be possible for core to look after everyone's remote files and pluggable storage and so on. Contrib has to deal with all those non-default configurations.