Problem/Motivation
As in Drupal 6 nodes were used for a lot of different use-cases some node types are completely replaced by new concepts and, thus, do not need to be migrated. One example would be page nodes which get replaced by proper page manager pages in Drupal 8.
Proposed resolution
Allow to limit the nodes to be migrated in the D6 Node source plugin by a specific node type.
Remaining tasks
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | interdiff.txt | 1.49 KB | benjy |
| #18 | 2332751-18.patch | 21.75 KB | benjy |
| #16 | 2332751-16-migrate-node-node-type.patch | 21.64 KB | tstoeckler |
Comments
Comment #1
tstoecklerHere's something I cooked up. It seems to work going by some limited testing.
Notes:
- If this is accepted we want to expand this to e.g.
NodeRevisionas well- This will need config schema
- Due to how
condition()works, this can be both a simple string and an array of node types, which is kind of neatThoughts?
Comment #2
tstoecklerOops, here's the patch.
Comment #3
benjy commentedYeah I like it, especially if it's that simple. +1 from me.
Comment #4
tstoecklerHere we go.
NodeRevisionactually does not need to be updated, as it extendsNode. Nice!This patch adds some config schema and tests.
Btw, we should separate the config schema and move lots of it into
migrate_drupalwhere it belongs, but that's not for this issue.Comment #5
tstoeckler#facepalm
Comment #7
tstoecklerAhh, yes, that doesn't really work. Here we go.
Comment #8
ultimikeComment #9
benjy commentedHad a quick look over this and it looks good. I'll try give it a proper test a the weekend.
Would be good to tidy up the serialized strings mentioned below.
Can we make these arrays and then call serialize. I think we decide that was the clearest way elsewhere.
Same for these.
Few more
Comment #10
benjy commentedOK, re-rolled this issue and fixed the formatting things I mentioned just before. Also fixed the NodeByNodeTypeTest.
Comment #11
tstoecklerAwesome, thanks @benjy! I had sort of forgotten about this...
Comment #12
ultimikeShouldn't this comment be above line 89? Seems out of place here.
Also - while the changes/additions to the automated tests look good, I have to admit that I'm still trying to figure out the difference between the tests in core/modules/migrate_drupal/src/Tests vs. the tests in core/modules/migrate_drupal/tests
Finally, once this gets committed, we'll need to document it - probably here, I assume: https://www.drupal.org/node/2129649
-mike
Comment #13
benjy commentedThanks for the review.
The difference between the tests are that unit tests live under core/modules/migrate_drupal/tests where as integration tests live under core/modules/migrate_drupal/src/Tests
Comment #14
ultimikeLooks great!
Thanks for the explanation on unit vs. integration tests.
-mike
Comment #16
tstoecklerI have no idea what is going here, but let's see if copying the recent changes from #2333357: Migrate node_revisions.timestamp into the revision_timestamp field here helps. It doesn't hurt to keep these in sync in any case.
Comment #18
benjy commentedthe log field needed to be added to the revision fields.
Comment #19
tstoecklerAwesome, thanks! Pretty minor stuff since #14 so I hope it's OK if I set this back to RTBC.
Comment #20
tstoecklerAhem.
Comment #21
alexpottCommitted 807e561 and pushed to 8.0.x. Thanks!