How to register Field Handler class with Migrate module

Question

I'm trying to use the migrate module to import some video fields. I'm assuming that I'll need to write an extension to the MigrateFileFieldHandler. I set up a shell class based on what I saw in the MigrateImageFieldHandler (which is a subclass of MigrateFileFieldHandler), however my class doesn't seem to get loaded.

My guess is that I need to register my Field Handler somewhere, somehow, but I can't find any instructions or examples anywhere. I know that I register Migrations in the hook_migrate_api but I can't find how or where I need to register Field Handlers.

Answer 1

From this blog post it looks like you register the field type from within your custom class: http://openconcept.ca/blog/mmallett/migrating-data-using-drupals-migrate-module

as such:

class MigrateCUSTOMFIELDNAMEFieldHandler extends MigrateFieldHandler {
  public function __construct() {
    $this->registerTypes(array('email'));
  }
// more stuff in your class ...

Without such information migrate usually just silently ignores the field, or try to work with it in any way. The same rule for an improperly named/implemented Migration class -- you just don't see it in drush ms.

EDIT:

From the blog post, actually from MigrateExtras README:

The Migrate Extras module provides extensions to Migrate (http://drupal.org/project/migrate) to support various contributed modules. The ideal place to implement migration support for a contributed module is in that module. That way, the migration support is always self-consistent with the current module implementation - it's not practical for the migrate_extras module to keep up with changes to all other contrib modules. Support for contributed modules may be added to migrate_extras for two reasons - if the module's maintainer does not accept a patch providing migration support, or as an intermediate step before submitting such a patch to the other module.

In cases where modules supported by migrate_extras end up implementing the support themselves, you could at least temporarily end up with redundant implementations. The extra implementation may be disabled at admin/content/migrate/configure.

Anyway, if you then look at: http://drupalcode.org/project/migrate_extras.git/blob/9843c3b2c003e8bd19bb370e6eb6b2264f13eca1:/migrate_extras.migrate.inc

They declare their migrate API integration thus:

/*
 * Implementation of hook_migrate_api().
 */
function migrate_extras_migrate_api() {
  $api = array(
    'api' => 2,
    'destination handlers' => array(
      'MigratePathautoHandler',
      'MigrateExtrasNodeFlagHandler',
      'MigrateExtrasUserFlagHandler',
    ),
    'field handlers' => array(
      'MigrateAddressFieldHandler',
      'MigrateCckPhoneHandler',
      'MigrateGeoFieldHandler',
      'MigrateIntervalFieldHandler',
      'MigrateNameHandler',
      'MigrateMediaFieldHandler',
    )
  );
  return $api;
}

You probably want to list your FieldHanlder in a similar fashion (but with your class name). You probably also want to add it to the files[] array of your module so it is autoloaded and Migrate sees it.

Your new FieldHanlder should be listed at admin/content/migrate/configure

... if you read the blog post provided, it explains this oddity of FieldHandlers ...