So after fooling around with this module a bit, I realised I will probably need to write my own missing moduleUpgradePaths for things like content_profile (coming from a complicated D6 site).

Is there any documentation on howto add your own upgrade paths to this? What would be the best practice / recommended way to do this?

Files: 

Comments

askibinski created an issue. See original summary.

mikeryan’s picture

Title: Custom migration / module upgrade paths » Document implementing migration paths for contrib modules
Project: Migrate Upgrade » Drupal core
Version: 8.x-1.x-dev » 8.0.x-dev
Component: Documentation » documentation
Parent issue: » #2561243: [meta] Migration system documentation

I'm afraid we don't have specific documentation for this yet, just general docs on migration development, so let's make this the issue to add that documentation.

Besides the documentation, this is on my list of topics to blog about in the coming weeks. But for the meantime, your best bet is to learn from core - implementing a migration path for a contrib module is really no different than doing it for a core module. In this particular case, you're in luck - the migration path for content_profile will look a lot like the migration path for core profile values, the main difference being the queries to obtain the source data. So, in the core user module, look at:

  • migration_templates/*profile*.yml
  • src/Plugin/migrate/source/ProfileField.php
  • src/Plugin/migrate/source/d6/ProfileFieldValues.php

If you get stuck, you can always pop a question or three into the #drupal-migrate IRC channel.

mikeryan’s picture

Category: Support request » Task
askibinski’s picture

1. Thanks for the pointers! I managed to create a module which at least recognizes the plugin.
It doesn't really do much yet in terms of migration, but I think it's a start.

Created the sandbox with the module here: https://www.drupal.org/sandbox/merge/2612546

There is a lot of stuff copied from the core user module in /src there.

2. Using the module 'content_profile' is not yet anymore missing from the list of detected D6 modules, using the UI from migrate_upgrade.
However, I did have to patch the migrate_upgrade module to add my path in MigrateUpgradeForm.php:

    'content_profile' => [
      'source_module' => 'content_profile',
      'destination_module' => 'user',
    ],

I think there should be a better way to do this, and I think this is the issue for it:
#2568523: Standardize source module discovery mechanism

philipz’s picture

I'm trying to implement a migration path from d6 module (emfield) to d8 (Video Embed Field).
The above comments are great starter for me but I'm wondering how could I test and rollback migrations during development.
I mean is there any control over migrate/upgrate like it is in D7 migrate (limit, rollback etc.) or do I have to just run the whole upgrade each time I make a change in code? :)

mikeryan’s picture

From my recent blog post:

I will also note that in terms of debugging your upgrade path, the drush migrate-upgrade command has a very handy --configure-only option, which runs the configuration portion of the upgrade (turning migration templates into migration configuration entities) without actually running the imports. When debugging a specific upgrade migration, I will use this option, then (with migrate_tools installed) import all the migrations previous to the one I'm testing. At this point I can do drush sql-dump >/tmp/backup.sql. It's much faster to test the migration, tweak it, and restore the backup for another try than it is to go all the way back to the beginning.

philipz’s picture

@mikeryan: Thanks for quick reply and all the work you're doing! :) I must have missed that part of the post somehow.

philipz’s picture

FileSize
3.42 KB

I've managed to have some progress with migration of contrib module field but I would appreciate a lot any help or pointing me in the right direction :)

1. I've added my field to map in d6_field.yml migration template file. This resulted in field being created during node configuration migration.
2. I've run content type data migration and the field is populated with value from d6 site. This is done by the default get plugin which copies value column as I understand.
3. I've created MigrateProcessPlugin and MigrateCckField in the contrib module I'm trying to migrate. Those plugins are not picked up during migration.

Is there anything else I should set up to make the plugins work and copy the other field columns from source database?
I was following core link module so far but there's nothing more I can find inside of it...

benjy’s picture

Hi philipz, is this for video_embed_field? Sam152 actually asked me to take a look at that and I intended to write it and document the process for other contrib authors but if you've already started, maybe you could share the code with me in a sandbox and we can do it together?

philipz’s picture

Sure, I would be happy to work together. I created an issue for this couple of days ago: #2623950: Write migration from Drupal 6 for Embedded Media Field
I don't have a sandbox for this yet and all the code I have is the patch I've uploaded already and minor change in core field migration templates.
I'll set up the sandbox and share it with you.

jhodgdon’s picture

Please lets keep this discussion about adding documentation for contrib maintainers. Thanks!

philipz’s picture

maryedith’s picture

HI, there, What is the latest on migrating Content Profile? I am working on a d6-d8 migration and will need to bring forward User data stored in Content Profile fields.
Thanks much for any info.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.