Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
As per #2183983: Find hidden configuration schema issues there are fails with several migration tests when using strict schema checking.
Proposed resolution
1. Add strict schema checking in migrations.
2. Resolve failures.
3. Review.
4. Commit.
Remaining tasks
1. Resolve fails.
2. Review.
3. Commit.
User interface changes
None.
API changes
Any schema changes as needed.
Comment | File | Size | Author |
---|---|---|---|
#23 | 2358269-migrate-schema-fix-23.patch | 14.34 KB | Gábor Hojtsy |
#23 | interdiff.txt | 8.57 KB | Gábor Hojtsy |
#21 | interdiff.txt | 1.97 KB | Gábor Hojtsy |
#21 | 2358269-migrate-schema-fix-21.patch | 10.44 KB | Gábor Hojtsy |
#19 | 2358269-migrate-schema-fix-19.patch | 8.47 KB | Gábor Hojtsy |
Comments
Comment #1
vijaycs85Comment #2
vijaycs85Comment #3
Gábor Hojtsy@vijaycs85: are you working on this? You put it on the sprint :)
Comment #4
Gábor HojtsySeems like this issue is way too wide in scope. The menu_link_config and page_manager fails listed are not even from core. And then you added some system.action and system.theme stuff which is not mentioned in the summary... Anyway, let's look at some menu stuff first.
Comment #5
Gábor HojtsyRemoved the menu_link_config and page_manager related bits from the summary.
Comment #6
vijaycs85Looks like D8 totally rewrote this functionality more flexible instead of just a variable. Here is how the flow of this variable from D6 to D8
1. D7 converted menu_primary_links_source to menu_main_links_source
2. Initially D8 converted menu_main_links_source to menu.settings:source.main
3. Then moved to theme.settings (as per change notice) as part of converting menu as block
However any block that we assign to primary_menu region is a primary menu. So for the D6 to D7 conversion, we have to create a block and assign to this region?
Comment #7
vijaycs85Comment #8
Gábor HojtsyComment #9
Gábor HojtsySchema fail patch.
Comment #10
Gábor HojtsyReasons for test fails that I could not resolved but dabbled in resolving:
- MigrateBlockTest: all the visibility settings are migrated to the wrong place (settings.visibility instead of visibility); then all the tests confirm that the path visibility was empty which of course is, the settings are migrated to the wrong place; I tried to set this up properly (see attached) but then it fails on not finding the condition plugins; can someone help?
- MigrateNodeBundleSettingsTest: migrates boolean base field default values as a simple boolean instead of an array of "value: $bool" pairs; again tried to resolve this but made it worse; someone with better migrate experience can help maybe?
Test fails that I did resolve:
- MigrateUploadEntityFormDisplayTest: migrates entity form modes and attempts to set a nonexistent label setting. This was easy to adjust, I managed to actually fix this.
- MigrateUserPictureEntityFormDisplayTest: same thing as with the MigrateUploadEntityFormDisplayTest, same plugin
- MigrateUserProfileEntityFormDisplayTest same problem but different plugin, resolved also.
Need help for the first two. Should not be big for those who have migrate experience hopefully :)
Comment #11
Gábor HojtsyComment #13
Gábor HojtsyFinally the system cron migration also fails. This does not seem to have its own tests but only fails as part of the full D6 test suite. The target config names are incorrect.
Comment #14
Gábor HojtsyComment #15
Gábor HojtsyActually figured out the right fix for the booleans. Now only need to fix the block visibility one with the right constants syntax use. I tried to add constants but it says would not be supported by this plugin?!
Comment #19
Gábor HojtsyThe cron stuff had its own test. Fixing that. I made an attempt to move the block one forward, but its still dabbling...
- Added some constants to be able to use the static values I needed.
- Found another incorrect settings visibility code in the block settings plugin, that needs to be moved to somewhere but not sure how?
- Also now the user roles may be null but should be an array.
The whole visibility thing may require its own plugin due to the logic required?
I *think* this should only fail on migrate block tests. At least locally it did not fail on the labels anymore. Not sure why it does on the above results?!
Comment #21
Gábor HojtsyLooked at the fails again:
1. Missed a form mode label extra in user pictures.
2. System maintenance enablement is stored in state not in config. Not sure if there is a state target for migrate. But its clearly not correct to migrate the enabled setting to config, it is not stored there in D8.
Comment #23
Gábor HojtsySo we needed that custom plugin and I figured it out. Now the old visibility setting and the paths, roles are passed to the new visibility migration plugin which sets up the target structure as needed. That exposed problems with the block tests, because actually two source blocks have custom paths (yay), so fixed the test to test for that and now that actually proves the block visibility *is* migrated. Prior to that all tests were ensuring the block visibility was NOT migrated, which is wrong because again some blocks do have visibility constraints in this test (thankfully).
This should resolve all the problems with the remaining block fails. I think this fixes all the bugs found. While it is certainly possible to improve the block visibility stuff further, this is required to satisfactorily close #2183983: Find hidden configuration schema issues so I would love to get this in as soon as possible. It fixes clear bugs found :)
Comment #24
Gábor HojtsyComment #25
benjy CreditAttribution: benjy commentedI reviewed the patch, everything looks good to me. Great work!
This is awesome! I'm almost surprised there were so few wrong config keys :)
Comment #26
alexpottAwesome work. Committed 194539a and pushed to 8.0.x. Thanks!
Comment #28
Gábor HojtsyFantastic, thanks!