DrupalCon Munich 2012: An import/upgrade API for core
See http://drupal.org/node/1052692 for background.
Problems
Upgrades for major core versions have become increasingly more painful as Drupal itself has grown more complex, and the schema changes from version to version.
The upgrade process is a one-shot, in-place deal - if something goes wrong in the middle, assuming you were prudent, you have to restore backups and start over. If you weren't prudent...
Skipping a version (e.g., going from Drupal 5 to Drupal 7) is next to impossible - one must follow the upgrade path through intermediate versions, and it's a long shot that most of your content makes it through alive.
Major core upgrades are wonderful opportunities for refactoring - both revisiting architecture decisions that didn't pan out (we really could consolidate our 120 content types to 12) and taking advantage of new features. The current upgrade-in-place methodology requires two separate major site launches to reach the end state.
Goal
Ease the straight upgrade process.
Make upgrading more robust - resumable, rollbackable, etc.
Support importing from any Drupal version.
Allow the import process to be customized - remap/refactor content during upgrade.
Proposed Solution
The proposal is to add new APIs, based on our experience with the Migrate module, to support upgrading by importing from the source site to a target installation. At this point, I see two APIs - a general Import API (which would have many other applications, of course) and an Upgrade API built on the Import API, with particular intelligence about the versions of Drupal we will support out-of-the-box. Plus, of course, there will need to be a UI for performing the upgrades. The Import API would correspond to the basic framework today implemented by the Migrate module; work on the migrate_d2d module will serve as a POC for the upgrade functionality.
Problems
Upgrades for major core versions have become increasingly more painful as Drupal itself has grown more complex, and the schema changes from version to version.
The upgrade process is a one-shot, in-place deal - if something goes wrong in the middle, assuming you were prudent, you have to restore backups and start over. If you weren't prudent...
Skipping a version (e.g., going from Drupal 5 to Drupal 7) is next to impossible - one must follow the upgrade path through intermediate versions, and it's a long shot that most of your content makes it through alive.
Major core upgrades are wonderful opportunities for refactoring - both revisiting architecture decisions that didn't pan out (we really could consolidate our 120 content types to 12) and taking advantage of new features. The current upgrade-in-place methodology requires two separate major site launches to reach the end state.
Goal
Ease the straight upgrade process.
Make upgrading more robust - resumable, rollbackable, etc.
Support importing from any Drupal version.
Allow the import process to be customized - remap/refactor content during upgrade.
Proposed Solution
The proposal is to add new APIs, based on our experience with the Migrate module, to support upgrading by importing from the source site to a target installation. At this point, I see two APIs - a general Import API (which would have many other applications, of course) and an Upgrade API built on the Import API, with particular intelligence about the versions of Drupal we will support out-of-the-box. Plus, of course, there will need to be a UI for performing the upgrades. The Import API would correspond to the basic framework today implemented by the Migrate module; work on the migrate_d2d module will serve as a POC for the upgrade functionality.