Problem/Motivation
The way we migrate comment types from Drupal 6 to Drupal 8 is no longer going to cut it, as we have discovered over in #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics. That issue is against the D7 migration path, but D6 is affected too because its comment type migration only creates two comment types -- comment and comment_no_subject. This can result in conflicts and problems when the Forum module is introduced.
Proposed resolution
The d6_comment_type migration should behave exactly like the d7_comment_type migration and create a new comment type for each node type. To facilitate this, it would be a LOT easier and cleaner to remove the comment type-related source plugins from the D6 migration path, and have the D6 NodeType source plugin include the comment settings for each node type. This will be a million times simpler and cleaner! We will then be able to do the mapping for the D6 forum comment type as we did for D7 in #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics.
And while we're at it, we should do the same for Drupal 7, that is get rid of the CommentType source plugin and move this functionality in the NodeType source plugin, so we'll have a common way to deal with comment types from Drupal 6 & 7.
Remaining tasks
Write a patch, bikeshed, review, and commit. Not necessarily in that order.
User interface changes
None.
API changes
A few source plugins from Migrate Drupal (which is experimental!) will probably be removed. Therefore, this constitutes a BC break, although it's in an experimental meta-module and therefore within policy.
A few source plugins from Migrate Drupal are now deprecated.
Those are:
- Drupal\comment\Plugin\migrate\source\d6\CommentVariable
- Drupal\comment\Plugin\migrate\source\d6\CommentVariablePerCommentType
- Drupal\comment\Plugin\migrate\source\d7\CommentType
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #57 | 2887142-57.patch | 90.29 KB | ada hernandez |
| #57 | interdiff-2887142-54-57.txt | 954 bytes | ada hernandez |
| #47 | 2887142-47.patch | 84.49 KB | maxocub |
| #45 | interdiff-2887142-42-45.txt | 490 bytes | maxocub |
| #45 | 2887142-45.patch | 90.14 KB | maxocub |
Comments
Comment #2
phenaproximaHere's a first attempt to ice the variable-based comment settings plugins in favor of merging that information into the d6_node_type plugin...
Comment #4
phenaproximaThis oughta do the trick.
Comment #6
phenaproximaOkay, THIS should fix all the entity counts. Man...that test takes forever.
Comment #7
maxocub commentedI think that this makes a lot of sense and that it is much easier to understand what is going on.
Nevertheless, I tested it manually and it doesn't seem to be working properly yet. When I go to a migrated node which is supposed to have comments, I don't see them. It seems like there's no comment fields on the node types.
Maybe the tests should try to reproduce that, like load a node and see if the comments are there.
Comment #8
phenaproximaWell...dammit. Thanks for testing, @maxocub! I will try to reproduce the problem, and expand the test coverage to account for the hole, when I trace it.
Comment #9
maxocub commentedThis is postponing a Migrate critical (#2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics), so adding the tag here too.
Comment #10
maxocub commentedComment #11
maxocub commentedComment #12
maxocub commentedI found the problem. Some field instances were not migrated because the comment variables for some content types on the D6 site were not set and they were using default values.
I added the default values in the d6_field_instance migration and modified the comment field instance test so it would also tests those field instances on those content types that are using default values.
Comment #14
heddnAssigning to myself for review this week.
Comment #15
maxocub commentedThis is postponing a critical: #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics so this should also be critical.
I'll work on the CR so this can be completed.
Comment #16
maxocub commentedHmm, reading the IS and seeing the the issue that is postponed on this is related to D7, I don't think this is really a blocker.
Also, I think it would be nice to do the same thing to the D7 comment type source plugin, just to have a common way to deal with comment type migrations.
Comment #17
maxocub commentedHere's a patch that does the same thing for D7.
If it makes the patch too big for review, I can always split it for D6 & D7 and create a second issue.
Comment #19
maxocub commentedRemoved the test for the deleted CommentType plugin.
Comment #20
maxocub commentedComment #22
jofitzTests are green so returning to Needs Review.
Comment #23
maxocub commentedComment #24
maxocub commentedAdded two change records.
Comment #25
heddnWhat happens if comment type is null? I guess we skip the whole comment then. That seems to make sense to me.
Reviewed #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics and we are doing the same thing there. Good.
I think we need or could add a BC layer here.
Comment #26
maxocub commentedRe #25:
1. Yes, the row is skipped if the comment type is null.
2. There's some overlap between the two issues, we'll need a re-roll once one of them gets commited.
3. Added back the source plugin and added deprecation notices. Also added back the tests for those deprecated source plugins.
Comment #27
heddnYou're the man @maxocub. I've removed the BC break tag and will review this again.
Comment #28
andypostLooks impressive, found only typo
typo s/ModeType/NodeType
Comment #29
maxocub commentedOups, good catch!
Comment #30
jofitzCoding standards correction.
Comment #31
heddnLet's move this back to 8.4 since this is really a bug, not a task. So that means we'll need to update the trigger_error message and probably add a Change Record.
Comment #32
jofitzUpdated the trigger_error messages.
Comment #33
heddnComment #34
masipila commentedheddn, you asked in IRC for comments if this issue and #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics are so closely related that one of these needs to be committed first.
--clips--
I discussed this with maxocub on IRC:
21:51 < masipila> heddn asked two days ago here for my opinion if https://www.drupal.org/node/2853872 or
https://www.drupal.org/node/2887142 should be committed first
21:57 < maxocub> Hi masipila, personally, I don't think it matters which one gets in first. I'd be happy to
make the re-roll and I don't think it would be that complicated. Logically though, I think
https://www.drupal.org/node/2887142 should be commited first.
21:57 < masipila> maxocub: I would tend to agree
--clips--
Cheers,
Markus
Comment #35
heddnIS seems updated. All feedback addressed. Let's get this merged.
Comment #36
maxocub commentedThis needed a re-roll since #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics landed.
Comment #37
maxocub commentedOups, forgot the files.
Also putting it back to need review so someone else can confirm everything is still good to go.
The only thing added, as seen in the interdiff, is the static map dealing with forum comment type in D6, mirroring what was done for D7 in #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics.
Comment #39
maxocub commentedThe D6 entity count needed updating because of the forum comment type migration. We are not creating new comment type, field config, etc. for forum but using the ones already provided by the forum module, like we did in #2853872: Migration for forum and article comments: duplicate comment types and incorrect comment_entity_statistics for D7.
Comment #40
phenaproximaIt's a long patch, but it's looking truly excellent. I really like the changes made here. I also like the improved and expanded test coverage, and I think the migration path that comment types and fields take will be much clearer after this lands. Bravo to all!
Since it's me, I found many nitpicks -- almost all doc comment things. I do want to add more test coverage for the NodeType plugins, so I'm kicking this back as needing tests, but I think that will be doable in a jif.
Why were these dependencies added?
This should also be in the migrate_drupal_6 test group.
We can improve this. How about "Asserts various aspects of a comment component in an entity view display"?
Let's use assertInternalType('array', $component) here.
I think this should also have the migrate_drupal_6 group.
Let's change $id's description to "The entity form display ID."
Same here.
Again, let's have this in the migrate_drupal_6 group too.
As before, we can improve this doc comment. Just reuse my previous suggestions :)
assertInternalType() is preferable here.
Let's add this test to migrate_drupal_6 group.
And this one.
We want to keep this in both test groups.
The test should be in both groups.
Let's add this test to migrate_drupal_7 group as well.
$id's description should be "The entity form display ID."
Same here.
Let's add this test to migrate_drupal_7 as well.
How did this change come to be?
Why do we suddenly have ten more comment types? I'm not opposed to this, but we may need to explain that to the committers so it will be good to document it here.
We should probably expand the unit tests of the NodeType plugins to ensure that they return this data properly. It's pretty clear that it works, but more test coverage never hurts.
Comment #41
maxocub commentedOn it.
Comment #42
maxocub commentedComment #43
maxocub commentedUnassigning.
Comment #45
maxocub commentedFixing the failing test.
I don't see why those migration are dependencies, but since they are in a test, I leave them there.
Comment #46
heddnVery mild question/nit. Should we use callback and UC the first word too? If you disagree, ignore.
This seems like we are loosing coverage over the deprecated functionality. Yeah, I don't see any @legacy tags in the patch.
Comment #47
maxocub commentedRe #46:
Comment #49
maxocub commentedRe #46.2:
Hmm, since these tests are integration tests and not unit tests, it's hard to keep them without modifying them so much that they do exactly what the new tests do.
The yaml files are now using the node_type source plugin, so I don't see how we can keep them and tests those deprecated source plugins.
We could add unit tests for the deprecated classes, but this patch is already big enough. Could we do that in a follow-up if that's really necessary?
Comment #50
phenaproximaMaybe I'm being dense, but I don't see a problem here. All the affected migrations still have passing integration test coverage. So I'm not sure what else we're missing.
Comment #51
maxocub commentedThis issue was postponing a Migrate critical, #2909752: [D6] Migration for comments: duplicate comment types and incorrect comment_entity_statistics, and is now fixing it right here in this patch.
I closed #2909752: [D6] Migration for comments: duplicate comment types and incorrect comment_entity_statistics as a duplicate, but that means this issue should now be marked as a Critical since it fixes the forum comment type bug.
Comment #52
catchCould we move this to a protected method that we can mark @deprecated? That will make it easier to find for removal in 9.x.
Comment #53
phenaproximaI think that's a good idea. Let's get that done, then I think this is back to RTBC.
Comment #54
ada hernandez commentedAdded @deprecated method
Comment #55
ada hernandez commentedComment #56
phenaproximaThanks, @Adita! Only one thing remains.
Each of these need a short, one-line description, and should come before the @deprecated tag.
Comment #57
ada hernandez commentedthanks!, description added/sorted
Comment #58
phenaproximaGlorious. RTBC once Drupal CI passes it.
Comment #60
catchCommitted/pushed to 8.5.x and cherry-picked to 8.4.x. Thanks!
Comment #62
andyposttests are incomplete and probably broken so filed follow-up #3007436: Fix d7 comment migration
d7 source plugin is not fixed as d6 one