I'm having trouble with both a db and xml update import to make my changed time stamp correct for nodes.

Digging into node.inc there is a weird construct regarding $changed which blocks the ::prepare($node, $row) to set the changed time correctly.

CommentFileSizeAuthor
#10 migrate-change_date_preserved-1901898-10.patch519 bytespgillis
#1 migrate-node-changed-time-1901898-1.patch539 bytesclemens.tolboom

Comments

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
commented
Status: Active » Needs review
StatusFileSize
new migrate-node-changed-time-1901898-1.patch539 bytes

The attached patch made me happier but I'm not sure about the logic of the mentioned $changed in MigrateDestinationNode::import(stdClass $node, stdClass $row)

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
commented
Title: Changed timestamp is not imported. » Changed timestamp is not imported though node.inc
mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Needs review » Postponed (maintainer needs more info)

Can you describe a little more clearly what the issue is? prepare() has nothing to do with setting changed - it actually has to get set after saving the node, because node_save() insists on setting it directly.

helmo’s picture

helmo commented
Status: Postponed (maintainer needs more info) » Active

After importing a set of nodes, the 'changed' date of these nodes is set to NOW().
In a content listing all nodes would have the same modification date, which is hardly useful to our editors.

We expected the 'changed' value to be equal to that of the source database.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Active » Postponed (maintainer needs more info)

What does your field mapping for 'changed' look like?

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
commented

This is the code from a migration class

  function prepare($node, $row) {
    $node->changed = $node->created;
  }

where we want to trigger the $changed if in

# plugins/destinations/node.inc
...

      // Unfortunately, http://drupal.org/node/722688 was not accepted, so fix
      // the changed timestamp
      if (isset($changed)) {
        db_update('node')
          ->fields(array('changed' => $changed))
          ->condition('nid', $node->nid)
          ->execute();
        $node->changed = $changed;
      }
rob_johnston’s picture

rob_johnston commented

Possibly related #1841136: Setting updated date on entities

I also see the problem of the "changed" (DB language) or "updated" (UI language) field of the node being set to the current time when migrated. However, if I import hundreds at a time I can see that this "changed" field is actually written correctly. It's only after they are all brought in that their dates are updated to the current date. The timing of this seems to correspond to the rows in the node_revision table being updated to set the "status" column from 0 to 1.

@clemens.tolboom , I bet if you change the lines in plugins/destinations/node.inc to include a watchdog statement as shown below you will see that the changed date is correct. It's something happening after this that is changing the data.

      if (isset($changed)) {
        watchdog('migrate_test', 'Changed date-time = ' . $changed);
        db_update('node')
          ->fields(array('changed' => $changed))
          ->condition('nid', $node->nid)
          ->execute();
        $node->changed = $changed;
      }
rob_johnston’s picture

rob_johnston commented

I now see my problem... the node's "changed" column was being updated because my migration script is using a prepare() method to set the workbench moderation state to 'published', 'draft', or 'needs_review'. Once I stop doing that then I get the dates I expect. Don't have a good work-around yet, not even what was suggested in the related issue.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Category: bug » support
Status: Postponed (maintainer needs more info) » Closed (works as designed)

OK, so not an issue in Migrate per se. To force the desired changed value after workbench has had its way with it, you'll probably need to define a hook_node_update function to reset it.

pgillis’s picture

pgillis commented
StatusFileSize
new migrate-change_date_preserved-1901898-10.patch519 bytes

For those not interested in implementing the hook_node_update the attached patch leaves the changed value as what it was in the source database.

pgillis’s picture

pgillis commented
Issue summary: View changes

Updated issue summary.