Closed (fixed)
Project:
Drupal core
Version:
9.4.x-dev
Component:
migration system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
23 Mar 2019 at 09:53 UTC
Updated:
16 Jan 2022 at 10:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
heddnComment #5
quietone commentedComment #8
quietone commentedIt looks like there are two problems. 1) The field_name was being used as the name for the target vocabulary and 2) the target bundle was created as an indexed array, when it should be associative with the key and value the same. And that is how the target_bundles are tested in \Drupal\Tests\field\Kernel\EntityReference\EntityReferenceSettingsTest.
Next is to double check what the D7 migration does.
Comment #9
quietone commentedThe Drupal 7 migration of the allowed vocabularies is correct, it is an associative array. So nothing to do there.
Comment #12
danflanagan8I ran upgrades from the drupal6 fixture through the UI without the patch and confirmed the bug was present.
Then I applied the patch and tried again. This time the target bundle got assigned correctly.
So manual testing was great!
As far as the code itself, I have two comments.
1. I think it would be nice to make it clearer that the new plugin is only used for the d6 migration. Maybe just in the comment above the annotation mentioning d6?
2. What would you think about re-naming the new helper function in the tests? When I saw
assertEntityReferenceFields()I was surprised that all it checked was the target bundles. Something likeassertTargetBundles()would probably read a little smoother.Neither of these is a big deal though, and I could be convinced that neither is necessary.
Comment #13
quietone commented@danflanagan8, Thanks for the testing!
#12.1 An extra line seemed unnecessary so I reworked the summary line to include 'Drupal 6'. What do you think.
#12.2 Yes, that is a better name. Fixed
Comment #14
danflanagan8@quietone, I think the changes look great. I also want to point out for the record that all of your changes to the test are additive except for this one line:
That line was actually asserting that the migration is incorrect because we really want the target bundles to be
['tags' => 'tags']. So we're not losing test coverage there!But...Last night I started wondering if there was a way to reproduce the effect of the new process plug with existing process plugins. (This is my favorite part of migration!) This morning I was able to hack something together. It's miserable though! Here's the relevant bits.
It could have been cleaner is php's
array()was callable but apparently it's not. That's why I had to do that json thing. I think above is our best option other than creating the new process plugin.Seeing as the above is absolutely unreadable, I think your patch is the way to go. RTBC. Thanks!
Comment #16
quietone commentedRestoring RTBC because the test failure was due to #3255836: Test fails due to Composer 2.2 which has been fixed.
Comment #19
catchCommitted/pushed to 10.0.x and cherry-picked to 9.4.x, thanks!
The new process plugin makes this minor-ish, please re-open if you think it should be backported to 9.3.x.