How to migrate content from drupal 6 to 7 by using Migrate_d2d - Part 2 - taxonomy

This is the second part in a series of blog posts about migrate and migrate_d2d. I will in this post demonstrate how to migrate taxonomy terms from Drupal 6 to Drupal 7. Part 1 - Background, setup and user migration. contain information about how migration i general work and the needed configuration. Please make sure you read and understand it before attempting to follow this.

Blog post in this series

Migrating taxonomies

It is vital to understand that migrating taxonomy terms is just that. It only migrate terms from one vocabulary to the other. It does not create a reference to your entities (nodes, files etc), that have to be done when these entities are migrated to your system. This also means taxonomy terms have to be migrated before you attempt to migrate, for example, nodes.

Configuration

Before we jump into the code, let's make sure we have what we need. Basic config is covered in Part 1 - Background, setup and user migration. These are only the moving parts you need to make the example code work.

Drupal 6

Create in admin/generate three vocabularies, or use the Drupal 6 core taxonomy UI to create them. The code rely on that you have the following vocabularies 1, 2 and 3. Unlike Drupal 7, Drupal 6 does not have proper machine names.

Create three taxonomy vocabulary In Drupal 6 create three taxonomy vocabularies needed to store all taxonomy terms. Make also sure you generate nodes that populate and use them.

Drupal 7

Go to admin/structure/taxonomy and make sure you have three vocabularies named: tags, tags1 and tags2. Not very exiting names but they will do their job.

Create three taxonomy vocabulary In Drupal 7 create three taxonomy vocabularies needed to store all taxonomy terms migrated from Drupal 6.

Exampe 2 - Migrate taxonomy terms from Drupal 6

Grab the code from github and clone it into your Drupal 7 sites/all/modules/ directory.

git clone --branch example2 https://github.com/steinmb/smb_migrate.git

Or if you already have cloned it by following example 1, simply switc branch:

git checkout example2

Register and de-register statically defined classes

After the module is enabled does Migrate require you might have to register your migration task (class) (Introduced by Migrate 7.x-2.6). Running drush ms should list your taxonomy migration tasks if not you have to register them by running the following drush command:

drush migrate-register

You should see something like "All statically defined migrations have been (re)registered". If UI is your thing visit admin/content/migrate/configure and press the button labeled "Register statically defined classes". This should take you to the migration overview page that should list this migration.

You can also remove registered import tasks and groups with migrate-deregister

drush migrate-deregister --help

lists avaiable options. Notice this is also how you remove orphans. They are normally migrations groups and tasks left behind after you alter and/or remove migration tasks during development.

Run migrate status

To view the state and verify that the new migration task was registered run migrate status:

drush ms

It should return something along these lines:

Group: taxonomy           Total  Imported  Unprocessed  Status  Last imported
Tags                      14     0         14           Idle
Tags2                     17     0         17           Idle
Tags3                     19     0         19           Idle

Group: content_migration  Total  Imported  Unprocessed  Status  Last imported
User                      51     0         51           Idle

Migration groups and importing terms

I wanted to demonstrate the use of migration groups. Here can you see all the taxonomy migrations task grouped inside the group taxonomy. You can then run all three migration task simply by:

drush mi --group=taxonomy

It should return something along these lines:

Processed 14 (14 created, 0 updated, 0 failed, 0 ignored) in 0.1 sec (8949/min) - done with 'Tags'
Processed 17 (17 created, 0 updated, 0 failed, 0 ignored) in 0.1 sec (9067/min) - done with 'Tags2'
Processed 19 (19 created, 0 updated, 0 failed, 0 ignored) in 0.1 sec (9622/min) - done with 'Tags3'

You can also choose to import them one by one:

drush mi Tags

Code breakdown

I will here only review the code that have been added/changed since blog post part 1. Not exactly sure what the other code do, have a look at part 1.

smb_migrate.migrate.inc

<?php
function smb_migrate_migrate_api() {
 
$api = array(
   
'api' => 2,
   
'groups' => array(
     
'content_migration' => array(
       
'title' => t('SMB Drupal 6 to Drupal 7 content migration example.'),
      ),
     
'taxonomy' => array(
       
'title' => t('SMB Drupal 6 to Drupal 7 taxonomy migration example.')
      ),
    ),
  );
 
?>

Create a new group called "taxonomy" allowing us to group all three taxonomy tasks.

<?php
/**
 * For vocabulary migrations, source_vocabulary and destination_vocabulary are
 * required arguments. Note that in Drupal 6 vocabularies did not have machine
 * names, so we use the vocabulary ID to uniquely identify them.
 */
$vocabulary_arguments = array(
 
'Tags' => array(
   
'description' => t('Migration of Topics terms from Drupal 6'),
   
'source_vocabulary' => '1'// D6 Vocabulary ID
   
'destination_vocabulary' => 'tags',
   
'group_name' => 'taxonomy',
  ),
 
'Tags2' => array(
   
'description' => t('Migration of Topics terms from Drupal 6'),
   
'source_vocabulary' => '2'// D6 Vocabulary ID
   
'destination_vocabulary' => 'tags2',
   
'group_name' => 'taxonomy',
  ),
 
'Tags3' => array(
   
'description' => t('Migration of Topics terms from Drupal 6'),
   
'source_vocabulary' => '3'// D6 Vocabulary ID
   
'destination_vocabulary' => 'tags3',
   
'group_name' => 'taxonomy',
  ),
);
?>

We here create three migration tasks named: Tags, Tags2, Tags3. The names means nothing, name them anything you like.

  • source_vocabulary: As mention above, Drupal 6 does not have proper machine names. source_vocabulary points to the vocabulary ID in Drupal 6.
  • destination_vocabulary is the machine name in Drupal 7 we target the terms to.
  • group_name: Bind the migration task to the group we created above.
<?php
/**
 * Again, we're using the migrate_d2d class directly.
 * The soft dependency says that while we don't have to run the user migration
 * first, we want to make sure it's listed first so the vocabularies are
 * listed right ahead of the node migrations.
 */
$common_vocabulary_arguments = $common_arguments + array(
 
'class_name' => 'DrupalTerm6Migration',
 
'soft_dependencies' => array('User'),
);
?>
  • class_name: PHP class name that does the heavy lifting while the migration run. If you want to find out more. Have a look inside migrate_d2d/d6/taxonomy.inc. Search for the class class DrupalTerm6Migration extends DrupalTermMigration.

Migrating files and/or images

In the next part will we look at migrating files and images. Well, they are actually all only files.

Blog post in this series

Add new comment