Wondering what the plan is in the long term for contrib module migration sources? Migrate_extras provides contrib destinations, so should there be a migrate_d2d_extras, eventually? Would it make sense to start that immediately (Sorry, I can't volunteer to maintain anything like this at the moment), or add basic stuff into a sub-module of migrate_d2d?

Some key modules really need something like this, including CCK, image.module, date, webform etc.

Comments

mikeryan’s picture

Title: Contrib sources? » How to support contrib module sources

Support for some common contrib modules (CCK, date, content_profile) is built-in. I absolutely do not want to create another _extras module, it's simply impossible to centrally maintain a repository supporting myriad ever-evolving contrib modules - I'm deprecating migrate_extras as it is in favor of building migration support into the contrib modules themselves.

Note that migrate_d2d automatically detects all the subfields of CCK fields, so support for specific CCK field types is unnecessary, which covers a lot of this problem. As for other modules that add data to nodes/users/etc., it will take some thought on what an API to support them would look like.

naught101’s picture

@Mike, sorry, that question was perhaps misleading. My understanding is that migrate_extras only include destinations, and not sources. It's entirely reasonable to expect modules to include their own migrate destinations, but most will not go back to previous versions and add sources. In particular popular, superseeded modules, like image.module, where development is basically redundant, are unlikely to provide any sources for d5/d6. What should happen in this case? Perhaps because these are likely fairly rare cases, they should just be written in their own contrib module?