Importing node revisions preserving vid order [#2883441]

I'm trying to import nodes and their revisions from two D7 sites into a single D8 site, while preserving vid order (older revisions have lower vids).

The obvious way import nodes and revisions is to first run a migration like d7_node.yml, with nid and vid omitted so that they get assigned new values in the D8 site (otherwise there would be collisions if the same nid/vid exists in both sites). This imports all current revisions and populates a migrate_map_d7_node table mapping D7 nids to D8 nids. Then, to import the other revisions, run a migration like d7_node_revision.yml, with vid omitted and nid populated like this:

process:
  nid:
    plugin: migration_lookup
    migration: d7_node
    source: nid
  ...

The problem with this approach is that the current revision gets imported first, so its vid is lower than the vids of the older revisions. This causes the current revision to appear at the bottom of the node's Revisions tab. This might be tolerable in itself, but I'm also trying to import Workbench Moderation states from D7, and Workbench Moderation appears to assume that the most recent revision has the largest vid. So preserving vid order is a must.

The only other approach I could think of is something like this:

Run a node import using a modified version of the d7_node source plugin that imports the oldest D7 revision (not the current)
Import revisions as described above
Import nodes as described above, using the --update flag. This should overwrite the current D8 revision with the current D7 revision.

This seems pretty convoluted and may not be easy to implement. Is there some part of the Migrate infrastructure that helps solve this problem?

Comments

Comment #1

2 June 2017 at 14:03

colinmccabe created an issue. See original summary.

Comment #2

mpotter CreditAttribution: mpotter at Phase2 commented 11 May 2018 at 14:26

I think this is more of a Core issue now rather than for migrate_plus.

I've run into the same issue and now in Drupal 8.5 this is more serious since Editing a node will load the "current revision" into the edit form and core now assumes that the "current revision" is the revision with the highest vid. Thus, for content migrated like this where the original node has a lower vid, editing the node actually loads the *previous revision* into the edit form. This can cause previously unpublished draft content to be published if the content editor doesn't notice.

I ended up creating a drush script that I run after doing the revision migration that loops through and resaves the nodes (preventing the Changed date from changing in a presave). Seems like a real kludge and makes me wonder how anybody is migrating revisions properly from D7.

Comment #3

heddn

English

Nicaragua

CreditAttribution: heddn at MTech, LLC commented 16 May 2018 at 15:05

Project:	Migrate Plus	» Migrate Upgrade
Version:	8.x-2.0-beta2	» 8.x-3.x-dev
Component:	API	» Code

This is more of a migrate upgrade issue. Or core, maybe. But let's start in upgrade. Since only with that can someone rewrite the ids as stated in the IS.

Actually, I'm not sure that just loading the most recent revision is the "right" solution in core. Is there a way in core to know the right published revision? And maybe update listing views or such to better handle this edge case so it sorts published revision to the top.

So, after moving this to the migrate upgrade queue, if we feel this should be solved in core based on that last paragraph, please move it again.