You are here

Migrating Content part 3: Nodes with your own field handlers

In this finale (?) on using the Migrate module, I will go through how to go about writing your very own field handler to pull in content into a field type that does not yet have a mapped path. In this example, we will be migrating an events (so the date field from the date module will require a migration path). At the time of writing, http://drupal.org/node/1021076 had not yet been resolved (or have the ability for date_to and date_from to be established) so we will write out a field handler that handles just this!

The first article discussed the merits of using the Migrate module. The second article was a walkthrough on how to import users. The third article was a walkthrough on how to import basic nodes.

Much like last time, we first define our migration class

class MyEventMigration extends Migration {

// ...

}

And this class will consist of two functions - one is the class constructor while the other is for massaging/adding extra information on a per row basis.

/**

* Class Constructor

*/

publicfunction __construct(){

// ...

}

/**

* Add any additional data / clean up data for the current row / node that will be added/updated.

*/

publicfunction prepareRow($current_row){

// ...

}

In this full scenario, if you follow the steps that are described in the node migration walkthrough, you should be most of the way there. However, we need to define a way to map out our event information so we define the field handler that will handle our events. Much like how we defined certain pieces of data into classes such as the MigrateTextFieldHandler or the MigrateFileFieldHandler, let's call this one MigrateDateFieldHandler:

// Define a way to migrate the date field.

class MigrateDateFieldHandler extends MigrateFieldHandler {

// Define the constructor of our Handler - it lets Migrate know what *types* of fields this handler is compatible against.

publicfunction __construct(){

// ...

}

// Define our arguments on where this data will be found during the preparation.

DISCLAIMER: To note, the arguments() structure is based on how the handling was created for files (there are separators for each row of data so would have '2011-01-01 12:30|2011-01-02 1:30|## 2011-01-04 8:30|2011-01-10 10:00|')
First comes the implementation of the constructor:

Simple! Now migrate knows that this class will only handle these types of fields (so links, files, text will not get processed and instead throw an error).
Next comes the implementation of the arguments

And with that, you now have your own field handler which can be used by the migrate module to bring in other types of fields/content to your new site (such as links, computed fields, etc).

Instead of posting out the entire module (over 150 lines of code) in here, I have posted the module in a sandbox called 'REDCAT migration' so you can go through and examine the code side by side with this documentation :)

I hope all of this has been helpful. If something doesn't make a lot of sense, leave a comment! I want to keep improving this documentation and hopefully, all of this will be even more useful to other folk looking to migrate content in the Drupal community.