Posted by mikeryan on November 18, 2013 at 9:35pm
Backing up a bit to a high-level view of the architecture, right now we've got the whole thing in a single Migrate module. I'd like to see some separation between the APIs that will service all kinds of migrations, and the support specific to Drupal-to-Drupal upgrades, as well as identifying what (if anything) requires a module. The buckets of code I picture:
Core
- Migrate API: Most of what we have now.
- Upgrade API: Any classes specific to Drupal-to-Drupal migration.
- Upgrade module: D6/D7 migration configurations, plus UI.
Contrib
- migrate_plus module (or even call it "migrate", if there's no module in core?): General migration UI, D7 migrate features not going into core such as different source plugins, etc.
- migrate_d2d module: Support for D5 and D8 sources, UI for remapping content types (i.e., support for custom Drupal-to-Drupal migrations as opposed to upgrade-all-the-things), etc.
Thoughts?
Comments
Line between contrib and core not fully clarified for me
Excuse my ignorance as I have not been following all of the IMP discussions extremely closely... But this post left me with a question:
Is IMP going to support sources on the D6 end and corresponding destinations on the D8 end (if I have that terminology right) for D6 content types built with the (obviously contrib in 6) CCK? And if so, which fields -- do others need to be done in contrib? And how about user profile fields and categories in 6? And Views? That clarification is missing from your list in this post.
Also I guess that you should specifically say in your list that contrib modules need to provide migrate source/destination classes in their D8 repos for their module's specific data and configuration, right?
Drupal programmer - http://poplarware.com
Drupal author - http://shop.oreilly.com/product/0636920034612.do
Drupal contributor - https://www.drupal.org/u/jhodgdon
This post was just intended
This post was just intended to speak at the highest level of organization for the APIs, between core and the contrib side of the migrate framework, not to address things at the level of what precise types of data are covered. We do need to catalog precisely what will be covered and where it will be handled, but that's a subject for a separate discussion.
As to your specific questions - yes, CCK fields will be supported. We haven't dug into this area in detail yet, but I would assume all field types which are in core in D8 will be supported. Certainly user profiles will also be supported. I hadn't thought about views, but since we have Views in core in D8 I assume we'll want to import view definitions from D6/D7. And contrib modules with custom data will need to implement the Migrate API in lieu of the traditional update functions (big win here is that, unlike update functions, implementing the destination classes will also support migration from non-Drupal sources).
Mike Ryan
Seems like it might be more
Seems like it might be more productive to have a narrow scope to accomplish and then widen out. Like, for instance, concentrate on core, specifically on a 6->8 upgrade path. Once that's stable, start adding contrib stuff like CCK.
I think I obscured my main
I think I obscured my main point by bringing up the core/contrib boundary...
Within the core migrate implementation, rather than mix the general Migrate APIs which will be usable for all sorts of migrations with the support for Drupal upgrade paths, I think they should be separated out:
Core
If we are to do this, better sooner than later, I think.
Thoughts on this?
Mike Ryan