Hi! Thanks for this excellent module.

Could someone please provide a minimal example of the code I should put in my custom module in order to map several source fields into a single location field? I have looked over the example beer.inc and wine.inc, and they don't seem to address this.

Someone asked for a similar example for filefields here: http://drupal.org/node/753130
But the answer to "create a content set" isn't specific enough, because I don't know the syntax required.
The examples in beer.inc and wine.inc are only for nodes, users, terms, and comments.

I'm sorry if this is somewhere in the issues queue or code. I looked but couldn't find it. Thank you!

Comments

Anonymous’s picture

Anonymous (not verified) commented

Just to clarify: there is some old code using hook_prepare_migrate_node here:

http://www.lullabot.com/articles/drupal-data-imports-migrate-and-table-w...

But if I understand correctly, the support for Location in Migrate Extras means that this is no longer the way to do this, that we should instead be using a content set, right?

Anonymous’s picture

Anonymous (not verified) commented

Ok, after way too long, I think I have a working solution. But I'd really like someone more experienced to confirm that this is the correct way to do this. If so, please put it prominently on the front page of Migrate Extras! :)

So, here is code to migrate source fields into a single Location CCK field, attached to a node, as part of a node migration. You want to use a prepare function. It goes inside your NodeMigration, but outside the _construct function.

class LegacyBizNodeMigration extends LegacyMigration {
  public function __construct() {
    parent::__construct();
    $this->description = t('Business Listing Nodes');
   // ... rest of _construct function.
   }

  // Here is where you build your location.
  public function prepare(stdClass $account, stdClass $row) {
    // The source fields are named address, city, state, and zip.
    // The destination fields are street, city, province, and postal_code.
    $location = array(
		      'street' => $row->address,
		      'city' => $row->city,
		      'province' => $row->state,
		      'postal_code' => $row->zip,
		      // There are many more available keys, see location_save or location module for more details
		      );
    $lid = location_save($location);
    
    //    If you have the devel module, you can uncomment this line and confirm that your location is being populated with your data. It will spit out the full location info, even with drush. 
    //    dpm($location);

    // The destination location CCK field is field_biz_location
    // The [0] is the delta. You'll need to modify this code if you're trying to save multiple locations to a single node.
    $account->field_biz_location[0]['lid'] = $lid;
  }

} // End of LegacyBizNodeMigration
dags’s picture

dags commented

This looks good to me. It's pretty close to what I came up with.

I have one problem though, maybe you can help: I have latitude and longitude information stored for each node I'm importing, and during a migration, those coordinates always default to 0. I tried changing the column type on latitude and longitude in the location table, and I messed around with different combinations of 'source' and 'locpick', but so far nothing has worked. Any ideas?

lobo235’s picture

lobo235 commented

troubador, Thanks for the info in #2. Worked like a charm for me using 6.x-2.1.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Version: 6.x-2.0-rc1 » 6.x-2.x-dev
Category: support » feature
Priority: Major » Normal

That looks workable (to someone who's never used the Location module, anyway). The proper way to do it, however, is with a field handler like you see in date.inc. Location support for V2 is now consolidated to the following issue:

#943178: Implementation of Location support for Migrate Extras V2

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Active » Closed (duplicate)
mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Version: 6.x-2.x-dev » 6.x-2.0-rc1
Category: feature » support
Priority: Normal » Major

Location support for V2 is now consolidated to the following issue:

#943178: Implementation of Location support for Migrate Extras V2

dreamriks’s picture

dreamriks commented
Title: Working example of how to map source fields to a Location destination field? » usage of migrate module
Assigned: Unassigned » dreamriks
Status: Closed (duplicate) » Active

hi,
I tried to use migrate moduleto create node from the available database. for this i started modifying the beer example. the first thing that i did was , i edit the beertermmigration function and just changed the name of the database table in the query as shown below:

$query = db_select('jos_users', 'met')
->fields('met', array('id', 'name', 'username', 'email', 'password','usertype','block','sendEmail','gid','registerDate','lastvisitDate','activation','params'))
// This sort assures that parents are saved before children.
->orderBy('usertype', 'ASC');

// Create a MigrateSource object, which manages retrieving the input data.
$this->source = new MigrateSourceSQL($query);

// Set up our destination - terms in the migrate_example_beer_styles vocabulary
$this->destination = new MigrateDestinationTerm('Migrate Example Beer Styles');

// Assign mappings TO destination fields FROM source fields. To discover
// the names used in these calls, use the drush commands
// drush migrate-fields-destination BeerTerm
// drush migrate-fields-source BeerTerm
$this->addFieldMapping('name', 'name');
$this->addFieldMapping('username', 'username');

// Documenting your mappings makes it easier for the whole team to see
// exactly what the status is when developing a migration process.
$this->addFieldMapping('email', 'email')
->description(t('The incoming lastvisitDate field is the name of the term parent'));

// Mappings are assigned issue groups, by which they are grouped on the
// migration info page when the migrate_ui module is enabled. The default
// is 'Done', indicating active mappings which need no attention. A
// suggested practice is to use groups of:
// Do Not Migrate (or DNM) to indicate source fields which are not being used,
// or destination fields not to be populated by migration.
// Client Issues to indicate input from the client is needed to determine
// how a given field is to be migrated.
// Implementor Issues to indicate that the client has provided all the
// necessary information, and now the implementor needs to complete the work.
$this->addFieldMapping(NULL, 'usertype')
->description(t('This info will not be maintained in Drupal'))
->issueGroup(t('DNM'));
$this->addFieldMapping(NULL, 'block')
->description(t('This info will not be maintained in Drupal'))
->issueGroup(t('DNM'));
$this->addFieldMapping(NULL, 'sendEmail')
->description(t('This info will not be maintained in Drupal'))
->issueGroup(t('DNM'));
$this->addFieldMapping(NULL, 'gid')
->description(t('This info will not be maintained in Drupal'))
->issueGroup(t('DNM'));
$this->addFieldMapping(NULL, 'registerDate')
->description(t('This info will not be maintained in Drupal'))
->issueGroup(t('DNM'));
// Open mapping issues can be assigned priorities (the default is
// MigrateFieldMapping::ISSUE_PRIORITY_OK). If you're using an issue
// tracking system, and have defined issuePattern (see BasicExampleMigration
// above), you can specify a ticket/issue number in the system on the
// mapping and migrate_ui will link directory to it.
$this->addFieldMapping(NULL, 'lastvisitDate')
->description('Will a field be added to the vocabulary for this?')
->issueGroup(t('Client Issues'))
->issuePriority(MigrateFieldMapping::ISSUE_PRIORITY_MEDIUM)
->issueNumber(770064);
$this->addFieldMapping(NULL, 'activation')
->description('Will a field be added to the vocabulary for this?')
->issueGroup(t('Client Issues'))
->issuePriority(MigrateFieldMapping::ISSUE_PRIORITY_MEDIUM)
->issueNumber(770065);
$this->addFieldMapping(NULL, 'params')
->description('Will a field be added to the vocabulary for this?')
->issueGroup(t('Client Issues'))
->issuePriority(MigrateFieldMapping::ISSUE_PRIORITY_MEDIUM)
->issueNumber(770066);

// It is good practice to account for all source and destination fields
// explicitly - this makes sure that everyone understands exactly what is
// being migrated and what is not. Also, migrate_ui highlights unmapped
// fields, or mappings involving fields not in the source and destination,
// so if (for example) a new field is added to the destination field it's
// immediately visible, and you can find out if anything needs to be
// migrated into it.
$this->addFieldMapping('format')
->issueGroup(t('DNM'));
$this->addFieldMapping('weight')
->issueGroup(t('DNM'));
$this->addFieldMapping('parent')
->issueGroup(t('DNM'));
}
}

now the changes are visible on the gui wrt the mapping. but now i dont have an idea about what is to be done if i want to import a node. Please help me fast.

dreamriks’s picture

dreamriks commented

hi
after mapping of fields in beer example of migration module, what part of that code is responsible for creation of content and node,. If some one could explain the code it would of huge help to me.
Thanx in advance.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Title: usage of migrate module » Working example of how to map source fields to a Location destination field?
Version: 6.x-2.0-rc1 » 6.x-2.x-dev
Assigned: dreamriks » Unassigned
Category: support » feature
Priority: Major » Normal
Status: Active » Closed (duplicate)

@dreamriks - you had a question about the Migrate module, and what you did was reopen a closed issue in the Migrate Extras module queue and hijack it to ask a question that had nothing to do with that issue. I recommend you read http://drupal.org/node/317 from the Getting Involved Guide and learn how to use the issue queues. Then, you can open a new support request issue in the Migrate issue queue.