1

I expect this is a trivial question for those familiar with OOP/PHP. The migrate_d2d module provides an example module that demonstrates implementing a D6 -> D7 migration. I'm making great progress in defining the migration as I need. However, I am stumped on how I can add team information to my custom migration. The provided beer examples show performing this step when extending the Migration class.

abstract class BasicExampleMigration extends Migration {
  public function __construct($arguments) {
    parent::__construct($arguments);

    $this->team = array(
      new MigrateTeamMember('Liz Taster', 'ltaster@example.com',
                            t('Product Owner')),
      new MigrateTeamMember('Larry Brewer', 'lbrewer@example.com',
                            t('Implementor')),
    );

    $this->issuePattern = 'http://drupal.org/node/:id:';
  }
}

With migrate_d2d, the chain of dependency starts with the migrate_d2d class definitions:

Migration > DrupalMigration when then forks to:  
DrupalUserMigration > DrupalUser7Migration  
DrupalTermMigration > DrupalTerm7Migration  
DrupalRoleMigration > DrupalRole7Migration  
...etc

For my purposes, I'd like the DrupalMigration object to have the team properties set.

How do I modify DrupalMigration class properties so that I can set the team's properties and have all the children classes inherit this property?

1

I just followed the dependency chain of the example module:

  • ExampleNodeMigration extends DrupalNode6Migration
  • DrupalNode6Migration extends DrupalNodeMigration
  • DrupalNodeMigration extends DrupalMigration
  • DrupalMigration extends Migration

That means that as long as your class, like ExampleNodeMigration, extends a class down the chain from class Migration, your team implementation should be as in the example you gave.

In light of the changes you made:

How do I modify DrupalMigration class properties so that I can set the team's properties and have all the children classes inherit this property?

You insert your own custom class that extends the lowest class in the chain that has what you need, then have your migration modules extend it. So if you are migrating users, you would extend DrupalUser7Migration in some custom class, then have your various user migration classes extend DrupalUser7Migration, and so on for each variety of thing that migrate_d2d can migrate. That may be the best you can do because PHP is single-inheritance.

There is another way to get around single-inheritance and not repeat yourself. You can create a trait, called, for example, MyMigrationSettings.

trait MyMigrationSettings {
  function setTeam() {
    $this->team = array(
    new MigrateTeamMember('Liz Taster', 'ltaster@example.com',
                        t('Product Owner')),
    new MigrateTeamMember('Larry Brewer', 'lbrewer@example.com',
                        t('Implementor')),
    );
  }
}

Then, use the trait in your migration classes:

class ExampleNodeMigration extends DrupalNode6Migration {
  use MyMigrationSettings;
  public function __construct($arguments) {
    parent::__construct($arguments);
    $this->setTeam();
    // ...
  );
}

I have not tested this code and I am just literally typing it into the comment box.

2
  • Yes — that is what the beer.inc example presumes. This presumption breaks on the migrate_d2d model. I've re-written my question to hopefully clarify. – Screenack Nov 7 '15 at 20:25
  • Thanks — this is fantastic! The only downside is we're running 5.3.3. – Screenack Nov 10 '15 at 1:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.