Home / Migrate 2.6 - UI changes

Migrate 2.6 - UI changes

The Migrate module provides services for migrating data from various sources (other CMS frameworks, external web services, or other Drupal installations) into the local Drupal environment. It has been used to migrate sites such as The Economist, Examiner.com, Stanford Law School, and PayPal and eBay's developer forums (x.com) to Drupal.

Since my previous post on the framework changes in Migrate 2.6, I have released a release candidate. Today I will cover some of the most significant changes in the Migrate UI, for those who have been working with Migrate 2.5 and earlier.

Groups in UI

The first difference you will probably notice in the Migrate UI is in the main dashboard page at admin/content/migrate. Formerly this listed every migration you had defined, but now that we've enhanced group functionality, the first thing you'll see here is a list of your groups. For example, if you have migrate_example enabled:
Migrate dashboard
More on that "Source system" column in the next post...

Clicking on a group name will give you the list of migrations (or "tasks") in the group, which should look more familiar to the experienced Migrate user:
Task list

Basic vs. advanced UI permissions

With Migrate 2.6, we've introduced two levels of permission - migration information and advanced migration information. The advanced permission shows you everything you, as a migration developer, are used to seeing. But, sometimes, you may want to enable people who aren't migration developers to monitor and run migration processes. Now you can grant them a role with the migration information permission, and their view of the task listing page will look like:
Basic tasklist
They will have a more limited view when clicking the task name as well (in particular not having access to the feature in the next section!).

Editing of field mappings

The biggest leap forward in the Migrate UI with version 2.6 is the ability to edit a migration's field mappings and dependencies. In the past, these have always been defined in code, in the migration class constructor, but now the code-based configuration can be overridden through the UI:
Field mapping editor
You can select the source field from the available source fields which are not marked "DNM", set a default value for when no source field is mapped or the source value is empty, and select another migration for translating source IDs into Drupal IDs. You can also select source fields to mark "DNM":
Source fields
and edit migration dependencies:
Dependencies

Invoking drush-based imports from the UI

As explained in the Migrate documentation, running migrations through drush is preferable to running them through the UI. However, what if you need to enable non-technical (or non-privileged-to-ssh-to-the-server-and-run-drush) users, i.e., the ones we've introduced the basic permission level for, to be able to perform imports, and your migrations are too large and/or slow to effectively run via Batch API? Well, WordPress Migrate has had an answer to that for a while - the ability to have the UI trigger a drush command running in the background on the server. This feature has now been generalized and brought into Migrate itself. When you visit the Migrate configuration page on a vanilla install, you'll see:
Background configuration
The first thing to do is to set the migrate_drush_path variable to point to your drush command:

$ which drush
/Applications/acquia-drupal/drush/drush
$ drush vset migrate_drush_path /Applications/acquia-drupal/drush/drush
migrate_drush_path was set to "/Applications/acquia-drupal/drush/drush".

You can also set it in your settings.php file:
$conf['migrate_drush_path'] = '/Applications/acquia-drupal/drush/drush';

If you're lucky, you'll be all set. If not, when you refresh the configuration page you'll see:
Background configuration failure
The configuration page attempts to run a drush status command, and if it fails notifies you. The most likely reason it would fail is if your web server PATH does not include PHP - fixing this is dependent on your environment, and left as an exercise for the reader. Once you do have it fixed, refreshing the configuration page should look like this:
Background configuration success
You can choose whether the standard Import and Rollback operations always use Batch API, always use drush, or you can make both options available:
Background/immediate execution
Finally, you can send an email notification to the account running the migration:
Background email configuration
In my next post, I will talk about the new framework in Migrate 2.6 to ease the development of wizard-style UIs for defining and registering migrations.

Reacties

Posted on by Jeff Geerling (niet gecontroleerd).

These improvements are coming at exactly the right time for me; I just started working on a major migration, and haven't had to do any since 2.4 was released; the improvements are very welcome, especially the ability to define simple migrations through the UI/wizard (which has been missing since the days of 6.x) and, and the ability to kick off drush migrations in the background through the UI.

Thank you for your hard work on this module!

Posted on by Kosta Harlan.

Thanks for all your hard work on this, Migrate is a great module to work with!

With the new interface, do you recommend creating migration mappings through the UI, in code, or both? Is there the ability to see which UI mappings are overriding what is in code? or to export the UI mapping to code?

Posted on by mryan.

I would implement sensible default field mappings in the code, which you can then override through the UI.

On the migration detail View tab, under the Mapping vertical tabs, mappings that are pulled from the database (most likely, but not necessarily, because they were overridden through the UI) are italicized.

The ability to export mappings to code most likely won't happen until Migrate V3 on Drupal 8 - see https://drupal.org/node/1983404

Posted on by Michael Anello.

Mike - this is great stuff - is it safe to upgrade from 2.5 to 2.6? Is there any chance of it breaking a migration that is in-progress?

Thanks,
-mike

Reactie toevoegen

Plain text

  • Geen HTML toegestaan.
  • Adressen van webpagina's en e-mailadressen worden automatisch naar links omgezet.
  • Regels en alinea's worden automatisch gesplitst.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Adressen van webpagina's en e-mailadressen worden automatisch naar links omgezet.
  • Toegelaten HTML-tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Regels en alinea's worden automatisch gesplitst.
Bij het indienen van dit fomulier gaat u akkoord met het privacybeleid van Mollom.