Last updated December 11, 2012. Created by mikeryan on November 22, 2011.
Edited by Alan D., lliss, nerdcore. Log in to edit this page.
To migrate content into Drupal nodes, use the MigrateDestinationNode class:
<?php
$node_options = MigrateDestinationNode::options($language, $text_format);
$this->destination = new MigrateDestinationNode('article', $node_options);
$this->addFieldMapping('title', 'source_title');
$arguments = MigrateTextFieldHandler::arguments(array('source_field' => 'source_teaser'));
$this->addFieldMapping('body', 'source_body')
->arguments($arguments)
...
?>The first argument is the bundle (content type) you wish to migrate source content into.
Fields
nid - The Drupal node ID. Usually this will be unmapped - the nid will be automatically assigned when the node is created, and the map table will record the source key that generated this ID. You will need to map the nid when the system-of-record is DESTINATION (i.e., the purpose of your migration is updating existing nodes rather than importing new nodes). Also, if you want to maintain the same content ID as you had in the source system, you would map that ID to the nid as well as setting the is_new option.
title - The title of the node.
uid - The Drupal user ID of the account that created the node.
created - The date and time when the node was created. If no value is mapped from the source data, this will default to the time the node is imported by Migrate. Note that while this is ultimately stored as a UNIX timestamp, any absolute date/time string supported by strtotime() can be mapped to this (or generally any other timestamp field).
changed - The date and time when the node was last modified. See also created. Note that if not mapped, it will default to the time the node is imported by Migrate.
status - The node status, 1 for published and 0 for unpublished.
promote - Whether the node is promoted to the front page (1 for promoted, 0 for not promoted).
sticky - Whether the node should be listed at the top of listings by default (1 for sticky, 0 for not sticky).
revision - Whether to create a new revision for the node (1 to create a revision, 0 to overwrite if the node already exists).
log - Log message to store with a revision.
language - The node's language, e.g. "en" for English.
tnid - The translation set ID for the node.
translate - A boolean indicating whether this translation page needs to be updated.
revision_uid - The uid of the user who created a specific node revision.
is_new (Drupal 7 only) - An option that, if set to TRUE, will create a new node using the value mapped to nid as its ID, rather than generated a new sequential ID. Because the Migrate module maintains the mappings of source to destination IDs, and supports automatically substituting them with sourceMigration to maintain relationships, this is rarely necessary (even if you might think you need it at first glance).
Options
Language
The language option will be applied as the default language for any node fields which are language-dependent. If unspecified, it will default to LANGUAGE_NONE.
Text format
The text format (e.g., 'filtered_html') will be applied as the default text format for any node fields which take a format. If unspecified, the default for the field will be applied. On Drupal 6, this should be set to the numeric text format value (i.e. '1' for Filtered HTML - see the filter_formats table to find the numeric ID) rather than the human readable name for the filter.
Node statistics
Support for the core Statistics module was added in v2.4. Map like any other node field.
<?php
$this->addFieldMapping('totalcount', 'total_count');
$this->addFieldMapping('daycount', 'daily_counter');
$this->addFieldMapping('timestamp', 'last_viewed');
?>
Comments
Numeric Value for Text Format?
This page says
But where are those values? How do you know that '1' is 'Filtered HTML'?
Is this even correct? I
Is this even correct?
I used
<?php$text_format = 'filtered_html';
?>
and it seemed to work fine. Could this have been changed from D6 in D7? Here is an excerpt of the schema from my D7 DB:
mysql> describe field_data_body;+--------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+------------------+------+-----+---------+-------+
...
| body_format | varchar(255) | YES | MUL | NULL | |
+--------------+------------------+------+-----+---------+-------+
Filter format
Hey nerdcore -- I had the same reaction, and had to go hunting around to find out that in D7, the filter_formats table uses machine names for "format" where previous versions used ints.
Goldurned young upstarts changin my data types. Why, ints were just fine in my day...
When I was your age, we
When I was your age, we didn't need UUIDs. ;)
Thanks for the tip. I'll have a look at filter_formats.